I have enjoyed using Maven for my personal and professional projects ever since Maven exists. Maven 1 had some serious limitations and when Maven 2 was released, it was a major step forward for build quality. One of Maven 2's nice features is the dependencies being transitive. This is really great when you depend on a library to automagically get all its transitive dependencies.
This is great as long as everything you need is mavenized, but whenever you need a third party library which has not yet been mavenized, Maven won't let you use it unless it gets mavenized. This is where it gets painfull.
In Maven 1, mavenizing a library was boring but that wasn't much of a problem once you got the method. But in Maven 2, this is a different story. Maven depends on the quality of the metadata of artifacts, in particular, for transitive dependencies to work, POMs need to have their dependencies section properly filled.
If the third party library you want to mavenize doesn't depend on anything or if its dependencies are all already mavenized, then it's just a matter of filling the dependencies section with references to existing artifacts. But, if those dependencies are not mavenized, then you have a lot of work ahead and it can carry on and on for a very long time and pretty quickly, you'll get fed up (I did ...) and give up writing complete metadata.
I believe too strongly in Maven benefits to give up to anemic POMs, so I wrote Mavenizer to ease that otherwise painfull process.
Mavenizer's first goal is to ease the process of mavenizing third party libraries. Its second goal as a whole is to help enhance the overall quality of published artifacts. Some publicly available artifacts have real bad metadata.
| [top] |
Mavenizer will scan your third library's directory structure for jars and extract as much information as possible relevant for its mavenization. It will try to guess groupId, artifactId, version, dependencies for all jars found from manifests headers entries, file names and package names.
You won't have to manually open jars and look for manifest entries. Most of the time, the version is written in many places, and worse, very often they are contradictory. So you won't have to gather all those manually.
As some informations can be ambiguous or missing, the result of this analysis will be stored in a XML document. With this document, you can change informations until it you're happy with it. The XML document attempts to be human readable and attempts to make it easy to edit informations which will be spread in many places once the Maven metadata is generated. It is thus much easier to modify such informations in that central place than trying to edit a Maven repository by hand. Changing a groupId or a version of an artifact will of course be taken into account in its POM but also in the POMs of all artifacts using it.
In a future version, Mavenizer will also help you refactor jars, split them by package, remove unused classes, detect and remove duplicated classes, etc ...
| [top] |
Please see the Maven FAQ for the complete explanation.
| [top] |