You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Grégory Joseph <jo...@gmail.com> on 2007/11/23 20:21:30 UTC
Trunk of assembly plugin broken and not in synch with deployed 2.2-beta2-SNAPSHOT ?
Hi,
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 ?
Thanks a bunch !
-greg
Re: Trunk of assembly plugin broken and not in synch with deployed 2.2-beta2-SNAPSHOT ?
Posted by Grégory Joseph <jo...@gmail.com>.
Yep, see jira indeed, where I uploaded a patch that somewhat
suspiciously fixes my issues.
http://jira.codehaus.org/browse/MASSEMBLY-250
Cheers
greg
On 27/11/2007, John Casey <jd...@commonjava.org> wrote:
> I don't know what would be causing this, but the jira should allow us
> to take a look. I've done most of the development on the assembly
> plugin in the past year or so, but I don't think this has anything to
> do with my changes, since I haven't committed anything on the plugin
> in a month or more...
>
> At any rate, we can track this via your JIRA.
>
> Thanks,
>
> -john
>
> On Nov 26, 2007, at 4:58 AM, Grégory Joseph wrote:
>
> > On 23/11/2007, Dennis Lundberg <de...@apache.org> wrote:
> >> Please report this in JIRA, as attachment to mailing lists have a
> >> nasty
> >> habit of being forgotten.
> >
> > Done,
> > http://jira.codehaus.org/browse/MASSEMBLY-250
> >
> > I was hoping for some preliminary discussion, so as to be able to
> > create more precise and effective reports ;)
> >
> > Cheers,
> >
> > greg
> >
> >> Grégory Joseph wrote:
> >>> Hi,
> >>>
> >>> 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 ?
> >>>
> >>> Thanks a bunch !
> >>>
> >>> -greg
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> ----
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >> --
> >> Dennis Lundberg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
> rss: http://feeds.feedburner.com/ejlife/john
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Trunk of assembly plugin broken and not in synch with deployed 2.2-beta2-SNAPSHOT ?
Posted by John Casey <jd...@commonjava.org>.
I don't know what would be causing this, but the jira should allow us
to take a look. I've done most of the development on the assembly
plugin in the past year or so, but I don't think this has anything to
do with my changes, since I haven't committed anything on the plugin
in a month or more...
At any rate, we can track this via your JIRA.
Thanks,
-john
On Nov 26, 2007, at 4:58 AM, Grégory Joseph wrote:
> On 23/11/2007, Dennis Lundberg <de...@apache.org> wrote:
>> Please report this in JIRA, as attachment to mailing lists have a
>> nasty
>> habit of being forgotten.
>
> Done,
> http://jira.codehaus.org/browse/MASSEMBLY-250
>
> I was hoping for some preliminary discussion, so as to be able to
> create more precise and effective reports ;)
>
> Cheers,
>
> greg
>
>> Grégory Joseph wrote:
>>> Hi,
>>>
>>> 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 ?
>>>
>>> Thanks a bunch !
>>>
>>> -greg
>>>
>>>
>>> --------------------------------------------------------------------
>>> ----
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> --
>> Dennis Lundberg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Re: Trunk of assembly plugin broken and not in synch with deployed 2.2-beta2-SNAPSHOT ?
Posted by Grégory Joseph <jo...@gmail.com>.
On 23/11/2007, Dennis Lundberg <de...@apache.org> wrote:
> Please report this in JIRA, as attachment to mailing lists have a nasty
> habit of being forgotten.
Done,
http://jira.codehaus.org/browse/MASSEMBLY-250
I was hoping for some preliminary discussion, so as to be able to
create more precise and effective reports ;)
Cheers,
greg
> Grégory Joseph wrote:
> > Hi,
> >
> > 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 ?
> >
> > Thanks a bunch !
> >
> > -greg
> >
> >
> > ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
> --
> Dennis Lundberg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Trunk of assembly plugin broken and not in synch with deployed
2.2-beta2-SNAPSHOT ?
Posted by Dennis Lundberg <de...@apache.org>.
Please report this in JIRA, as attachment to mailing lists have a nasty
habit of being forgotten.
http://jira.codehaus.org/browse/MASSEMBLY
Grégory Joseph wrote:
> Hi,
>
> 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 ?
>
> Thanks a bunch !
>
> -greg
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org