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 <file><fileMode/></> 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 0xFFFFFFFF ... > > 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]
