Re: Manifest.MF - classpath is in wrong format when generated programmatically.

[Steve Loughran <st...@apache.org>]

Garima Bathla wrote:
> David :
> 
> Thanks, I have tried setting the class-path via manifestclasspath task as
> well within a build.xml ant script and it is the same result, with long
> class-path's the jar names are split over differnt lines with \n and space
> character.

This is by design
http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html


"No line may be longer than 72 bytes (not characters), in its 
UTF8-encoded form. If a value would make the initial line longer than 
this, it should be continued on extra lines (each starting with a single 
SPACE). "

Ant breaks long filenames exactly on the 72-octal marker (not chars, 
octals), because that is the only way the manifest parser will know that 
the line continues. If you go overlength, you are breaking the rules, if 
you go too short, the parser doesn't know that there is any extra. The 
line has to split on 72 octalls exactly, which really means 70 octals 
followed by \n\r

Here is the quote from the ant 1.8 manual on manifest

"Manifests are processed according to the Jar file specification.. 
Specifically, a manifest element consists of a set of attributes and 
sections. These sections in turn may contain attributes. Note in 
particular that this may result in manifest lines greater than 72 bytes 
being wrapped and continued on the next line.

The Ant team regularly gets complaints that this task in generating 
invalid manifests. By and large, this is not the case: we believe that 
we are following the specification to the letter. The usual problem is 
that some third party manifest reader is not following the same 
specification as well as they think they should; we cannot generate 
invalid manifest files just because one single application is broken. 
J2ME runtimes appear to be particularly troublesome.

If you find that Ant generates manifests incompatible with your runtime, 
take a manifest it has built, fix it up however you need and switch to 
using the <zip> task to create the JAR, feeding in the hand-crafted 
manifest. "

What this means is
1. We think we are getting it right. We've put a lot of effort in to it, 
and the only place we've found problems are when other people write 
manifest parsers and didn't understand the specification themselves. 
Some motorola phones, some versions of websphere.
2. If we have got it wrong, submit a bugrep with tests and proof that we 
are breaking the specification. Proof, not belief.
3. Java -jar should handle split classpaths. If it doesn't something 
serious is wrong with your version
4. If someone else has got it wrong, it's not Ant's problem. in that 
case, use <zip> and do everything by hand.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Re: Manifest.MF - classpath is in wrong format when generated programmatically.

[Garima Bathla <ga...@gmail.com>]

Thanks Steve, your mail forced me to step back and trace all the
possibilities that could have been the culprit for the
ClassNotFoundException and I am glad I finally figured it out.

In the META-INF directory the auto generated file INDEX.LIST that lists all
the packages for the jar that is being built and with INDEX.LIST in META-INF
directory , java - jar jarFile.jar ignores Class-Path attribute and looks in
the packages listed in the INDEX.LIST.

So if I rename INDEX.LIST in the jar and then run java - jar command ;
Class-Path ( even though it is split over multiple lines) is being read
correctly.

For my problem I turned off the index attribute in the jar task.

Thanks, I will close the bug -
https://issues.apache.org/bugzilla/show_bug.cgi?id=47446 as INVALID.

Regards,
Garima.




On Wed, Jul 1, 2009 at 9:24 AM, Steve Loughran <st...@apache.org> wrote:

> Garima Bathla wrote:
>
>> David :
>>
>> Thanks, I have tried setting the class-path via manifestclasspath task as
>> well within a build.xml ant script and it is the same result, with long
>> class-path's the jar names are split over differnt lines with \n and space
>> character.
>>
>
> This is by design
> http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html
>
>
> "No line may be longer than 72 bytes (not characters), in its UTF8-encoded
> form. If a value would make the initial line longer than this, it should be
> continued on extra lines (each starting with a single SPACE). "
>
> Ant breaks long filenames exactly on the 72-octal marker (not chars,
> octals), because that is the only way the manifest parser will know that the
> line continues. If you go overlength, you are breaking the rules, if you go
> too short, the parser doesn't know that there is any extra. The line has to
> split on 72 octalls exactly, which really means 70 octals followed by \n\r
>
> Here is the quote from the ant 1.8 manual on manifest
>
> "Manifests are processed according to the Jar file specification..
> Specifically, a manifest element consists of a set of attributes and
> sections. These sections in turn may contain attributes. Note in particular
> that this may result in manifest lines greater than 72 bytes being wrapped
> and continued on the next line.
>
> The Ant team regularly gets complaints that this task in generating invalid
> manifests. By and large, this is not the case: we believe that we are
> following the specification to the letter. The usual problem is that some
> third party manifest reader is not following the same specification as well
> as they think they should; we cannot generate invalid manifest files just
> because one single application is broken. J2ME runtimes appear to be
> particularly troublesome.
>
> If you find that Ant generates manifests incompatible with your runtime,
> take a manifest it has built, fix it up however you need and switch to using
> the <zip> task to create the JAR, feeding in the hand-crafted manifest. "
>
> What this means is
> 1. We think we are getting it right. We've put a lot of effort in to it,
> and the only place we've found problems are when other people write manifest
> parsers and didn't understand the specification themselves. Some motorola
> phones, some versions of websphere.
> 2. If we have got it wrong, submit a bugrep with tests and proof that we
> are breaking the specification. Proof, not belief.
> 3. Java -jar should handle split classpaths. If it doesn't something
> serious is wrong with your version
> 4. If someone else has got it wrong, it's not Ant's problem. in that case,
> use <zip> and do everything by hand.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>