Workarounds for five Maven 2 design issues
Now that the Maven 2 hunting season has been officially opened here's my top 5 of Maven 2 design issues and their workarounds:
Transitive dependencies: they are a liability. If your build consists of separate modules that are inter-connected you have to precisely design the content of these modules in order to control the dependencies that are propagated. Workaround: disable transitive dependencies by adding
<optional>true</optional>to a dependency and add required dependencies manually.Plugins not shipped with Maven distribution: this is a design master piece according to some. Delete the contents of your repository and your build may no longer work. This is particularly an issue when you want to build an old version of your code, maybe some weeks or months old. Also, see next point. The Maven brotherhood regularly updates their plugins. Maven will automatically download the latest version unless you specify the version number in your
pom.xmlfiles. Workaround: specify plugin versions.Plugins are poorly maintained: we use the usual plugins and we have 4 (four!) different versions of commons-collection, junit and commons-lang in our local repositories, 3 versions of ASM and so on. All of these are dependencies of plugins. Many plugins are not longer maintained and it's not unsual that the latest version of a plugin has SNAPSHOT or alpha in its version. If plugins would be shipped with the product they would have to go through some kind of quality control and release cycle. Workaround: set up your own repository for plugins, change versions of dependencies in plugin
pom.xmlfiles.No distinction between JAR and project dependencies: if one project depends on another in the same build you should have the option to depend on that project, not its JAR. Furthermore, it should be possible to let Maven 2 automatically build other projects if you depend on them directly. Some people may be against this and this brings up a question: should the Maven brotherhood dictate our ways of working, or should they facilitate them? Workaround: none.
Maven 2 is not designed to prevent loss of time: there is no charter on quality, no guidelines for plugin developers to work towards a better user experience. There's no oversight on plugins, not even the offical Maven plugins. Maven is extensible in many ways but not in ways that would make a difference. The code base is 10 times as big as it should be. The losers are Maven 2 users. We've already lost at least two man weeks on Maven over the course of a couple of months. Workaround: none, unless you want to write your own build system.
I believe Maven 1 has introduced a number of important practices. Maven 2 did not manage to go beyond that. In my opinion there's room for new build systems with a better focus on the user experience to replace Maven 2.
- Login or register to post comments
- 3997 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Alejandro Dobniewski replied on Thu, 2008/01/31 - 4:28pm
Roman Pichlik replied on Thu, 2008/01/31 - 4:30pm
# 1.) Concept of transitive dependencies works well, but there is lack of well defined POM descriptors in most cases for OSS libraries. Absolut classic is Jakarta Commons Logging with Servlet API dependency. This is not problem of concept Atransitive dependencies, but crap POMs. There is simple solution, use an internal repository and maintain POMs itself. This approach may work for internal project, but doesn`t work for OSS projects. Therefore repo1.maven.org should be maintained in a better way.
# 2.) Use dependency management and collect all you dependencies and plugins to a central project POM.
# 3.) It`s funny because it isn`t problem of Maven. It is as saying that Eclipse is bad since there are poorly implemented plugins.
# 4.) From my point of view is better to depend on something what`ve been tested.
Steven Devijver replied on Thu, 2008/01/31 - 4:53pm
in response to: rp117107
Justin Edelson replied on Thu, 2008/01/31 - 8:19pm
in response to: sdevijver
No it doesn't. I have project that has 10 dependencies. I depend on this project, but at runtime I only need 3 of those 10 libraries. What do I do?[/quote]
But that proves the point. The other 7 depdencies should be declared as optional in the POM. JCL is a great example. It looks like they finally changed Servlet, Log4j, and LogKit/Avalon to be optional, but only in the 1.1.1 pom (http://repo1.maven.org/maven2/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.pom)
Steven Devijver replied on Fri, 2008/02/01 - 12:36am
in response to: justinedelson
Interesting. And what if in another use I need 4 other libraries out of 10? And in another one 2 others out of 10. What do I do?
Ignacio Coloma replied on Fri, 2008/02/01 - 2:53am
in response to: justinedelson
Sorry, but this is only applicable to the simplest of projects. Try to use Spring in a maven project, and tell me that you find it reasonable.
The Spring guys have made a great effort isolating their dependencies, but I have to repeat the same work because the maven dependency system is (sorry) crap. Ivy allows spring descriptors to specify a "persistence", "aop", "web", "security" configuration that would solve the problem. Maven has "runtime", "compile" and "test". Clearly insufficient for a project with 40+ dependencies.
In my opinion, maven has displaced responsibility of their actions over their users for too much time. You forced spring to deploy a dozen artifacts, when just one should be enough. There is no way I could say "bring me hibernate for jpa, without caching". My projects have dependencies with internal guts of projects I do not want to know about.
The answer "it's our users' fault" is far too common. I do not see apt-get or yum users complaining this much.
Roman Pichlik replied on Fri, 2008/02/01 - 3:06am
in response to: sdevijver
Interesting. And what if in another use I need 4 other libraries out of 10? And in another one 2 others out of 10. What do I do?
[/quote]
You have to explicitly declare these dependencies in your POM. It is still ok since default works for 80% cases. Let say that transitive dependencies as Log4J, Servlet API etc. for Commons Logging are in the scope optional. After it most of Commons Logging use cases works fine and if you want something extra, go to a POM and declare it. The key point is that transitive dependencies should be declared as smart defaults. Lets look to a POM file of Spring framework, dependencies are declared in a manner of smart defaults and everything works fine.
Justin Edelson replied on Fri, 2008/02/01 - 12:33pm
in response to: icoloma
Sorry, but this is only applicable to the simplest of projects. Try to use Spring in a maven project, and tell me that you find it reasonable.
[/quote]
I do this with some regularity and haven't had any big problems, but don't doubt others have different experiences.
[quote=icoloma]The answer "it's our users' fault" is far too common. I do not see apt-get or yum users complaining this much.
[/quote]
I wasn't blaming the users. Keeping the repository clean is clearly the responsibility of the repository owner, i.e. Apache in this case. The comparison to apt and yum is apt (no pun intended) - a Maven repository needs to be curated much in the same way a Linux distribution is.
common1 replied on Mon, 2009/06/29 - 12:27pm
common1 replied on Mon, 2009/06/29 - 12:28pm