Noel Sebastien (BIL) wrote:
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 ?
Classpath spec says it can be one of \n , \r\n or \r
I dont think we should adapt the manifest at all: -1 t to the idea.
It comes very close to stepping on the toes of the
when-to-break-long-lines logic, which is such a source of support calls,
usually related to applications or users who dont know the rules (even
things like weblogic and the J2EE specification authors), that we dont
want to introduce uncertainty into how ant generates manifests. We know
that the manifests we create that can be understood by all applications
except those who refuse to read the specs. Let's leave it that way,.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
