So, it’s Friday evening, and all I’m left to do if fix our generated
We’re using the Maven Remote Resources Plugin to generate all sorts of files, like a
NOTICE.txt and a
The Notice file is supposed to contain a list of all other software used by the one in which the file is built; typically, libraries, etc. It is meant to say who wrote that software, what license it’s using, and provide links to all those resources.
Now, we realized a couple months ago that this in fact did not output the expected URLs in all cases. Here’s an example:
This product includes/uses software(s) developed by 'Magnolia International Ltd.' (http://www.magnolia-cms.com) - magnolia-core (http://www.magnolia-cms.com/magnolia-core) License: GPLv3 (http://www.gnu.org/licenses/gpl-3.0.txt) License: Magnolia Network Agreement (http://www.magnolia-cms.com/mna.html) - magnolia-gui (http://www.magnolia-cms.com/magnolia-gui) License: GPLv3 (http://www.gnu.org/licenses/gpl-3.0.txt) License: Magnolia Network Agreement (http://www.magnolia-cms.com/mna.html)
And what I’ve been spending the last couple of hours fighting, is those two completely bogus URLs to magnolia-core and magnolia-gui. They don’t exist. They’re certainly not referenced as such in our POM files. So what’s going on ?
The template looked something like this: (in typical cringe-worthy Velocity style)
This product includes/uses software(s) developed by '$organizationName.name'#if($organizationName.url) ($organizationName.url)#end #foreach ( $project in $projectsSortedByOrganization.get( $organizationName ) ) - $project.name#if ($addVersion) (version $project.version)#end#if ($addArtifact) ($project.artifact)#end#if($project.url) ($project.url)#end
… followed by another nested loop for the license(s) under which said software is available. It’s pretty much exactly the sample template provided in Maven’s documentation (or somewhere where I’ve copied it from anyway. I’ll be bothered some other day to remember where and link it here if anybody cares)
The POM files of
magnolia-gui do not define a
<url> element. But their parent POM does, and it has the
For some reason, Maven decided that it was a good idea to manipulate the url when parsing/processing the models, and so it goes ahead and appends the artifactId to a
<url> defined in a parent POM. If it’s defined more levels up, you end up with completely irrelevant URLs like
I’ve been told that this URL is used by the site plugin in some context. It seems nobody knows exactly why it’s the way it is; I don’t see why anything specific to generating Maven sites (which are essentially just a bunch of ugly reports that are really only “useful” to developers) should have to do with my project‘s model. Oh and I tried with Maven 3, it’s still the same – but is the site plugin working with Maven 3 now ? Anyhow. Not here to rent.
I figured that the
project object, which is available in the Velocity template used to generate the file, has a
originalModel variable. So by going up the stack of parents, one can find the “real” URL of the model. I’m pretty sure that’d have been trivial in Java, and I wouldn’t even have felt the need to tweet about this tiny frustrating experience.
But I had to translate that in a f*&%+£$! Velocity template. Luckily, I don’t think I’m going to get blamed for venting, so I did vent, in the form of a long comment that’s probably twice as long as the already unnecessary long “macro” I had to write. See for yourself.
Rant over. Time for the week-end !