Issue Details (XML | Word | Printable)

Key: MASSEMBLY-250
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: John Casey
Reporter: Grégory Joseph
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Maven 2.x Assembly Plugin

Trunk of assembly plugin broken and not in synch with deployed 2.2-beta2-SNAPSHOT ?

Created: 25/Nov/07 12:09 PM   Updated: 18/Feb/08 07:04 PM
Component/s: None
Affects Version/s: 2.2-beta-2
Fix Version/s: 2.2-beta-2

Time Tracking:
Not Specified

File Attachments: 1. File assembly-trunkbuggy.tgz (10 kB)
2. Text File MASSEMBLY-250.patch (0.8 kB)



 Description  « Hide
(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 ?



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Grégory Joseph added a comment - 26/Nov/07 07:03 AM
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 ?

Grégory Joseph added a comment - 26/Nov/07 07:27 AM
the above patch "solves" (notice the quotes), or seems to solve, the empty file issue and the multiple archives issue.

John Casey added a comment - 18/Feb/08 07:04 PM
commenting that section out worked because it was an improper time to cleanup that formatted directory. In most implementations, the archiver actually just queues up files that need to be added, until create() is called (I think that's the method name)...in any case, since we were then deleting the newly formatted directory, it wasn't there when the archiver actually went to add the files, and an empty file set was added. This was the result of some overly-ambitious cleanup code, since the assembly plugin was leaving temp files behind on the CI server.

Also, I added a new expression value-source that will handle ${pom.properties.*} on outputFileNameMapping, outputDirectory, etc.