[M1] & [M2]: 3rd party POM issues: syntax and dependency versions

[Andy Glick <an...@acm.org>]

I've noticed that the authors of a good many 3rd party POM's have used only the <id> and <version> tags when declaring dependencies. From what I can gather this was standard practice some time ago, possibly during the M1 release candidate period, but it is suboptimal today. For example, I'm using Mevenide for Idea. It offers some fairly nice GUI POM editing screens. Because the Mevenide authors expected dependency declarations to follow the current convention, with <groupId> and <artifactId> tags rather than the <id> tag, the screen displays only the version but not the names.

In other cases I've noticed that the <id> tag can be used even when the <groupId> and <artifactId> differ iff the artifactId is an hyphenated extension of the groupId using the plus sign, e.g. <id>easymock+classextension<id>. I've noticed this usage in a number of poms that refer to geronimo-spec artifacts.

Are these the kinds of "issues" that should be entered into the CodeHaus Jira in the Maven Evangelism project? How about the use of XML entities to declare versions?


About the variation in the versions of the various artifacts that are referenced in many POMs. Some years ago the Gump project was started at Apache as an effort to determine when current changes to projects were going to cause problems for other projects. It seems to me that the way that we inform each other about the compatibilities/incompatibilities of various versions of well known packages, that is by doing so in a one-off manner in individual posts, isn't the best approach.

I realize that everyone is very busy right now working on the next M1 and M2 releases, and I'm not suggesting this for the short term, but in the long run it might be useful if some tools could be built that the members of projects could use to determine the latest version of dependency X, lets say commons-collections for example, that would work with their project. This would help everyone determine where there were version inconsistencies and better allow them to schedule scarce resources to meet migration requirements. You might want to think of this as a larger grained version of Jester.

In the mean time, is it reasonable for the Maven site to construct and maintain some type of inter artifact version compatibility matrix?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org