You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "John Casey (JIRA)" <ji...@codehaus.org> on 2008/02/19 02:05:28 UTC

[jira] Closed: (MASSEMBLY-250) Trunk of assembly plugin broken and not in synch with deployed 2.2-beta2-SNAPSHOT ?

     [ http://jira.codehaus.org/browse/MASSEMBLY-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Casey closed MASSEMBLY-250.
--------------------------------

    Resolution: Fixed

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.

> 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
>            Assignee: John Casey
>             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