Maven would be cool if…
Posted by billburke on February 22, 2008
Maven would be cool if the plugins weren’t so god awful! I mean, are these plugin developers idiots? Do they even use their crap? I just spent a good day trying to get the maven-ear-plugin to work only to give up and do an assembly, only to run into different problems there. Beyond being totally unintuitive, these specific plugins have horrible horrible documentation. Add to this fact that the assembly plugin doesn’t even check its syntax. For example, I had <fileset> and didn’t know why the stupid plugin wasn’t creating the fileset in the jar. Well, its because I didn’t capitalize the ‘S’ <fileSet>. Of course no error message. I had to ditch maven-ear-plugin because it didn’t correctly put transitive dependencies in the directory I wanted automatically.
I just can’t believe people haven’t cleaned up this shit. Are people really using Maven? I WANT to like Maven, I WANT to use Maven. Its too bad its so freakin painful.
arash said
I totally agree! It is really a shame that Java community does not have a sophisticated build tool after so many years!
Dave H said
The only thing I like about maven is the dependency management. I keep meaning to give Ivy a try, but never seem to get around to it.
billburke said
What I *reallY* like about maven is that I can just point Intellij to a pom.xml and everything just works.
alrubinger said
A few observations I’ve made over the past few months:
The Bad:
* Agreed, often the standard plugins are non-intuitive and difficult to configure. I often find myself looking through the source to see what the plugin is expecting.
* Dependency Management is stupid simple at first glance, but once you take into account transitive dependency resolution, things get complex quickly due to the “nearest version wins” model. Frequent use of “mvn dependency:tree -Dincludes=org.me.whatever” helps.
* Defining metadata on the plugins is done in an XDoclet-esque fashion, embedding annotations in Javadoc. So you lose this information at runtime (if you’d like to subclass an artifact to make a plugin, for example).
* Local repositories easily fall out-of-sync; if a snapshot is removed from a networked repo, this change is not reflected locally.
The Good:
* The community at #maven on Freenode IRC is very helpful.
* The Plugin architecture is well-designed, making custom Mojo development easy and powerful.
* I’d rather spend my time developing custom plugins for Maven in Java than wrestling with Ant scripts.
* Antrun Plugin allows for stepwise Maven migration
S,
ALR
Ryan J. McDonough said
For the most part, Maven is great and saves a lot of bullshit. But when it comes to tools like the EAR plugin, its just freakin’ blows. The documentation is crap and doesn’t cover enough cases. As with most Maven plugins, the documentation is half-assed.
Packaging can be a complex process depending on what industry you’re in and how the application is going to be deployed. The current EAR plugin seems to suit the needs of the folks who wrote it at the time. Exclusions are a pain in the ass and non-intuitive. Things get worse with the WAR plugin. Anyone up for writing a better one? This thing is killing me on my current project.
Marcus said
Well, of course, it blows. One size really doesn’t fit all, and if it did, what a boring place to be!
Tobias said
We had major problems with Maven 2 in a bigger “sort of” SOA project. The packaging stuff was a mess, the dependency stuff was not really helpful since we ended up managing all transitive dependencies by hand and we had to ditch the repository approach for proper release management based on a baseline approach.
All in all it just enforced a uniform directory and sub-project structure for all the service projects. And we ha to dedicate one person to manage all the pom.xml files and dependencies and such.
Avishay said
We have just finished writing a full build environment for a very big project containing over 300 maven modules. Reading this blog reminded me all the things we had to put up with while using maven.
Yes, of course , it is better than what we had before!(ant), but dealing with all the problems such as:
The plugins, the transitive dependencies issues, the awful XDoclet, maven-ear/war-plugin not working, the lack of Documentation …
I’ve come to realize that I realy need the control of all that is going on inside the build, which ment writing most of the plugins by myself.
My recommendations:
A realy good place to start is an opensource project called jfrog (www.jfrog.org) which contains several maven2 projects.
If you want to write your own plugin, look at Maven Anno Mojo project which allows you to use Java5 @Annotations instead of XDoclets.
JadePlugins – contains various maven plugins for assembly,multijar and so on ..
Dependency Analyzer – nice graphical tool gives you an overview of your dependencies
Derek Adams said
I know what you mean. We have a bunch of projects that are deployed as sars, wars, and ejb3 jars. I spent a week trying to get the standard plugins to do what I wanted and was never satisfied with the results. I ended up adding assemblies for everything and, even though it works, the whole build kinda seems like a hack now.
soloturn said
would it be worth using http://incubator.apache.org/buildr/ ?
Daoud AbdelMonem Faleh said
building hibernate or OSS management this was a my post about maven few months ago trying to build hibernate from source tree..
just painful..
Regards.
Ittay said
I have very good experience with Buildr. The syntax looks declerative, but you can still write functions. It is build around Rake which is a Make clone, so everything is defined via tasks dependencies which means it’ll only do what is required. And assembly is really just copying files, so you can write your own function.
See http://svn.apache.org/viewvc/ode/trunk/Rakefile?view=markup for an example of a very complex project with Buildr. search for ‘def distro’ and ‘parent.distro’ to see how they handle assembly. Look for ‘package(:war)’ to see how wars are created.
HTH
Dzmitry Liauchuk said
Trying to get Maven running at the moment. It’s really pain in ass to make declarative build tool doing what I’m expecting from it to do.
With Maven I see new and new issues day by day. Different repositores are not in sync; for one project there at least three(!) versions of Spring libraries; Java Errors (linkage/invalid method exceptions) in runtime during the build, etc.
Standard Ant + several custom tasks (e.g. transitive dependency management support) provides full control over the build process. It need to spend just a day or two and everything works just as expected.
I believe Maven serves well for HelloWorld and probably library/framework development projects, because of its decent dependency resolution capabilities. But I hardly can believe it works fine for enterprise with ton of modules and cross-dependencies between them and third-party libraries. It just doesn’t provide fine-grained control upon what’s happening during the build.