Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin (Decimal/Octal file modes issue)
Max Bowsher wrote:
John Casey wrote:
Max: I'm tempted to say that we should look for decimal versions of common
octal expressions, then prefix the rest with '0' to ensure they're
interpreted as octal (unless they have 0x in front, that is).
Is that a decent solution?
I think that it is the best compromise between maintaining the same
behaviour with existing descriptors, and fixing the bug going forward
into the future.
Would this behaviour apply to all modes in the descriptor, or just
filefileMode ? (I'd lean toward the latter).
OOI, why prepend a leading zero, rather than using Integer.parseInt(x,8)
and Integer.parseInt(x,10) as appropriate? I was thinking of something
along the lines of:
HashMap commonModes = new HashMap() {{
add(
Oh, grr. I'd really like to know how Thunderbird managed to save a
previous version than was showing when I did save-to-Drafts.
Anyway, I meant:
private static HashMap commonDecimalModes = new HashMap() {{
add(420);
add(436);
add(493);
add(509);
}}
.
if ( commonDecimalModes.contains( mode ) )
return Integer.parseInt( mode, 10 );
else
return Integer.parseInt( mode, 8 );
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] Release 2.2-beta-1 of maven-assembly-plugin (Decimal/Octal file modes issue)
Hi Max,
Max Bowsher wrote on Thursday, March 29, 2007 1:46 PM:
Max Bowsher wrote:
John Casey wrote:
Max: I'm tempted to say that we should look for decimal versions of
common octal expressions, then prefix the rest with '0' to ensure
they're interpreted as octal (unless they have 0x in front, that
is).
Is that a decent solution?
I think that it is the best compromise between maintaining the same
behaviour with existing descriptors, and fixing the bug going
forward into the future.
Would this behaviour apply to all modes in the descriptor, or just
filefileMode ? (I'd lean toward the latter).
OOI, why prepend a leading zero, rather than using
Integer.parseInt(x,8) and Integer.parseInt(x,10) as appropriate? I
was thinking of something along the lines of:
HashMap commonModes = new HashMap() {{
add(
Oh, grr. I'd really like to know how Thunderbird managed to save a
previous version than was showing when I did save-to-Drafts.
Anyway, I meant:
private static HashMap commonDecimalModes = new HashMap() {{
add(420); add(436);
add(493);
add(509);
}}
.
if ( commonDecimalModes.contains( mode ) )
return Integer.parseInt( mode, 10 );
else
return Integer.parseInt( mode, 8 );
Why not letting Java decide? It handles decimal, octal and hex values
automatically:
public Integer fromString(String str) {
long value = Long.decode(str).longValue();
if(value Integer.MIN_VALUE || value 0xl) {
throw new NumberFormatException(For input string: \ + str +
'');
}
return new Integer((int)value);
}
Note: Integer.decode(String) is not used here because it will not handle
negative hex-coded integer values. With this approach you can express -1 as
0x ...
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] Release 2.2-beta-1 of maven-assembly-plugin (Decimal/Octal file modes issue)
Max Bowsher wrote on Thursday, March 29, 2007 3:26 PM: Jörg Schaible wrote: [snip] Note: Integer.decode(String) is not used here because it will not handle negative hex-coded integer values. With this approach you can express -1 as 0x ... The whole point here is to maximize compatibility with maven-assembly-plugin-2.1 behaviour. That's why we, not Java, should be making the decision. Furthermore, we are talking about Unix permission mode bits. Neither negative values, nor hexadecimal values, are relevant. Decimal values are only relevant to the extent of supporting existing assembly descriptors written for the buggy behaviour of maven-assembly-plugin-2.1. Yep. Noticed my misplaced comment when it was already sent. I would not like to support hex code for Unix permissions either ... sorry, for the noise. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
I've deployed a new version from the 2.2-beta-1 tag that includes Brett's fix. However, I haven't changed anything WRT Max's message yet. Feel free to try this stuff out; I'm going to spend a few mins trying to sort out the file/dir modes stuff. -john On 3/29/07, Brett Porter [EMAIL PROTECTED] wrote: On 29/03/2007, at 4:13 PM, Stephane Nicoll wrote: IMO, we really need the assembly release. It's been way too long and it's beta. Can't we fix those things for beta-2? If John's fixed the bug I filed, then I'm happy (was just waiting for the new build to be announced so I could test it...) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin (Decimal/Octal file modes issue)
All of this will create one big inconsistency, though. Consider what happens when, way down the line, someone tries to set '511' as a real, octal mode? If they don't use '0511', they'll get 777. This is wildly counterintuitive when you consider that '777' == 777 and '0777' == 777. Also, it will only make it *less* intuitive moving forward (again, for new builds, not for legacy or tagged builds) if we ONLY apply this inconsistency to filefileMode// elements. I don't see how we can maintain the behavior of the buggy implementation from 2.1. -john On 3/29/07, Jörg Schaible [EMAIL PROTECTED] wrote: Max Bowsher wrote on Thursday, March 29, 2007 3:26 PM: Jörg Schaible wrote: [snip] Note: Integer.decode(String) is not used here because it will not handle negative hex-coded integer values. With this approach you can express -1 as 0x ... The whole point here is to maximize compatibility with maven-assembly-plugin-2.1 behaviour. That's why we, not Java, should be making the decision. Furthermore, we are talking about Unix permission mode bits. Neither negative values, nor hexadecimal values, are relevant. Decimal values are only relevant to the extent of supporting existing assembly descriptors written for the buggy behaviour of maven-assembly-plugin-2.1. Yep. Noticed my misplaced comment when it was already sent. I would not like to support hex code for Unix permissions either ... sorry, for the noise. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin (Decimal/Octal file modes issue)
On 3/29/07, John Casey [EMAIL PROTECTED] wrote: I don't see how we can maintain the behavior of the buggy implementation from 2.1. +1 Honestly if found it silly to maintain a buggy behavior. Stéphane -john On 3/29/07, Jörg Schaible [EMAIL PROTECTED] wrote: Max Bowsher wrote on Thursday, March 29, 2007 3:26 PM: Jörg Schaible wrote: [snip] Note: Integer.decode(String) is not used here because it will not handle negative hex-coded integer values. With this approach you can express -1 as 0x ... The whole point here is to maximize compatibility with maven-assembly-plugin-2.1 behaviour. That's why we, not Java, should be making the decision. Furthermore, we are talking about Unix permission mode bits. Neither negative values, nor hexadecimal values, are relevant. Decimal values are only relevant to the extent of supporting existing assembly descriptors written for the buggy behaviour of maven-assembly-plugin-2.1. Yep. Noticed my misplaced comment when it was already sent. I would not like to support hex code for Unix permissions either ... sorry, for the noise. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] Release 2.2-beta-1 of maven-assembly-plugin
Hi everyone, 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=11126styleName=Htmlversion=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 Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
+1 We're using the SNAPSHOT locally for many weeks now and all goes well. Thanks, Stéphane On 3/28/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, 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=11126styleName=Htmlversion=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 Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
Yes! Please! Oh god, yes John Casey wrote: Hi everyone, 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=11126styleName=Htmlversion=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 Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john -- Richard van der Hoff [EMAIL PROTECTED] Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
I've moved the closed issues out of the 2.2 version in JIRA, into a separate 2.2-beta-1 version: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126styleName=Htmlversion=13338 On 3/28/07, Richard van der Hoff [EMAIL PROTECTED] wrote: Yes! Please! Oh god, yes John Casey wrote: Hi everyone, 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=11126styleName=Htmlversion=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 Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john -- Richard van der Hoff [EMAIL PROTECTED] Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] Release 2.2-beta-1 of maven-assembly-plugin
+1 -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 12:59 PM To: Maven Developers List Subject: [vote] Release 2.2-beta-1 of maven-assembly-plugin Hi everyone, 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=11126styleNa me=Htmlversion=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 Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
On 3/28/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, 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. [...] So, let's try for 24hrs. Please vote +1/+0/-1. Non-binding +1. Thanks! Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
+1 LOTS of us have been waiting for this one. Thanks! Dan On Wednesday 28 March 2007 12:59, John Casey wrote: Hi everyone, 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=11126style Name=Htmlversion=12617 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plug in-2.2-beta-1 Staging repository: http://people.apache.org/~jdcasey/stage/repo Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
-1 But it got really close :) Unfortunately, I found a regression, though it looks a simple one to fix: http://jira.codehaus.org/browse/MASSEMBLY-192 I'm continuing my testing past this to see if there are any other issues, though it looks fine. - Brett On 29/03/2007, at 2:59 AM, John Casey wrote: Hi everyone, 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=11126styleName=Htmlversion=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 Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it to the tag...then we could roll another candidate, though I do want to resolve Max's issue above as well. Max: I'm tempted to say that we should look for decimal versions of common octal expressions, then prefix the rest with '0' to ensure they're interpreted as octal (unless they have 0x in front, that is). Is that a decent solution? -john On 3/28/07, Brett Porter [EMAIL PROTECTED] wrote: -1 But it got really close :) Unfortunately, I found a regression, though it looks a simple one to fix: http://jira.codehaus.org/browse/MASSEMBLY-192 I'm continuing my testing past this to see if there are any other issues, though it looks fine. - Brett On 29/03/2007, at 2:59 AM, John Casey wrote: Hi everyone, 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=11126styleName=Htmlversion=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 Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
The real problem here is that as long as there are tags out there that don't specify plugin versions, we have no mechanism for deprecating or breaking api compat, regardless of the version (2.0 - 2.1 - 2.2 - 99.0). -j On 3/28/07, John Casey [EMAIL PROTECTED] wrote: MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it to the tag...then we could roll another candidate, though I do want to resolve Max's issue above as well. Max: I'm tempted to say that we should look for decimal versions of common octal expressions, then prefix the rest with '0' to ensure they're interpreted as octal (unless they have 0x in front, that is). Is that a decent solution? -john On 3/28/07, Brett Porter [EMAIL PROTECTED] wrote: -1 But it got really close :) Unfortunately, I found a regression, though it looks a simple one to fix: http://jira.codehaus.org/browse/MASSEMBLY-192 I'm continuing my testing past this to see if there are any other issues, though it looks fine. - Brett On 29/03/2007, at 2:59 AM, John Casey wrote: Hi everyone, 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=11126styleName=Htmlversion=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/repohttp://people.apache.org/%7Ejdcasey/stage/repo Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
This is a general problem with the magical RELEASE version that plugins use... IMO this is an anti-feature and should be removed in general and force people to configure the plugin's version to help ensure that future releases of plugins don't break their builds. --jason On Mar 28, 2007, at 6:49 PM, John Casey wrote: The real problem here is that as long as there are tags out there that don't specify plugin versions, we have no mechanism for deprecating or breaking api compat, regardless of the version (2.0 - 2.1 - 2.2 - 99.0). -j On 3/28/07, John Casey [EMAIL PROTECTED] wrote: MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it to the tag...then we could roll another candidate, though I do want to resolve Max's issue above as well. Max: I'm tempted to say that we should look for decimal versions of common octal expressions, then prefix the rest with '0' to ensure they're interpreted as octal (unless they have 0x in front, that is). Is that a decent solution? -john On 3/28/07, Brett Porter [EMAIL PROTECTED] wrote: -1 But it got really close :) Unfortunately, I found a regression, though it looks a simple one to fix: http://jira.codehaus.org/browse/MASSEMBLY-192 I'm continuing my testing past this to see if there are any other issues, though it looks fine. - Brett On 29/03/2007, at 2:59 AM, John Casey wrote: Hi everyone, 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=11126styleName=Htmlversion=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/repohttp:// people.apache.org/%7Ejdcasey/stage/repo Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
Agreed, in addition to making it easy to lock down your lifecycle plugin versions. I wonder if I ever sent that proposal out for 2.1... We just need to manage this as best we can (keep compat on x.y versions, and separate unstable repo as I posted elsewhere). - Brett On 29/03/2007, at 11:53 AM, Jason Dillon wrote: This is a general problem with the magical RELEASE version that plugins use... IMO this is an anti-feature and should be removed in general and force people to configure the plugin's version to help ensure that future releases of plugins don't break their builds. --jason On Mar 28, 2007, at 6:49 PM, John Casey wrote: The real problem here is that as long as there are tags out there that don't specify plugin versions, we have no mechanism for deprecating or breaking api compat, regardless of the version (2.0 - 2.1 - 2.2 - 99.0). -j On 3/28/07, John Casey [EMAIL PROTECTED] wrote: MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it to the tag...then we could roll another candidate, though I do want to resolve Max's issue above as well. Max: I'm tempted to say that we should look for decimal versions of common octal expressions, then prefix the rest with '0' to ensure they're interpreted as octal (unless they have 0x in front, that is). Is that a decent solution? -john On 3/28/07, Brett Porter [EMAIL PROTECTED] wrote: -1 But it got really close :) Unfortunately, I found a regression, though it looks a simple one to fix: http://jira.codehaus.org/browse/MASSEMBLY-192 I'm continuing my testing past this to see if there are any other issues, though it looks fine. - Brett On 29/03/2007, at 2:59 AM, John Casey wrote: Hi everyone, 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=11126styleName=Htmlversion=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/repohttp:// people.apache.org/%7Ejdcasey/stage/repo Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
On 3/29/07, Brett Porter [EMAIL PROTECTED] wrote: Agreed, in addition to making it easy to lock down your lifecycle plugin versions. I wonder if I ever sent that proposal out for 2.1... We just need to manage this as best we can (keep compat on x.y versions, and separate unstable repo as I posted elsewhere). Does not work (if you're talking about non snapshot release for unstable) I tried to release two versions of a plugin to a corporate repo (as a workaround). So I had maven-war-plugin-2.0.3-preview-1 in my corporate repo and other standard versions on central. This lead maven to alway try to get the pom from central which is obviously not found so it creates a fake one using a template - boum. I've discussed this extensively with Kenney and I remember there's something in Jira but I can't find it back. IMO, we really need the assembly release. It's been way too long and it's beta. Can't we fix those things for beta-2? Stéphane - Brett On 29/03/2007, at 11:53 AM, Jason Dillon wrote: This is a general problem with the magical RELEASE version that plugins use... IMO this is an anti-feature and should be removed in general and force people to configure the plugin's version to help ensure that future releases of plugins don't break their builds. --jason On Mar 28, 2007, at 6:49 PM, John Casey wrote: The real problem here is that as long as there are tags out there that don't specify plugin versions, we have no mechanism for deprecating or breaking api compat, regardless of the version (2.0 - 2.1 - 2.2 - 99.0). -j On 3/28/07, John Casey [EMAIL PROTECTED] wrote: MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it to the tag...then we could roll another candidate, though I do want to resolve Max's issue above as well. Max: I'm tempted to say that we should look for decimal versions of common octal expressions, then prefix the rest with '0' to ensure they're interpreted as octal (unless they have 0x in front, that is). Is that a decent solution? -john On 3/28/07, Brett Porter [EMAIL PROTECTED] wrote: -1 But it got really close :) Unfortunately, I found a regression, though it looks a simple one to fix: http://jira.codehaus.org/browse/MASSEMBLY-192 I'm continuing my testing past this to see if there are any other issues, though it looks fine. - Brett On 29/03/2007, at 2:59 AM, John Casey wrote: Hi everyone, 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=11126styleName=Htmlversion=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/repohttp:// people.apache.org/%7Ejdcasey/stage/repo Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
On 29/03/2007, at 4:13 PM, Stephane Nicoll wrote: IMO, we really need the assembly release. It's been way too long and it's beta. Can't we fix those things for beta-2? If John's fixed the bug I filed, then I'm happy (was just waiting for the new build to be announced so I could test it...) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
