Jose Alberto,
Can we make sure that our own code actually understand the jars as you are constructing them? Does this works with AntClassLoader? How about URLClassLoader?
URLClassLoader should definitely work. AntClassLoader does not use Class-Path entries in the manifest but it certainly should. There is a bug covering this.
I also think it is important to have a way to request that at least the classpath be left alone as a long line. There is too much code outthere that t does not follow this obscure spec.
I don't know if I would call it an obscure spec. Certainly the jar command that comes with the JDK and the Manifest classes in the JDK follow the spec.
Can anyone give me a good reason why there is this need for 72 char lines in manifests? Is someone concerned about overrun buffers in java? (just a retorical question).
Well, parts of the spec are based on a mail RFC (RFC822) and I guess the line lengths come from there. I can't see the reason. There is a prohibition on headers that start with From too.
How big should it be. There is in fact a limit in the JDK code on how big a line can be when reading in a manifest.
How about a "strict='true'" attribute that when true follows the 72 char split and lives lines alone when false.
Since the JDK jar command is behaving in the same way as the <manifest> code, I'm not sure we should establish a less compliant approach.
I know this is changing the subject a little, but it would be fantastic if we could add a <classpathset> fileset element that constructs the Class-Path line
from a list of jars. I could provide a patch if people think it would be a good idea.
I had though of adding a <classpath> element and allowing it to take a reference to a Path object. Not sure I follow how you would do it. Can you expland on that?
Conor
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
