ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garima Bathla <>
Subject Re: Manifest.MF - classpath is in wrong format when generated programmatically.
Date Fri, 03 Jul 2009 18:53:17 GMT
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

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

Thanks, I will close the bug - as INVALID.


On Wed, Jul 1, 2009 at 9:24 AM, Steve Loughran <> 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
> "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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message