My first trials of Maven were failures. As I am stubborn, I tried again, on a new project, a quite simple one. It works, but it makes some easy things overkill. And the default way of using it makes a developer lose lots of time.
If I have a project with common classes, a standalone app, and a web app, then logically you do 3 projects, 2 of them depending on the common one. That's how the default maven setup works, and that's what their documentation presents. Now when using maven eclipse, this will create 3 project, none depending on each other. If you modify something in the common code, it won't be seen by any of the other code, you have to publish it with maven first, this takes way too much time. Furthermore I did not see any way to force rebuild the common automatically from one of the other project. If you modify code in common and web app project, you need to call maven twice. I find all this very counterproductive, because you do those steps extremely often. Now there are probably some ways to do that with Maven2, but it is not the default behavior. I could add project dependencies in eclipse manually, and forget about maven while working in eclipse, but then the maven eclipse plugin is really useless. And you'll face the same issues when you want to use maven tomcat deploy.
Even more worrying, after moving back to Ant, I saw a strange bug with Spring context loading disappear. Maven is hiding so much, that it becomes not obvious how your app is deployed.
Developers lose power with Maven. It's a pain to do something a bit differently that the default Maven way. With Ant, people gain power. I see both as being the distinction between a framework approach (Maven) and a library API approach (Ant). By default, Maven tries to do a lot, while Ant tries to do nothing. It's very easy to build exactly what you need with Ant, while it is of course difficult with Maven.
Some parts of Spring have a similar disadvantage to Maven. If you do everything in XML with the most Spring magic, you'll spend hours trying to figure out how to do things and why it does not seem to work like you think it should. If you use Spring as an API, like the wonderful Spring JDBC, development will be fast (faster than with straight JDBC for example), and your program flow is easy to follow.
I just worked through the documentation here
ReplyDelete(using maven 2.0.6 and eclipse 3.2.2) and the maven eclipse:eclipse target automatically added the core project to the module1 project as a dependency.
This means that when working in Eclipse I can make changes in core without having to do a maven install - my changes to core are picked up automatically in module1 since module1 depends on the core eclipse project, not the installed jar.
Hope this makes sense.
Completely agree ! I've tried Maven 2 for a month and switch back to simple ant. It just make simple think harder.
ReplyDeletecouldn't agree more: We did a rather huge project with maven1, migrated it too maven2, which was a catastrophe. Dependent projects are one thing, but working with codegeneration (we had some model driven developments in there: project A produced artefacts that project B needed for the compile) brings up another bunch of problems. Most of the time you simply don't know what exactly maven does. And you will spend so many time figuring out, which switches to flip if you want to change something, that you do not really gain anything from the default behavior. Speaking of defaults: The automatically generated documentation is great! That is, if people write documentation. Most apache-projects have the standard maven-website with "insert-documentation-here" written all over it. Maven gives you plenty of functionality "out-of-the-box" that you never really need.
ReplyDeleteWe finally moved back to ant&ivy: Gives you much more transparency and it is much easier to figure out, what is going on in your build. I found ivy's ide-integration actually quite good and it really helps you to get a consistent classpath during development *and* build...
And
My main issue with maven is the non-repeatability of the resulting build.
ReplyDeleteSince transitive dependencies cause external POM files to be read and processed as part of the build, the end result of your build may vary on a day-to-day basis, depending on how stable the external POMs are.
Also since the default behaviour is to include the dependencies that arise transitively, you may end up with completely unnecessary jars in the resulting build. I find it a lot more difficult to prune out jars I do not know than to manually add jars I understand I need.
Amen, brother. Maven is a complete hairball. It tries to solve problems that don't exist, and in doing so, introduces mounds of needless complexity and worthless artifacts.
ReplyDeleteChris, I had less jars in the Ant created war file. Otherwise they should have be the same in my mind. I did not check exactly what was the culprit with my Maven2 deployment, it is obviously something I must have done wrong, but I don't know what.
ReplyDeletePaul is right, I should have done that in the first place, having a project that gathers the modules, it might even make deploying to tomcat in one step possible.
ReplyDeleteI think everything is possible with Maven2, it is just not straightforward for me, and as I see, for lots of other people.
I found Maven 2 to work really well for me, but I didn't use any GUI tools - just v. small pom files generated at the command line.
ReplyDeleteHere is the article I wrote on how I use Maven 2.
I've noticed a lot of people complaining about the Eclipse plug-in, which I've never bothered to install.
I really like maven 2.0 and had a hell of a time getting 1.0 to work.
ReplyDeleteMind you my development style is application based and
I still use ant but get it to call maven for me.
I also use a ant scripting standard I am developing called "Theena" which provides a frame work of basic build functions and all the custom build processes live in there own project based ant script which Theena calls.
Hope to release Theena to source forge some time soon.
One reason your war output from Maven is bigger than Ant could be due to not specifying dependency scope.
ReplyDeleteSo true ... so true ... Wasted two days just to generate a f*cking ueber-jar, still without success.
ReplyDeleteI disagree with Ivy as a better Maven. Both have a difficult learning curve, but you may find much more available plugins in Maven then in Ivy. Of course, both of them can rely on Ant. I also disagree with the fact that Ant is better then Maven, because Maven is more complicated, since Maven does more then Ant. I have a collection of archetypes for Maven, in my career I have done a lot of types of projects such as: XML JAXB parsers, EJB or Hibernate with automatically generated code, ANTLR grammars, Java Web start applications, OWL parsers, Web applications, Enterprise application and Web Services. For each type of project I have a POM file which I paste in my new project. It can be 5 lines or it can be 300 lines, in case of AndroMDA plugin. This makes me much more efficient then working with Ant. Also dependency management is much better then in Ant, in Maven almost everything gets downloaded automatically.
ReplyDeleteI use maven2 for my work (for two years) and I wouldn’t recommend it to anybody. Unpredictable, overcomplicated, with many hardcoded assumptions (often with no way to change by parametrization - this development laziness is called ‘convention over parametrization’). It was mistake - ant is much more productive choice.
ReplyDeleteMaven is a nice thing as long as you do not use eclipse.
ReplyDeleteI can use "maven clean install" on the command line an everything is fine, if I try to do the same in eclipse, it is not workking and usually takes hours to find out what is wrong this time.
If everything is finally working in eclipse, don't close it. Just closing eclipse an open it causes 15 out of 20 priojects with errors and I usually have to touch every single project to make it compilable and runnable again.
Either use Eclipse with ant or Maven without Eclipse. That is just a nightmare and definetely counterproductive.