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 <ste...@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-unsubscr...@ant.apache.org > For additional commands, e-mail: user-h...@ant.apache.org > >
