Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.2-beta-2
-
Fix Version/s: 2.2-beta-2
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
(I was hoping for some preliminary discussion on the dev list, in order to trim down and split this report properly; sorry for the lengthy and varied nature of this)
I painfully discovered recently that the trunk of the assembly plugin
seems to be broken. I'd been using the snapshot (20071017.162810) from
http://people.apache.org/repo/m2-snapshot-repository happily for a
while, but since I had to do releases, I went the hardcore way and did
an internal deploy against the trunk.
I can't use the 2.2-beta-1 version because I need, amongst other
things, fileSet filtering (more on that later), and the artifact type.
Here's what I found broken with the trunk:
- I can't build multiple artifacts from the same assembly descriptor
(i.e zip and tgz), only one. This works smoothly with the
aforementioned snapshot. - Severe issue: filtering a fileSet empties these files. (0 byte in
the resulting zip or tgz). This also works nicely with the snapshot.
It only works on the trunk if I disable filtering and lineending. - Less critical : pom properties are apparently not interpolated in
assembly descriptors.
I attached a small testcase the shows the issue. Unpack it and do:
mvn clean install
unzip -l target/assembly-trunkbuggy-1.2.3-SNAPSHOT-test.zip
You should see that both copies of the test.txt file have a length of 337 bytes.
Now move your local repo away for a moment, build the trunk, comment
out the repositories in my test's pom, build it again, and you should
see that the test.txt copies in the zip are empty.
As far as I can tell, there has not been any commit since the
timestamp of the snapshot that could have an obvious impact on these
problems.
I also tried doing deploy:deploy-file with the snapshot itself, to
deploy it internally, but somehow that triggered a whole different set
of problems. (ClassNotFoundExceptions etc)
I'll happily report this on Jira, but I thought I'd poke here first,
since it doesn't seem clear how the regression could have happened. At
some point I vaguely suspected the snapshot could have been built
against uncommitted code ... ?
Can someone shed some light on this? Also, since it doesn't seem that
the plugin is ready for a beta-2 release just yet (or is it? can
anyone do it ?), could anyone assist in changing the current snapshot
dependencies it has, so I could do an internal release of it, in order
to proceed with our own releases ?
I randomly found how to fix my issue. I'm really not sure this is right at all; neither why these files had to be deleted in the first place, nor why leaving them there makes the whole thing work again... is the actual archiving of the files delayed ?