I've been talking to Max more about this, and I think we're all in
agreement. So, with his help, here's what I've done:
- parse all modes using Integer.parseInt( mode, 8 )
- if a NumberFormatException happens, throw an AssemblyFormattingException
explaining that it's a bad file/directory mode
-
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 Thu
te] 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
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 o
Looking at this more, I don't see how we can escape breaking some builds, at
least theoretically. If we put in the common decimal mode workarounds, and
someone is using something that doesn't fit as 'common', their build will
break. The only definite solution is to keep using decimals where they h
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]>
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
Jörg Schaible wrote:
> Max Bowsher wrote on Thursday, March 29, 2007 1:46 PM:
>> private static HashMap commonDecimalModes = new HashMap() {{
>> add("420"); add("436");
>> add("493");
>> add("509");
>> }}
>>
>> .
>>
>> if ( commonDecimalModes.contains( mode ) )
>> return Integer.parse
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
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 t
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
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...)
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 pos
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:5
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,
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
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
-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 C
John Casey wrote:
> Hi everyone,
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin.
...
> 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-
+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
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% backw
+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
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=11126&styleName=Html&version=13338
On 3/28/07, Richard van der Hoff <[EMAIL PROTECTED]> wrote:
Yes! Please! Oh god, yes
John Casey wr
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% backwar
+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 a
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 w
26 matches
Mail list logo
