4 ms·

What a non-sense. You can't sanely describe build of your project(s) in documents. Did Maven folks include every possible scenario in markup? Nope. And that's w

by batto 14y ago

What a non-sense. You can't sanely describe build of your project(s) in documents. Did Maven folks include every possible scenario in markup? Nope. And that's why all Maven builds that are not simple jar of classes tends to have long sequentional calls of build plugins. I see it this way: First we had bash and make and ability to do almost everything (run other programs, ...) by using the right thing/language for the job. There was only lack of the functions to deal with Java builds and package management. Then we had Ant, XML programming language with very limited possibilites (I don't regard targets as a feature). But at least we could express what we wanted. Then we had Maven. If we needed something special we need to add it to sequence of build plugins (in several hardcoded build phases). Mostly we resort to do things in Ant plugin. This is why I hate Java. Because of such idiocy.

lmm 14y ago
The ability to call random external programs during the build of your project is not a feature, it's a bug. Likewise the ability to lay out your source arbitrarily. Your project's build is not a unique and special snowflake; it can build the same way as every other project, the way that has already been tried and tested by millions, the way that any developer will immediately understand. If there's really some step that needs to be done in your builds that isn't covered by the existing plugins, you can write your own (it's not hard) and then at least that step is happening in a structured, testable way. But if you're doing something unique to a single project, you shouldn't be doing it in the build system.
- batto 14y ago
  "ability to call external program" is a bug? Well, I do it on almost every line in my super-readable bash scripts. You say it's a bug because you mindlessly follow this Maven doctrine. My projects are unique and so is the way how I build them. Separating classpath source into 'java/' and 'resources/'? It's just masturbation. Why do I need to put my sources in 'src/main/java' and 'src/main/resources' if I know that I'll be using only Java in every project? Writing plugins... why whould I want to do such unpleasant thing as writing Maven plugin when I can usually do it in several lines in script?
- pnathan 14y ago
  > Your project's build is not a unique and special snowflake; it can build the same way as every other project, the way that has already been tried and tested by millions, the way that any developer will immediately understand. No, actually, builds can get very unique in multi-language systems or in embedded systems... believe me. =)
- tomjen3 14y ago
  You have not seen our source code. Anyway ant is for builds, Maven is for dependencies.
st3fan 14y ago
"Did Maven folks include every possible scenario in markup?" For me the main point of Maven is that you keep things simple and standard. By not deviating from a standard Maven web project structure and avoiding dependencies or build phases that need special care, I have projects that are simple to develop, build and package. I am trying very hard to just depend on good behaving Maven dependencies and to stick to simple solutions. No more special build phases for code generation, no more crazy stuff. If I need some special build phase then I am probably doing it wrong. The result of that is also that my projects are super simple. By avoiding special build phases I can pretty much load up a project in any IDE and just hit Run. To me that is the true power of Maven. For that reason I don't want to look back at Ant or any of the fancy super flexible Groovy/Scala/Ruby build tools. So contrary what many people think, Maven forces you to keep things simple. And I think that is a good thing in any project :)
- batto 14y ago
  > So contrary what many people think, Maven forces you to keep things simple. And I think that is a good thing in any project :) Forcing you to something is anything but good.
  - edwinnathaniel 14y ago
    I think he meant "Convention over Configuration"... you know, like Rails.
- equalarrow 14y ago
  'So contrary what many people think, Maven forces you to keep things simple.' This is absolutely why I left Java development. Maven in my mind is anything but simple. It was always frustrating to use - this was 2.0 mind you, so maybe things have become easier, but I doubt it. Even the terminology is totally abstract and complicated. I built a big project for a well known bank around '05-'06 and we had all kinds of problems with maven - we just went back to ant. I used to love Java in the late 90's/early 00's. I remember the resistance to doing projects with it - it was new, unproven, etc, etc - just like Language X today. I worked with some people who built some cool things with 1.2. The collections framework was great. But, then all the enterprise stuff started creeping in and everything was configured with gobs of crap xml. Demos would be given where you could edit the configuration via gui tools, but none of the devs I knew did this. Everyone hand edited everything. Things like maven with their overly abstracted naming and concepts and Spring where everything is 'wired up' by tons of xml are what ultimately drove me away from Java. I just wanted to spend my time working on features instead of configuring things.
zaptheimpaler 14y ago
I haven't worked in the industry for very long. Could someone explain why build processes tend to get so complicated? I have some intuition about the steps that a build process takes being complicated, but it seems to me that the process itself would be linear i.e A + Config -> B -> C -> D -> E -> Compiled Maybe you could have decision points in the compilation flow depending on config parameters, system parameters, making it a tree, but I don't see why a build tool couldn't make those decisions based on the configuration provided. Essentially, I envision a build tool that takes in a huge number of arguments (maybe reads them from an XML/JSON/whatever config file) with sane sets of defaults for each. (Forgive me if all this seems naive, it most likely is. I want to know why.)
- lmm 14y ago
  >Essentially, I envision a build tool that takes in a huge number of arguments (maybe reads them from an XML/JSON/whatever config file) with sane sets of defaults for each. That's pretty much how maven works. A typical java project will have an xml file listing its name and version, the names and versions of all its dependencies, a scm URL for tagging releases and that's basically it. The problem is people who have got used to having all the freedom of calling arbitrary shell programs at any point in the build process; it's very easy to accrete a series of small hacks ("oh I'll just sed this file here to fix that") that add up to something incomprehensible.

by batto 14y ago

lmm 14y ago

The ability to call random external programs during the build of your project is not a feature, it's a bug. Likewise the ability to lay out your source arbitrarily. Your project's build is not a unique and special snowflake; it can build the same way as every other project, the way that has already been tried and tested by millions, the way that any developer will immediately understand. If there's really some step that needs to be done in your builds that isn't covered by the existing plugins, you can write your own (it's not hard) and then at least that step is happening in a structured, testable way. But if you're doing something unique to a single project, you shouldn't be doing it in the build system.

batto 14y ago
"ability to call external program" is a bug? Well, I do it on almost every line in my super-readable bash scripts. You say it's a bug because you mindlessly follow this Maven doctrine. My projects are unique and so is the way how I build them. Separating classpath source into 'java/' and 'resources/'? It's just masturbation. Why do I need to put my sources in 'src/main/java' and 'src/main/resources' if I know that I'll be using only Java in every project? Writing plugins... why whould I want to do such unpleasant thing as writing Maven plugin when I can usually do it in several lines in script?
pnathan 14y ago
> Your project's build is not a unique and special snowflake; it can build the same way as every other project, the way that has already been tried and tested by millions, the way that any developer will immediately understand. No, actually, builds can get very unique in multi-language systems or in embedded systems... believe me. =)
tomjen3 14y ago
You have not seen our source code. Anyway ant is for builds, Maven is for dependencies.

st3fan 14y ago

"Did Maven folks include every possible scenario in markup?" For me the main point of Maven is that you keep things simple and standard. By not deviating from a standard Maven web project structure and avoiding dependencies or build phases that need special care, I have projects that are simple to develop, build and package. I am trying very hard to just depend on good behaving Maven dependencies and to stick to simple solutions. No more special build phases for code generation, no more crazy stuff. If I need some special build phase then I am probably doing it wrong. The result of that is also that my projects are super simple. By avoiding special build phases I can pretty much load up a project in any IDE and just hit Run. To me that is the true power of Maven. For that reason I don't want to look back at Ant or any of the fancy super flexible Groovy/Scala/Ruby build tools. So contrary what many people think, Maven forces you to keep things simple. And I think that is a good thing in any project :)

batto 14y ago
> So contrary what many people think, Maven forces you to keep things simple. And I think that is a good thing in any project :) Forcing you to something is anything but good.
- edwinnathaniel 14y ago
  I think he meant "Convention over Configuration"... you know, like Rails.
equalarrow 14y ago
'So contrary what many people think, Maven forces you to keep things simple.' This is absolutely why I left Java development. Maven in my mind is anything but simple. It was always frustrating to use - this was 2.0 mind you, so maybe things have become easier, but I doubt it. Even the terminology is totally abstract and complicated. I built a big project for a well known bank around '05-'06 and we had all kinds of problems with maven - we just went back to ant. I used to love Java in the late 90's/early 00's. I remember the resistance to doing projects with it - it was new, unproven, etc, etc - just like Language X today. I worked with some people who built some cool things with 1.2. The collections framework was great. But, then all the enterprise stuff started creeping in and everything was configured with gobs of crap xml. Demos would be given where you could edit the configuration via gui tools, but none of the devs I knew did this. Everyone hand edited everything. Things like maven with their overly abstracted naming and concepts and Spring where everything is 'wired up' by tons of xml are what ultimately drove me away from Java. I just wanted to spend my time working on features instead of configuring things.

zaptheimpaler 14y ago

I haven't worked in the industry for very long. Could someone explain why build processes tend to get so complicated? I have some intuition about the steps that a build process takes being complicated, but it seems to me that the process itself would be linear i.e A + Config -> B -> C -> D -> E -> Compiled Maybe you could have decision points in the compilation flow depending on config parameters, system parameters, making it a tree, but I don't see why a build tool couldn't make those decisions based on the configuration provided. Essentially, I envision a build tool that takes in a huge number of arguments (maybe reads them from an XML/JSON/whatever config file) with sane sets of defaults for each. (Forgive me if all this seems naive, it most likely is. I want to know why.)

lmm 14y ago
>Essentially, I envision a build tool that takes in a huge number of arguments (maybe reads them from an XML/JSON/whatever config file) with sane sets of defaults for each. That's pretty much how maven works. A typical java project will have an xml file listing its name and version, the names and versions of all its dependencies, a scm URL for tagging releases and that's basically it. The problem is people who have got used to having all the freedom of calling arbitrary shell programs at any point in the build process; it's very easy to accrete a series of small hacks ("oh I'll just sed this file here to fix that") that add up to something incomprehensible.