You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <ca...@gmail.com> on 2007/03/29 19:50:16 UTC
[vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
This is the second attempt, after fixing:
* http://jira.codehaus.org/browse/MASSEMBLY-155
* http://jira.codehaus.org/browse/MASSEMBLY-192
* [file and directory mode parsing]
WRT mode parsing, everything is now parsed using Integer.parseInt( mode, 8
). If this results in a NumberFormatException, that is wrapped in an
AssemblyFormattingException that indicates that it was a file/dir mode that
failed to parse. If the parse succeeds, the resulting mode int is checked
for sanity. That is, cases where group|world have perms that the user
doesn't, or cases where world has perms that the group doesn't (as in,
user:rx, group:rwx, world: rx). This could still break builds where a mode
is specified in decimal, but at least there should be some indication of
what went wrong...and now they'll know that we're trying to do the right
thing. Also, all of the mode parsing has been consolidated into
TypeConversionUtils, with a TypeConversionUtilsTest to check my work.
Finally, for MASSEMBLY-155, there is a new integration test that verifies
its behavior.
So, let's try this again:
I wanted to call a vote to release a beta version of the new assembly
plugin. There are still some outstanding issues (though not as many as jira
would have you believe; they just need tests), but I think we're at around
95-99% backward compatibility and the new features seem to be working well.
It's been just sitting in SVN for quite awhile now, and many people are
using it directly from there. I'd like to provide better support for those
people, and start getting more feedback on exactly what's still broken.
The change list is pretty large, but is mainly concerned with refactoring
the plugin away from the old monolithic approach to one that uses phases to
handle the different descriptor sections, along with common task classes to
handle behavior shared between phases.
Road Map:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=12617
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1
Staging repository:
http://people.apache.org/~jdcasey/stage/repo<http://people.apache.org/%7Ejdcasey/stage/repo>
So, let's try 72h +1/+0/-1. Please cast your votes!
Here's my +1.
-john
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by Eric Redmond <er...@gmail.com>.
+1
On 3/29/07, John Casey <ca...@gmail.com> wrote:
>
> This is the second attempt, after fixing:
>
> * http://jira.codehaus.org/browse/MASSEMBLY-155
> * http://jira.codehaus.org/browse/MASSEMBLY-192
> * [file and directory mode parsing]
>
> WRT mode parsing, everything is now parsed using Integer.parseInt( mode, 8
> ). If this results in a NumberFormatException, that is wrapped in an
> AssemblyFormattingException that indicates that it was a file/dir mode
> that
> failed to parse. If the parse succeeds, the resulting mode int is checked
> for sanity. That is, cases where group|world have perms that the user
> doesn't, or cases where world has perms that the group doesn't (as in,
> user:rx, group:rwx, world: rx). This could still break builds where a mode
> is specified in decimal, but at least there should be some indication of
> what went wrong...and now they'll know that we're trying to do the right
> thing. Also, all of the mode parsing has been consolidated into
> TypeConversionUtils, with a TypeConversionUtilsTest to check my work.
> Finally, for MASSEMBLY-155, there is a new integration test that verifies
> its behavior.
>
>
> So, let's try this again:
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many as
> jira
> would have you believe; they just need tests), but I think we're at around
> 95-99% backward compatibility and the new features seem to be working
> well.
> It's been just sitting in SVN for quite awhile now, and many people are
> using it directly from there. I'd like to provide better support for those
> people, and start getting more feedback on exactly what's still broken.
>
> The change list is pretty large, but is mainly concerned with refactoring
> the plugin away from the old monolithic approach to one that uses phases
> to
> handle the different descriptor sections, along with common task classes
> to
> handle behavior shared between phases.
>
> Road Map:
>
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=12617
>
>
> Tag:
>
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo<
> http://people.apache.org/%7Ejdcasey/stage/repo>
>
> So, let's try 72h +1/+0/-1. Please cast your votes!
>
> Here's my +1.
>
> -john
>
--
Eric Redmond
http://codehaus.org/~eredmond
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by Stephane Nicoll <st...@gmail.com>.
Thanks John for this.
Is there anything left to process the beta-1 release?
Thanks,
Stéphane
On 4/5/07, John Casey <ca...@gmail.com> wrote:
> yeah, I'm sure I deployed with the wrong version of maven. :(
>
> I'll fix and redeploy.
>
> -john
>
> On 4/5/07, Brett Porter <br...@apache.org> wrote:
> >
> > I now get:
> >
> > [INFO] Internal error in the plugin manager executing goal
> > 'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-1:single':
> > Unable to find the mojo 'org.apache.maven.plugins:maven-assembly-
> > plugin:2.2-beta-1:single' in the plugin
> > 'org.apache.maven.plugins:maven-assembly-plugin'
> > Component descriptor cannot be found in the component repository:
> > org.codehaus.plexus.archiver.manager.ArchiverManagerdefault.
> >
> >
> > Could this be related to plexus-container version? Same result on
> > 2.0.4, 2.0.5 and 2.0.6 for me. I don't declare any plexus-archiver
> > dependencyManagement (I don't specify p-archiver anywhere).
> >
> > - Brett
> >
> > On 04/04/2007, at 2:12 AM, John Casey wrote:
> >
> > > Ok, I've fixed MASSEMBLY-194, and put a new test in place to verify
> > > it.
> > > However, I cannot get Continuum to build from trunk, so I'm unable
> > > to build
> > > your attached test project. I'm currently merging the fix over to the
> > > 2.2-beta-1 tag, then I'll push up a new RC to my people.a.o account. I
> > > should be done in around ten minutes or so.
> > >
> > > -john
> > >
> > > On 3/30/07, Brett Porter <br...@apache.org> wrote:
> > >>
> > >> I did some further investigation. While there may be a memory leak,
> > >> it could well be a case of it always having been there so that is
> > >> worth separate investigation. I did hook yourkit up to it and didn't
> > >> see anything in particular that might be a culprit.
> > >>
> > >> However, the reason I'm seeing the problem is this: http://
> > >> jira.codehaus.org/browse/MASSEMBLY-194
> > >>
> > >> It's actually a functionality regression when you include unpacked
> > >> dependencies in your assembly. A test project is attached that
> > >> demonstrates it. It takes about 13s on 2.1, and 1m 30s on 2.2-beta-1
> > >> (and is triple the size on output).
> > >>
> > >> So, it looks like the 155 fix can go back in, but I think this
> > >> regression needs fixing before release.
> > >>
> > >> Thanks!
> > >>
> > >> Cheers,
> > >> Brett
> > >>
> > >> On 31/03/2007, at 11:40 AM, Brett Porter wrote:
> > >>
> > >> > No dice :( I made sure to delete the copy from my local repo so it
> > >> > was downloaded again.
> > >> >
> > >> > I checked the build order, and you were right - the CCE blew it up
> > >> > before it got to the problem spot.
> > >> >
> > >> > I'll try and come up with a test case for you.
> > >> >
> > >> > - Brett
> > >> >
> > >> > On 31/03/2007, at 2:32 AM, John Casey wrote:
> > >> >
> > >> >> Unfortunately, it wasn't that simple. I had actually combined two
> > >> >> merges in
> > >> >> a single commit to the beta-1 tag...a no-no, I know, but it's
> > >> >> fixed now.
> > >> >> I've put the newest deployment that excludes MASSEMBLY-155 out
> > >> on my
> > >> >> people.a.o acct, for your perusal.
> > >> >>
> > >> >> Let me know what you find out, and thanks for checking this so
> > >> >> thoroughly.
> > >> >>
> > >> >> -john
> > >> >>
> > >> >> On 3/30/07, Brett Porter <br...@apache.org> wrote:
> > >> >>>
> > >> >>>
> > >> >>> On 31/03/2007, at 12:43 AM, John Casey wrote:
> > >> >>>
> > >> >>> > I'll try rolling out the MASSEMBLY-155 fix, just to see if that
> > >> >>> > makes a
> > >> >>> > difference. I can't imagine the ClassCastException fix or the
> > >> >>> file-
> > >> >>> > mode
> > >> >>> > processing chewing up much, though.
> > >> >>> >
> > >> >>> > Brett: Is it possible that you weren't running out of memory
> > >> >>> > previously
> > >> >>> > *because* of the CCE?
> > >> >>>
> > >> >>> I'd need to check the build order, but that's entirely possible -
> > >> >>> good point :)
> > >> >>>
> > >> >>> I'll try it again tomorrow - if you want to point me at a rev# to
> > >> >>> rollback I'm happy to do so to avoid you having to muck around
> > >> with
> > >> >>> deployments.
> > >> >>>
> > >> >>> Thanks for your patience...
> > >> >>>
> > >> >>> Cheers,
> > >> >>> Brett
> > >> >>>
> > >> >>>
> > >> >>>
> > >> --------------------------------------------------------------------
> > >> >>> -
> > >> >>> 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
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by John Casey <ca...@gmail.com>.
yeah, I'm sure I deployed with the wrong version of maven. :(
I'll fix and redeploy.
-john
On 4/5/07, Brett Porter <br...@apache.org> wrote:
>
> I now get:
>
> [INFO] Internal error in the plugin manager executing goal
> 'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-1:single':
> Unable to find the mojo 'org.apache.maven.plugins:maven-assembly-
> plugin:2.2-beta-1:single' in the plugin
> 'org.apache.maven.plugins:maven-assembly-plugin'
> Component descriptor cannot be found in the component repository:
> org.codehaus.plexus.archiver.manager.ArchiverManagerdefault.
>
>
> Could this be related to plexus-container version? Same result on
> 2.0.4, 2.0.5 and 2.0.6 for me. I don't declare any plexus-archiver
> dependencyManagement (I don't specify p-archiver anywhere).
>
> - Brett
>
> On 04/04/2007, at 2:12 AM, John Casey wrote:
>
> > Ok, I've fixed MASSEMBLY-194, and put a new test in place to verify
> > it.
> > However, I cannot get Continuum to build from trunk, so I'm unable
> > to build
> > your attached test project. I'm currently merging the fix over to the
> > 2.2-beta-1 tag, then I'll push up a new RC to my people.a.o account. I
> > should be done in around ten minutes or so.
> >
> > -john
> >
> > On 3/30/07, Brett Porter <br...@apache.org> wrote:
> >>
> >> I did some further investigation. While there may be a memory leak,
> >> it could well be a case of it always having been there so that is
> >> worth separate investigation. I did hook yourkit up to it and didn't
> >> see anything in particular that might be a culprit.
> >>
> >> However, the reason I'm seeing the problem is this: http://
> >> jira.codehaus.org/browse/MASSEMBLY-194
> >>
> >> It's actually a functionality regression when you include unpacked
> >> dependencies in your assembly. A test project is attached that
> >> demonstrates it. It takes about 13s on 2.1, and 1m 30s on 2.2-beta-1
> >> (and is triple the size on output).
> >>
> >> So, it looks like the 155 fix can go back in, but I think this
> >> regression needs fixing before release.
> >>
> >> Thanks!
> >>
> >> Cheers,
> >> Brett
> >>
> >> On 31/03/2007, at 11:40 AM, Brett Porter wrote:
> >>
> >> > No dice :( I made sure to delete the copy from my local repo so it
> >> > was downloaded again.
> >> >
> >> > I checked the build order, and you were right - the CCE blew it up
> >> > before it got to the problem spot.
> >> >
> >> > I'll try and come up with a test case for you.
> >> >
> >> > - Brett
> >> >
> >> > On 31/03/2007, at 2:32 AM, John Casey wrote:
> >> >
> >> >> Unfortunately, it wasn't that simple. I had actually combined two
> >> >> merges in
> >> >> a single commit to the beta-1 tag...a no-no, I know, but it's
> >> >> fixed now.
> >> >> I've put the newest deployment that excludes MASSEMBLY-155 out
> >> on my
> >> >> people.a.o acct, for your perusal.
> >> >>
> >> >> Let me know what you find out, and thanks for checking this so
> >> >> thoroughly.
> >> >>
> >> >> -john
> >> >>
> >> >> On 3/30/07, Brett Porter <br...@apache.org> wrote:
> >> >>>
> >> >>>
> >> >>> On 31/03/2007, at 12:43 AM, John Casey wrote:
> >> >>>
> >> >>> > I'll try rolling out the MASSEMBLY-155 fix, just to see if that
> >> >>> > makes a
> >> >>> > difference. I can't imagine the ClassCastException fix or the
> >> >>> file-
> >> >>> > mode
> >> >>> > processing chewing up much, though.
> >> >>> >
> >> >>> > Brett: Is it possible that you weren't running out of memory
> >> >>> > previously
> >> >>> > *because* of the CCE?
> >> >>>
> >> >>> I'd need to check the build order, but that's entirely possible -
> >> >>> good point :)
> >> >>>
> >> >>> I'll try it again tomorrow - if you want to point me at a rev# to
> >> >>> rollback I'm happy to do so to avoid you having to muck around
> >> with
> >> >>> deployments.
> >> >>>
> >> >>> Thanks for your patience...
> >> >>>
> >> >>> Cheers,
> >> >>> Brett
> >> >>>
> >> >>>
> >> >>>
> >> --------------------------------------------------------------------
> >> >>> -
> >> >>> 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
> >>
> >> ---------------------------------------------------------------------
> >> 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: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by Brett Porter <br...@apache.org>.
I now get:
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-1:single':
Unable to find the mojo 'org.apache.maven.plugins:maven-assembly-
plugin:2.2-beta-1:single' in the plugin
'org.apache.maven.plugins:maven-assembly-plugin'
Component descriptor cannot be found in the component repository:
org.codehaus.plexus.archiver.manager.ArchiverManagerdefault.
Could this be related to plexus-container version? Same result on
2.0.4, 2.0.5 and 2.0.6 for me. I don't declare any plexus-archiver
dependencyManagement (I don't specify p-archiver anywhere).
- Brett
On 04/04/2007, at 2:12 AM, John Casey wrote:
> Ok, I've fixed MASSEMBLY-194, and put a new test in place to verify
> it.
> However, I cannot get Continuum to build from trunk, so I'm unable
> to build
> your attached test project. I'm currently merging the fix over to the
> 2.2-beta-1 tag, then I'll push up a new RC to my people.a.o account. I
> should be done in around ten minutes or so.
>
> -john
>
> On 3/30/07, Brett Porter <br...@apache.org> wrote:
>>
>> I did some further investigation. While there may be a memory leak,
>> it could well be a case of it always having been there so that is
>> worth separate investigation. I did hook yourkit up to it and didn't
>> see anything in particular that might be a culprit.
>>
>> However, the reason I'm seeing the problem is this: http://
>> jira.codehaus.org/browse/MASSEMBLY-194
>>
>> It's actually a functionality regression when you include unpacked
>> dependencies in your assembly. A test project is attached that
>> demonstrates it. It takes about 13s on 2.1, and 1m 30s on 2.2-beta-1
>> (and is triple the size on output).
>>
>> So, it looks like the 155 fix can go back in, but I think this
>> regression needs fixing before release.
>>
>> Thanks!
>>
>> Cheers,
>> Brett
>>
>> On 31/03/2007, at 11:40 AM, Brett Porter wrote:
>>
>> > No dice :( I made sure to delete the copy from my local repo so it
>> > was downloaded again.
>> >
>> > I checked the build order, and you were right - the CCE blew it up
>> > before it got to the problem spot.
>> >
>> > I'll try and come up with a test case for you.
>> >
>> > - Brett
>> >
>> > On 31/03/2007, at 2:32 AM, John Casey wrote:
>> >
>> >> Unfortunately, it wasn't that simple. I had actually combined two
>> >> merges in
>> >> a single commit to the beta-1 tag...a no-no, I know, but it's
>> >> fixed now.
>> >> I've put the newest deployment that excludes MASSEMBLY-155 out
>> on my
>> >> people.a.o acct, for your perusal.
>> >>
>> >> Let me know what you find out, and thanks for checking this so
>> >> thoroughly.
>> >>
>> >> -john
>> >>
>> >> On 3/30/07, Brett Porter <br...@apache.org> wrote:
>> >>>
>> >>>
>> >>> On 31/03/2007, at 12:43 AM, John Casey wrote:
>> >>>
>> >>> > I'll try rolling out the MASSEMBLY-155 fix, just to see if that
>> >>> > makes a
>> >>> > difference. I can't imagine the ClassCastException fix or the
>> >>> file-
>> >>> > mode
>> >>> > processing chewing up much, though.
>> >>> >
>> >>> > Brett: Is it possible that you weren't running out of memory
>> >>> > previously
>> >>> > *because* of the CCE?
>> >>>
>> >>> I'd need to check the build order, but that's entirely possible -
>> >>> good point :)
>> >>>
>> >>> I'll try it again tomorrow - if you want to point me at a rev# to
>> >>> rollback I'm happy to do so to avoid you having to muck around
>> with
>> >>> deployments.
>> >>>
>> >>> Thanks for your patience...
>> >>>
>> >>> Cheers,
>> >>> Brett
>> >>>
>> >>>
>> >>>
>> --------------------------------------------------------------------
>> >>> -
>> >>> 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
>>
>> ---------------------------------------------------------------------
>> 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: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by John Casey <ca...@gmail.com>.
Ok, I've fixed MASSEMBLY-194, and put a new test in place to verify it.
However, I cannot get Continuum to build from trunk, so I'm unable to build
your attached test project. I'm currently merging the fix over to the
2.2-beta-1 tag, then I'll push up a new RC to my people.a.o account. I
should be done in around ten minutes or so.
-john
On 3/30/07, Brett Porter <br...@apache.org> wrote:
>
> I did some further investigation. While there may be a memory leak,
> it could well be a case of it always having been there so that is
> worth separate investigation. I did hook yourkit up to it and didn't
> see anything in particular that might be a culprit.
>
> However, the reason I'm seeing the problem is this: http://
> jira.codehaus.org/browse/MASSEMBLY-194
>
> It's actually a functionality regression when you include unpacked
> dependencies in your assembly. A test project is attached that
> demonstrates it. It takes about 13s on 2.1, and 1m 30s on 2.2-beta-1
> (and is triple the size on output).
>
> So, it looks like the 155 fix can go back in, but I think this
> regression needs fixing before release.
>
> Thanks!
>
> Cheers,
> Brett
>
> On 31/03/2007, at 11:40 AM, Brett Porter wrote:
>
> > No dice :( I made sure to delete the copy from my local repo so it
> > was downloaded again.
> >
> > I checked the build order, and you were right - the CCE blew it up
> > before it got to the problem spot.
> >
> > I'll try and come up with a test case for you.
> >
> > - Brett
> >
> > On 31/03/2007, at 2:32 AM, John Casey wrote:
> >
> >> Unfortunately, it wasn't that simple. I had actually combined two
> >> merges in
> >> a single commit to the beta-1 tag...a no-no, I know, but it's
> >> fixed now.
> >> I've put the newest deployment that excludes MASSEMBLY-155 out on my
> >> people.a.o acct, for your perusal.
> >>
> >> Let me know what you find out, and thanks for checking this so
> >> thoroughly.
> >>
> >> -john
> >>
> >> On 3/30/07, Brett Porter <br...@apache.org> wrote:
> >>>
> >>>
> >>> On 31/03/2007, at 12:43 AM, John Casey wrote:
> >>>
> >>> > I'll try rolling out the MASSEMBLY-155 fix, just to see if that
> >>> > makes a
> >>> > difference. I can't imagine the ClassCastException fix or the
> >>> file-
> >>> > mode
> >>> > processing chewing up much, though.
> >>> >
> >>> > Brett: Is it possible that you weren't running out of memory
> >>> > previously
> >>> > *because* of the CCE?
> >>>
> >>> I'd need to check the build order, but that's entirely possible -
> >>> good point :)
> >>>
> >>> I'll try it again tomorrow - if you want to point me at a rev# to
> >>> rollback I'm happy to do so to avoid you having to muck around with
> >>> deployments.
> >>>
> >>> Thanks for your patience...
> >>>
> >>> Cheers,
> >>> Brett
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by Brett Porter <br...@apache.org>.
I did some further investigation. While there may be a memory leak,
it could well be a case of it always having been there so that is
worth separate investigation. I did hook yourkit up to it and didn't
see anything in particular that might be a culprit.
However, the reason I'm seeing the problem is this: http://
jira.codehaus.org/browse/MASSEMBLY-194
It's actually a functionality regression when you include unpacked
dependencies in your assembly. A test project is attached that
demonstrates it. It takes about 13s on 2.1, and 1m 30s on 2.2-beta-1
(and is triple the size on output).
So, it looks like the 155 fix can go back in, but I think this
regression needs fixing before release.
Thanks!
Cheers,
Brett
On 31/03/2007, at 11:40 AM, Brett Porter wrote:
> No dice :( I made sure to delete the copy from my local repo so it
> was downloaded again.
>
> I checked the build order, and you were right - the CCE blew it up
> before it got to the problem spot.
>
> I'll try and come up with a test case for you.
>
> - Brett
>
> On 31/03/2007, at 2:32 AM, John Casey wrote:
>
>> Unfortunately, it wasn't that simple. I had actually combined two
>> merges in
>> a single commit to the beta-1 tag...a no-no, I know, but it's
>> fixed now.
>> I've put the newest deployment that excludes MASSEMBLY-155 out on my
>> people.a.o acct, for your perusal.
>>
>> Let me know what you find out, and thanks for checking this so
>> thoroughly.
>>
>> -john
>>
>> On 3/30/07, Brett Porter <br...@apache.org> wrote:
>>>
>>>
>>> On 31/03/2007, at 12:43 AM, John Casey wrote:
>>>
>>> > I'll try rolling out the MASSEMBLY-155 fix, just to see if that
>>> > makes a
>>> > difference. I can't imagine the ClassCastException fix or the
>>> file-
>>> > mode
>>> > processing chewing up much, though.
>>> >
>>> > Brett: Is it possible that you weren't running out of memory
>>> > previously
>>> > *because* of the CCE?
>>>
>>> I'd need to check the build order, but that's entirely possible -
>>> good point :)
>>>
>>> I'll try it again tomorrow - if you want to point me at a rev# to
>>> rollback I'm happy to do so to avoid you having to muck around with
>>> deployments.
>>>
>>> Thanks for your patience...
>>>
>>> Cheers,
>>> Brett
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by Brett Porter <br...@apache.org>.
No dice :( I made sure to delete the copy from my local repo so it
was downloaded again.
I checked the build order, and you were right - the CCE blew it up
before it got to the problem spot.
I'll try and come up with a test case for you.
- Brett
On 31/03/2007, at 2:32 AM, John Casey wrote:
> Unfortunately, it wasn't that simple. I had actually combined two
> merges in
> a single commit to the beta-1 tag...a no-no, I know, but it's fixed
> now.
> I've put the newest deployment that excludes MASSEMBLY-155 out on my
> people.a.o acct, for your perusal.
>
> Let me know what you find out, and thanks for checking this so
> thoroughly.
>
> -john
>
> On 3/30/07, Brett Porter <br...@apache.org> wrote:
>>
>>
>> On 31/03/2007, at 12:43 AM, John Casey wrote:
>>
>> > I'll try rolling out the MASSEMBLY-155 fix, just to see if that
>> > makes a
>> > difference. I can't imagine the ClassCastException fix or the file-
>> > mode
>> > processing chewing up much, though.
>> >
>> > Brett: Is it possible that you weren't running out of memory
>> > previously
>> > *because* of the CCE?
>>
>> I'd need to check the build order, but that's entirely possible -
>> good point :)
>>
>> I'll try it again tomorrow - if you want to point me at a rev# to
>> rollback I'm happy to do so to avoid you having to muck around with
>> deployments.
>>
>> Thanks for your patience...
>>
>> Cheers,
>> Brett
>>
>>
>> ---------------------------------------------------------------------
>> 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: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by John Casey <ca...@gmail.com>.
Unfortunately, it wasn't that simple. I had actually combined two merges in
a single commit to the beta-1 tag...a no-no, I know, but it's fixed now.
I've put the newest deployment that excludes MASSEMBLY-155 out on my
people.a.o acct, for your perusal.
Let me know what you find out, and thanks for checking this so thoroughly.
-john
On 3/30/07, Brett Porter <br...@apache.org> wrote:
>
>
> On 31/03/2007, at 12:43 AM, John Casey wrote:
>
> > I'll try rolling out the MASSEMBLY-155 fix, just to see if that
> > makes a
> > difference. I can't imagine the ClassCastException fix or the file-
> > mode
> > processing chewing up much, though.
> >
> > Brett: Is it possible that you weren't running out of memory
> > previously
> > *because* of the CCE?
>
> I'd need to check the build order, but that's entirely possible -
> good point :)
>
> I'll try it again tomorrow - if you want to point me at a rev# to
> rollback I'm happy to do so to avoid you having to muck around with
> deployments.
>
> Thanks for your patience...
>
> Cheers,
> Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by Brett Porter <br...@apache.org>.
On 31/03/2007, at 12:43 AM, John Casey wrote:
> I'll try rolling out the MASSEMBLY-155 fix, just to see if that
> makes a
> difference. I can't imagine the ClassCastException fix or the file-
> mode
> processing chewing up much, though.
>
> Brett: Is it possible that you weren't running out of memory
> previously
> *because* of the CCE?
I'd need to check the build order, but that's entirely possible -
good point :)
I'll try it again tomorrow - if you want to point me at a rev# to
rollback I'm happy to do so to avoid you having to muck around with
deployments.
Thanks for your patience...
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by John Casey <ca...@gmail.com>.
I'll try rolling out the MASSEMBLY-155 fix, just to see if that makes a
difference. I can't imagine the ClassCastException fix or the file-mode
processing chewing up much, though.
Brett: Is it possible that you weren't running out of memory previously
*because* of the CCE?
-john
On 3/30/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
> I imagine the fix for MASSEMBLY-155 might cause the archiver to use a
> little more memory. I would imagine though that if the excludes weren't
> used, the fix wouldn't have an impact.
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: Friday, March 30, 2007 1:36 AM
> To: Maven Developers List
> Subject: Re: [vote] Attempt 2: Release 2.2-beta-1 of
> maven-assembly-plugin
>
> John,
>
> I'm building a >100mb assembly and the build is blowing up with an
> OOME. I upped the limit to 128m and instead of that problem it
> completely hangs down the track (kill -9). I'm trying again with 256m
> now.
>
> If I build with 2.1 again, there are no problems. I am able to switch
> back and forth and get consistent results: dead with 2.2, fine with
> 2.1. Oddly, though, I had no such problems with 2.2 yesterday.
>
> Did anything change overnight that might leak memory?
>
> - Brett
>
> On 30/03/2007, at 3:50 AM, John Casey wrote:
>
> > This is the second attempt, after fixing:
> >
> > * http://jira.codehaus.org/browse/MASSEMBLY-155
> > * http://jira.codehaus.org/browse/MASSEMBLY-192
> > * [file and directory mode parsing]
> >
> > WRT mode parsing, everything is now parsed using Integer.parseInt
> > ( mode, 8
> > ). If this results in a NumberFormatException, that is wrapped in an
> > AssemblyFormattingException that indicates that it was a file/dir
> > mode that
> > failed to parse. If the parse succeeds, the resulting mode int is
> > checked
> > for sanity. That is, cases where group|world have perms that the user
> > doesn't, or cases where world has perms that the group doesn't (as in,
> > user:rx, group:rwx, world: rx). This could still break builds where
> > a mode
> > is specified in decimal, but at least there should be some
> > indication of
> > what went wrong...and now they'll know that we're trying to do the
> > right
> > thing. Also, all of the mode parsing has been consolidated into
> > TypeConversionUtils, with a TypeConversionUtilsTest to check my work.
> > Finally, for MASSEMBLY-155, there is a new integration test that
> > verifies
> > its behavior.
> >
> >
> > So, let's try this again:
> >
> > I wanted to call a vote to release a beta version of the new assembly
> > plugin. There are still some outstanding issues (though not as many
> > as jira
> > would have you believe; they just need tests), but I think we're at
> > around
> > 95-99% backward compatibility and the new features seem to be
> > working well.
> > It's been just sitting in SVN for quite awhile now, and many people
> > are
> > using it directly from there. I'd like to provide better support
> > for those
> > people, and start getting more feedback on exactly what's still
> > broken.
> >
> > The change list is pretty large, but is mainly concerned with
> > refactoring
> > the plugin away from the old monolithic approach to one that uses
> > phases to
> > handle the different descriptor sections, along with common task
> > classes to
> > handle behavior shared between phases.
> >
> > Road Map:
> >
> > http://jira.codehaus.org/secure/ReleaseNote.jspa?
> > projectId=11126&styleName=Html&version=12617
> >
> >
> > Tag:
> >
> > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-
> > plugin-2.2-beta-1
> >
> > Staging repository:
> >
> > http://people.apache.org/~jdcasey/stage/repo<http://
> > people.apache.org/%7Ejdcasey/stage/repo>
> >
> > So, let's try 72h +1/+0/-1. Please cast your votes!
> >
> > Here's my +1.
> >
> > -john
>
> ---------------------------------------------------------------------
> 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: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I imagine the fix for MASSEMBLY-155 might cause the archiver to use a
little more memory. I would imagine though that if the excludes weren't
used, the fix wouldn't have an impact.
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Friday, March 30, 2007 1:36 AM
To: Maven Developers List
Subject: Re: [vote] Attempt 2: Release 2.2-beta-1 of
maven-assembly-plugin
John,
I'm building a >100mb assembly and the build is blowing up with an
OOME. I upped the limit to 128m and instead of that problem it
completely hangs down the track (kill -9). I'm trying again with 256m
now.
If I build with 2.1 again, there are no problems. I am able to switch
back and forth and get consistent results: dead with 2.2, fine with
2.1. Oddly, though, I had no such problems with 2.2 yesterday.
Did anything change overnight that might leak memory?
- Brett
On 30/03/2007, at 3:50 AM, John Casey wrote:
> This is the second attempt, after fixing:
>
> * http://jira.codehaus.org/browse/MASSEMBLY-155
> * http://jira.codehaus.org/browse/MASSEMBLY-192
> * [file and directory mode parsing]
>
> WRT mode parsing, everything is now parsed using Integer.parseInt
> ( mode, 8
> ). If this results in a NumberFormatException, that is wrapped in an
> AssemblyFormattingException that indicates that it was a file/dir
> mode that
> failed to parse. If the parse succeeds, the resulting mode int is
> checked
> for sanity. That is, cases where group|world have perms that the user
> doesn't, or cases where world has perms that the group doesn't (as in,
> user:rx, group:rwx, world: rx). This could still break builds where
> a mode
> is specified in decimal, but at least there should be some
> indication of
> what went wrong...and now they'll know that we're trying to do the
> right
> thing. Also, all of the mode parsing has been consolidated into
> TypeConversionUtils, with a TypeConversionUtilsTest to check my work.
> Finally, for MASSEMBLY-155, there is a new integration test that
> verifies
> its behavior.
>
>
> So, let's try this again:
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many
> as jira
> would have you believe; they just need tests), but I think we're at
> around
> 95-99% backward compatibility and the new features seem to be
> working well.
> It's been just sitting in SVN for quite awhile now, and many people
> are
> using it directly from there. I'd like to provide better support
> for those
> people, and start getting more feedback on exactly what's still
> broken.
>
> The change list is pretty large, but is mainly concerned with
> refactoring
> the plugin away from the old monolithic approach to one that uses
> phases to
> handle the different descriptor sections, along with common task
> classes to
> handle behavior shared between phases.
>
> Road Map:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?
> projectId=11126&styleName=Html&version=12617
>
>
> Tag:
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-
> plugin-2.2-beta-1
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo<http://
> people.apache.org/%7Ejdcasey/stage/repo>
>
> So, let's try 72h +1/+0/-1. Please cast your votes!
>
> Here's my +1.
>
> -john
---------------------------------------------------------------------
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: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by Brett Porter <br...@apache.org>.
John,
I'm building a >100mb assembly and the build is blowing up with an
OOME. I upped the limit to 128m and instead of that problem it
completely hangs down the track (kill -9). I'm trying again with 256m
now.
If I build with 2.1 again, there are no problems. I am able to switch
back and forth and get consistent results: dead with 2.2, fine with
2.1. Oddly, though, I had no such problems with 2.2 yesterday.
Did anything change overnight that might leak memory?
- Brett
On 30/03/2007, at 3:50 AM, John Casey wrote:
> This is the second attempt, after fixing:
>
> * http://jira.codehaus.org/browse/MASSEMBLY-155
> * http://jira.codehaus.org/browse/MASSEMBLY-192
> * [file and directory mode parsing]
>
> WRT mode parsing, everything is now parsed using Integer.parseInt
> ( mode, 8
> ). If this results in a NumberFormatException, that is wrapped in an
> AssemblyFormattingException that indicates that it was a file/dir
> mode that
> failed to parse. If the parse succeeds, the resulting mode int is
> checked
> for sanity. That is, cases where group|world have perms that the user
> doesn't, or cases where world has perms that the group doesn't (as in,
> user:rx, group:rwx, world: rx). This could still break builds where
> a mode
> is specified in decimal, but at least there should be some
> indication of
> what went wrong...and now they'll know that we're trying to do the
> right
> thing. Also, all of the mode parsing has been consolidated into
> TypeConversionUtils, with a TypeConversionUtilsTest to check my work.
> Finally, for MASSEMBLY-155, there is a new integration test that
> verifies
> its behavior.
>
>
> So, let's try this again:
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many
> as jira
> would have you believe; they just need tests), but I think we're at
> around
> 95-99% backward compatibility and the new features seem to be
> working well.
> It's been just sitting in SVN for quite awhile now, and many people
> are
> using it directly from there. I'd like to provide better support
> for those
> people, and start getting more feedback on exactly what's still
> broken.
>
> The change list is pretty large, but is mainly concerned with
> refactoring
> the plugin away from the old monolithic approach to one that uses
> phases to
> handle the different descriptor sections, along with common task
> classes to
> handle behavior shared between phases.
>
> Road Map:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?
> projectId=11126&styleName=Html&version=12617
>
>
> Tag:
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-
> plugin-2.2-beta-1
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo<http://
> people.apache.org/%7Ejdcasey/stage/repo>
>
> So, let's try 72h +1/+0/-1. Please cast your votes!
>
> Here's my +1.
>
> -john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by Stephane Nicoll <st...@gmail.com>.
+1
Stéphane
On 3/29/07, John Casey <ca...@gmail.com> wrote:
> This is the second attempt, after fixing:
>
> * http://jira.codehaus.org/browse/MASSEMBLY-155
> * http://jira.codehaus.org/browse/MASSEMBLY-192
> * [file and directory mode parsing]
>
> WRT mode parsing, everything is now parsed using Integer.parseInt( mode, 8
> ). If this results in a NumberFormatException, that is wrapped in an
> AssemblyFormattingException that indicates that it was a file/dir mode that
> failed to parse. If the parse succeeds, the resulting mode int is checked
> for sanity. That is, cases where group|world have perms that the user
> doesn't, or cases where world has perms that the group doesn't (as in,
> user:rx, group:rwx, world: rx). This could still break builds where a mode
> is specified in decimal, but at least there should be some indication of
> what went wrong...and now they'll know that we're trying to do the right
> thing. Also, all of the mode parsing has been consolidated into
> TypeConversionUtils, with a TypeConversionUtilsTest to check my work.
> Finally, for MASSEMBLY-155, there is a new integration test that verifies
> its behavior.
>
>
> So, let's try this again:
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many as jira
> would have you believe; they just need tests), but I think we're at around
> 95-99% backward compatibility and the new features seem to be working well.
> It's been just sitting in SVN for quite awhile now, and many people are
> using it directly from there. I'd like to provide better support for those
> people, and start getting more feedback on exactly what's still broken.
>
> The change list is pretty large, but is mainly concerned with refactoring
> the plugin away from the old monolithic approach to one that uses phases to
> handle the different descriptor sections, along with common task classes to
> handle behavior shared between phases.
>
> Road Map:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=12617
>
>
> Tag:
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo<http://people.apache.org/%7Ejdcasey/stage/repo>
>
> So, let's try 72h +1/+0/-1. Please cast your votes!
>
> Here's my +1.
>
> -john
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
Posted by Jason van Zyl <ja...@maven.org>.
+1
On 29 Mar 07, at 1:50 PM 29 Mar 07, John Casey wrote:
> This is the second attempt, after fixing:
>
> * http://jira.codehaus.org/browse/MASSEMBLY-155
> * http://jira.codehaus.org/browse/MASSEMBLY-192
> * [file and directory mode parsing]
>
> WRT mode parsing, everything is now parsed using Integer.parseInt
> ( mode, 8
> ). If this results in a NumberFormatException, that is wrapped in an
> AssemblyFormattingException that indicates that it was a file/dir
> mode that
> failed to parse. If the parse succeeds, the resulting mode int is
> checked
> for sanity. That is, cases where group|world have perms that the user
> doesn't, or cases where world has perms that the group doesn't (as in,
> user:rx, group:rwx, world: rx). This could still break builds where
> a mode
> is specified in decimal, but at least there should be some
> indication of
> what went wrong...and now they'll know that we're trying to do the
> right
> thing. Also, all of the mode parsing has been consolidated into
> TypeConversionUtils, with a TypeConversionUtilsTest to check my work.
> Finally, for MASSEMBLY-155, there is a new integration test that
> verifies
> its behavior.
>
>
> So, let's try this again:
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many
> as jira
> would have you believe; they just need tests), but I think we're at
> around
> 95-99% backward compatibility and the new features seem to be
> working well.
> It's been just sitting in SVN for quite awhile now, and many people
> are
> using it directly from there. I'd like to provide better support
> for those
> people, and start getting more feedback on exactly what's still
> broken.
>
> The change list is pretty large, but is mainly concerned with
> refactoring
> the plugin away from the old monolithic approach to one that uses
> phases to
> handle the different descriptor sections, along with common task
> classes to
> handle behavior shared between phases.
>
> Road Map:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?
> projectId=11126&styleName=Html&version=12617
>
>
> Tag:
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-
> plugin-2.2-beta-1
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo<http://
> people.apache.org/%7Ejdcasey/stage/repo>
>
> So, let's try 72h +1/+0/-1. Please cast your votes!
>
> Here's my +1.
>
> -john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org