http://maven.apache.org/repository-management.html

(we use Nexus)

A couple of quick replies: I think that the way that Maven handles transitive dependencies isn’t great – that’s what you and Tim are both saying as well. We’re also all saying that it’s a hard or impossible problem to fix completely. Hm. More thought needed.

About interoperability with Maven repos: my idea would be to be able to generate essentially just the dependencies part of the pom and include that in something that can be deployed to a Maven repo, but not the rest of the build configuration. You’re saying that a pom that can build the project is needed – why is that?

Your comment about IDE integration is good. I started out thinking that enabling great IDE integration is vital, but it could actually be that implementing it is in fact a core feature.

There are some problems of course, for me the lack of usable documentation is probably the worst but plugin configuration itself is less than fun even if you find some doc about how to do it. Performance issues and the unpredictable builds are bad problems. I have a few practises somewhat counter to maven core concepts like “never depend on a snapshot” and “don’t let maven download stuff”. But in spite of them I choose to use maven whenever I can. Also I really agree with the convetion over configuration policy. I will gladly adhere to a directory structure convention if it means that i get my .war packaged wihtout having to know how to package a .war.

We have about the same opinions regarding what is great with maven. In my list of things that are good about maven I would not have mentioned all the plugins (3) because the docs are so hopeless I usually give up when I try to find a plugin that could help me in any specific case. I just use tiny subset but it’s enough for me.

My list of things that need improving in a build tool would be somewhat different. I do not feel that troubleshooting errors in maven is much of a problem, typically my build will fail due to errors in my tests or my dependencies and that information is displayed well enough for me. Sub par docs are not really a problem with maven but rather with the plugin developers who don’t bother to write usable docs. Maven is slow, yeah maybe so, if a new tool was faster and equally good I would use it.

Number three, verbose configs, is something I would like to see improved. Usable docs would mitigate some of the problem but perhaps plugins could be configured in seperate files imported by a main “pom” to keep things apart and small enough to take in easily. Perhaps there can be a golden convention for how plugins are configured and a way to make it easy to document plugins.

The fourth point (and it’s close relative number six) would be a real USP. If you can resolve dependency versions in some way and provide deterministic build results I could quit with my policies of “never depend on a snapshot” and “don’t let maven download stuff”.

My worry would be that it is an impossible task. Two 3rd party tools could both introduce transitive dependencies on some common tool but different versions. Each of them may or may not be compatible with the other version but how would you know? At best you could announce a dependency conflict and force the developer to make an epxlicit decision (but hey that’s a great idea!). If you have stated that you want to use a snapshot version of something you have said “I will accept that my build may fail due to something someone elses does whenever he wants to” and that’s not going to change.

I see two other major issues, the first being your first objective. Interoperability with existing maven repos is probably required which means you have to parse and understand maven poms for transitive dep resolution. Also you will have to generate valid maven poms for your own components. Unless you intend to publish things into the maven repos that are not maven compatible (lots of bad karma there) you would have to generate maven poms that can actually build your project (not just resolve dependencies) using standard maven. This only really counts if you publish the source but a build tool should not exclude the open source option.

The other thing would be IDE integration. Perhaps that can be left up to a comunity of plugin devs but before I make a switch it must load in my eclipse at least as well as my maven project does before I will consider the tool.

Finally I have one imoprtant feature that I think needs to be on the list of objectives which is a SCM connection branching and releasing capability in line with what maven can do.

I definitely agree with your comments about the frustration of duplicated library inclusions – it’s not an easy thing to “fix”, but alleviating the problem should ideally be much easier than it is today using Maven.

IMO one of the biggest issues are low-quality POMs for transitive dependencies and a lack of canonical naming for certain libraries, leading to dependency bloat as you note in point 4. The latter may be a holdover from the initial migration from Maven 1 to Maven 2 when the naming conventions changed, but finding that the same library is included N times through different groupIds and artifactIds is frustrating. And finding libraries that are either part of the JDK now (like Xalan and Xerces) or put of the runtime environment (like the servlet API) is frustrating.

So in your improved build tool, acknowledging these issues and permitting some kind of convenient mechanism for globally eradicating certain dependencies would be great.

As you note in point 6, the lack of determinism is problematic. Anytime you have to suggest to a developer who is having build issues to “try it again” is pretty broken.

Do you have any experience with some of the build tools listed here?: http://www.streamhead.com/maven-alternatives/ buildr looks especially compelling and might meet some of your objectives.

Tim