Having backwards compatibility (default behavior) and adding an attribute to choose the eol style of the manifest fits to me perfectly. That is the answer of my problem, if I understand that the next release of Ant will include it (which release : Ant 1.7.0 or 1.7.1 ? Give me just an idea please).
By the way, as for my understanding, the same problem should have been solved by the specification for the class file generation. Class files should be portable and should surely contain some eol character. For example, I generate a Jar file under Unix that I use on Windows. The Windows JVM should be implemented to understand EOL Unix character then ? Is that mean, that any system should implement a way of understanding all other systems EOL characters.. Anyway the question is how to they the same problem for class file to ensure portability ? Regards, -----Original Message----- From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] Sent: mercredi 30 août 2006 20:40 To: Ant Users List Subject: Re: Jar task : Manifest File ends with Windows ending '\r'. Hello Matt, I am -1 to change the way ant stores manifests. At least if you want to change something, do not change the default behavior. Adding an attribute to choose the eol style of the manifest is OK, as long as the default behavior does not change. If you change the default behavior, Windows users of jars built under Unix will complain. \n without \r under Windows is displayed in notepad as a square. Regards, Antoine -------- Original-Nachricht -------- Datum: Wed, 30 Aug 2006 09:10:19 -0700 (PDT) Von: Matt Benson <[EMAIL PROTECTED]> An: Ant Users List <user@ant.apache.org> Betreff: Re: Jar task : Manifest File ends with Windows ending \'\\r\'. > --- Conor MacNeill <[EMAIL PROTECTED]> wrote: > > > > > > > > It is not against the specifications and, therefore, should not > > cause the jar to be dysfunctional. Nevertheless it may as well > > follow the platform conventions. > > > > Conor > > Agreed; however I cannot locate a 1.2 manifest specification. Can > anyone here say with certainty that all eol formats definitely were > permitted prior to 1.3? > > -Matt > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------- An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. --------------------- --------------------- An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. --------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
