7 Assembly Plugin Issues, Closed
Okay, so maybe some of these had been fixed awhile back, and maybe some of them weren’t really assembly-plugin bugs (I’m really thinking of one in particular here)…but the fact remains. I was able to close 7 issues in the MASSEMBLY project today. I feel like the assembly plugin has been coming along nicely in the past several weeks, and this is just a particularly visible sign of that. Oh, and in addition to the 7 that were closed, I was able to triage all of the remaining unassigned issues into either 2.2-beta-2, 2.2, or 2.3-beta-1 buckets (except for one very hairy issue that would involve implementation code in maven-wagon, among other places). The closed issues are (drum-roll please):
If you contributed a patch to one of the above, thank you sooo much. The patches in some of these issues made life much easier for yours truly. If you didn’t provide tests with your patch or issue, shame on you! 
Even just providing a scrubbed version of the project you’re having trouble with can give us a basis from which to write an integration test, and make sure the bastard bug never rears its head again.
If you have an issue, patch, test case, or random comment that wasn’t included above…please be patient, and we’ll try to address your concerns before too much longer (understand, I say this with a broad sweep of the hands and clear thoughts of geologic timescales)…
[UPDATED] Maven Patch Day: 12 patches applied.
I’ve already applied 6 patches from JIRA today, and I’m still hunting for more to do. Here’s the list of issues I’ve already hit:
Yeah, I know…it’s but a drop in the bucket. But it’s all progress.
UPDATE: I added another 6 issues to the pile of patches applied. Most notable among these (at least for me) is a fix so that you no longer have to call Artifact.isSnapshot() in order to figure out that an artifact with version “1.0-20070812.111111-2″ has a base-version of “1.0-SNAPSHOT”. Others include:
Pin the Snapshot Dependency Versions in Your POM
Occasionally, you might want to pin the versions of snapshot dependencies in your pom.xml to the most recent unique version (referenced by timestamp/buildnumber instead of “-SNAPSHOT”). To show how easy it is to do this, I’ve written a tiny little plugin to accomplish it. You can grab it from here: http://www.commonjava.org/~jdcasey/maven-misc/plugins/snapshot-pin-maven-plugin.zip, or wait a little while, and I’ll put it in the mojo sandbox at http://mojo.codehaus.org.
Essentially, what this plugin does is ask Maven to resolve all of the current project’s dependencies (up to the test scope). From here, it re-reads the POM from file, to ensure that the instance we’re working with is clean. Then, it maps the resolved artifacts by a version-less key of groupId:artifactId, and iterates through all dependencies (even those declared in dependencyManagement in the current pom.xml) and replaces the dependency version with the resolved one, if it can find one. In some cases, the local POM may declare a managed dependency, but not use it…these may not get pinned. After everything is finished, the mojo checks whether anything has changed in the POM instance, and writes the changes to file if so.
One glaring GOTCHA in this process is a query method that changes the state inside the resolve artifact instances. This method is Artifact.isSnapshot(), and it has the critical effect of changing the output of Artifact.getVersion() from the “-SNAPSHOT” predicated string to one with the timestamp and buildnumber that was resolved earlier in the build. It truly sucks that we have to call a query method in order to expose this information, but at this point it’s legacy (released), so we do what we can to get the results we need.
If you’ve been looking for something like this, enjoy. Otherwise, thanks for tuning in anyway!
