[ http://jira.codehaus.org/browse/MASSEMBLY-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Casey updated MASSEMBLY-250: --------------------------------- Fix Version/s: 2.2-beta-2 > Trunk of assembly plugin broken and not in synch with deployed > 2.2-beta2-SNAPSHOT ? > ------------------------------------------------------------------------------------ > > Key: MASSEMBLY-250 > URL: http://jira.codehaus.org/browse/MASSEMBLY-250 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Affects Versions: 2.2-beta-2 > Reporter: Grégory Joseph > Fix For: 2.2-beta-2 > > Attachments: assembly-trunkbuggy.tgz, MASSEMBLY-250.patch > > > (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 ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira