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

[Garima Bathla]

Dear Fellow memebers,

I really need help , I have been stuck with same problem for few days now.

Problem:
As we all know, manifest file syntax is very sensitive ( sensitive to
spaces, # of characters in a line, \n character). And I have learn it very
hard way that if Class-Path in a jar is not set as per the standards it will
be silently ignored.

I am in the process of generating MANIFEST.MF file programmatically by
Extending Jar Task; I am almost there, but the class-path that Jar task
prints in the Manifest file isn't formatted correctly.

*Code snippet:*
*String formattedManifestClassPath = "aaa.jar bbb.jar ccc.jar ddd.jar
eee.jar fff.jar ggg.jar hhh.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar
nnn.jar ooo.jar ppp.jar qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar
www.jar xxx.jar yyy.jar zzz.jar";*
**
*Manifest.Attribute classpathAttribute = new
Manifest.Attribute(Manifest.ATTRIBUTE_CLASSPATH,
formattedManifestClassPath);

*
*manifest.addConfiguredAttribute(classpathAttribute);*

Now the problem is that the Class-Path in MANIFEST.MF file is generated as

*Class-Path: aaa.jar bbb.jar ccc.jar ddd.jar eee.jar fff.jar ggg.jar hh*
* h.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar nnn.jar ooo.jar ppp.jar*
*  qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar www.jar xxx.jar yyy.*
* jar zzz.jar*
* *
So if I run

"java -jar generated.jar"

Class-Path is being ignored, because it is not well formed (jar name hhh.jar
is split over 2 lines).  How can I *generate class-path *in the correct
format? How do I set the String? Please note I am generating the classpath
programatically ( by extending the task and passing in the properties)

I have tried inserting \n ( new line character after every jar entery), but
ManifestClasspath is still not correct as Jar task inserts a new line
character after every 71st character.

formattedManifestClassPath = "aaa.jar \n bbb.jar \n ccc.jar \n ddd.jar \n
eee.jar \n fff.jar \n ggg.jar \n hhh.jar \n iii.jar \n jjj.jar \n kkk.jar \n
lll.jar \n mmm.jar \n nnn.jar \n ooo.jar \n ppp.jar \n qqq.jar \n rrr.jar \n
sss.jar \n ttt.jar \n uuu.jar \n vvv.jar \n www.jar \n xxx.jar \n yyy.jar \n
zzz.jar";

Any pointers if you know will be very helpful. Is it is a bug?

Regards,
Garima.

[Avlesh Singh]

Here is what the jar specification has to say on manifest's class-path
attribute -

The value of this attribute specifies the relative URLs of the extensions or
> libraries that this application or extension needs. URLs are separated by
> one or more spaces. The application or extension class loader uses the value
> of this attribute to construct its internal search path.


And this is the specification on the max_line_length attribute in the
manifest:

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).
>

Bottomline, none of the ANT's implementation is buggy. It is just following
the specs.

*Solution (IMHO)*
The solution possibly is to manually check your class-path-attribute string
for the length 72. If your jar file name is getting splitted because of this
length limit, add extra spaces (which is file according to the specs) until
the 72nd character. Add your jar file name thereafter. This would not cause
splits within your file names.

I am curious to know if the above solution works.
Good luck.

Cheers
Avlesh

On Mon, Jun 29, 2009 at 12:32 PM, Garima Bathla <garima.bathla@...>wrote:

> Dear Fellow memebers,
>
> I really need help , I have been stuck with same problem for few days now.
>
> Problem:
> As we all know, manifest file syntax is very sensitive ( sensitive to
> spaces, # of characters in a line, \n character). And I have learn it very
> hard way that if Class-Path in a jar is not set as per the standards it
> will
> be silently ignored.
>
> I am in the process of generating MANIFEST.MF file programmatically by
> Extending Jar Task; I am almost there, but the class-path that Jar task
> prints in the Manifest file isn't formatted correctly.
>
> *Code snippet:*
> *String formattedManifestClassPath = "aaa.jar bbb.jar ccc.jar ddd.jar
> eee.jar fff.jar ggg.jar hhh.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar
> nnn.jar ooo.jar ppp.jar qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar
> www.jar xxx.jar yyy.jar zzz.jar";*
> **
> *Manifest.Attribute classpathAttribute = new
> Manifest.Attribute(Manifest.ATTRIBUTE_CLASSPATH,
> formattedManifestClassPath);
>
> *
> *manifest.addConfiguredAttribute(classpathAttribute);*
>
> Now the problem is that the Class-Path in MANIFEST.MF file is generated as
>
> *Class-Path: aaa.jar bbb.jar ccc.jar ddd.jar eee.jar fff.jar ggg.jar hh*
> * h.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar nnn.jar ooo.jar ppp.jar*
> *  qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar www.jar xxx.jar yyy.*
> * jar zzz.jar*
> * *
> So if I run
>
> "java -jar generated.jar"
>
> Class-Path is being ignored, because it is not well formed (jar name
> hhh.jar
> is split over 2 lines).  How can I *generate class-path *in the correct
> format? How do I set the String? Please note I am generating the classpath
> programatically ( by extending the task and passing in the properties)
>
> I have tried inserting \n ( new line character after every jar entery), but
> ManifestClasspath is still not correct as Jar task inserts a new line
> character after every 71st character.
>
> formattedManifestClassPath = "aaa.jar \n bbb.jar \n ccc.jar \n ddd.jar \n
> eee.jar \n fff.jar \n ggg.jar \n hhh.jar \n iii.jar \n jjj.jar \n kkk.jar
> \n
> lll.jar \n mmm.jar \n nnn.jar \n ooo.jar \n ppp.jar \n qqq.jar \n rrr.jar
> \n
> sss.jar \n ttt.jar \n uuu.jar \n vvv.jar \n www.jar \n xxx.jar \n yyy.jar
> \n
> zzz.jar";
>
> Any pointers if you know will be very helpful. Is it is a bug?
>
> Regards,
> Garima.
>

[David Weintraub]

Just curious: Why don't you use the <manifest> task and the
<manifestClassPath> task?

On Mon, Jun 29, 2009 at 3:02 AM, Garima Bathla<garima.bathla@...> wrote:

> Dear Fellow memebers,
>
> I really need help , I have been stuck with same problem for few days now.
>
> Problem:
> As we all know, manifest file syntax is very sensitive ( sensitive to
> spaces, # of characters in a line, \n character). And I have learn it very
> hard way that if Class-Path in a jar is not set as per the standards it will
> be silently ignored.
>
> I am in the process of generating MANIFEST.MF file programmatically by
> Extending Jar Task; I am almost there, but the class-path that Jar task
> prints in the Manifest file isn't formatted correctly.
>
> *Code snippet:*
> *String formattedManifestClassPath = "aaa.jar bbb.jar ccc.jar ddd.jar
> eee.jar fff.jar ggg.jar hhh.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar
> nnn.jar ooo.jar ppp.jar qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar
> www.jar xxx.jar yyy.jar zzz.jar";*
> **
> *Manifest.Attribute classpathAttribute = new
> Manifest.Attribute(Manifest.ATTRIBUTE_CLASSPATH,
> formattedManifestClassPath);
>
> *
> *manifest.addConfiguredAttribute(classpathAttribute);*
>
> Now the problem is that the Class-Path in MANIFEST.MF file is generated as
>
> *Class-Path: aaa.jar bbb.jar ccc.jar ddd.jar eee.jar fff.jar ggg.jar hh*
> * h.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar nnn.jar ooo.jar ppp.jar*
> *  qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar www.jar xxx.jar yyy.*
> * jar zzz.jar*
> * *
> So if I run
>
> "java -jar generated.jar"
>
> Class-Path is being ignored, because it is not well formed (jar name hhh.jar
> is split over 2 lines).  How can I *generate class-path *in the correct
> format? How do I set the String? Please note I am generating the classpath
> programatically ( by extending the task and passing in the properties)
>
> I have tried inserting \n ( new line character after every jar entery), but
> ManifestClasspath is still not correct as Jar task inserts a new line
> character after every 71st character.
>
> formattedManifestClassPath = "aaa.jar \n bbb.jar \n ccc.jar \n ddd.jar \n
> eee.jar \n fff.jar \n ggg.jar \n hhh.jar \n iii.jar \n jjj.jar \n kkk.jar \n
> lll.jar \n mmm.jar \n nnn.jar \n ooo.jar \n ppp.jar \n qqq.jar \n rrr.jar \n
> sss.jar \n ttt.jar \n uuu.jar \n vvv.jar \n www.jar \n xxx.jar \n yyy.jar \n
> zzz.jar";
>
> Any pointers if you know will be very helpful. Is it is a bug?
>
> Regards,
> Garima.
>

--
David Weintraub
qazwart@...

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

[Garima Bathla]

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.

On Mon, Jun 29, 2009 at 7:39 AM, David Weintraub <qazwart@...> wrote:

> Just curious: Why don't you use the <manifest> task and the
> <manifestClassPath> task?
>
> On Mon, Jun 29, 2009 at 3:02 AM, Garima Bathla<garima.bathla@...>
> wrote:
> > Dear Fellow memebers,
> >
> > I really need help , I have been stuck with same problem for few days
> now.
> >
> > Problem:
> > As we all know, manifest file syntax is very sensitive ( sensitive to
> > spaces, # of characters in a line, \n character). And I have learn it
> very
> > hard way that if Class-Path in a jar is not set as per the standards it
> will
> > be silently ignored.
> >
> > I am in the process of generating MANIFEST.MF file programmatically by
> > Extending Jar Task; I am almost there, but the class-path that Jar task
> > prints in the Manifest file isn't formatted correctly.
> >
> > *Code snippet:*
> > *String formattedManifestClassPath = "aaa.jar bbb.jar ccc.jar ddd.jar
> > eee.jar fff.jar ggg.jar hhh.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar
> > nnn.jar ooo.jar ppp.jar qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar
> > www.jar xxx.jar yyy.jar zzz.jar";*
> > **
> > *Manifest.Attribute classpathAttribute = new
> > Manifest.Attribute(Manifest.ATTRIBUTE_CLASSPATH,
> > formattedManifestClassPath);
> >
> > *
> > *manifest.addConfiguredAttribute(classpathAttribute);*
> >
> > Now the problem is that the Class-Path in MANIFEST.MF file is generated
> as
> >
> > *Class-Path: aaa.jar bbb.jar ccc.jar ddd.jar eee.jar fff.jar ggg.jar hh*
> > * h.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar nnn.jar ooo.jar ppp.jar*
> > *  qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar www.jar xxx.jar yyy.*
> > * jar zzz.jar*
> > * *
> > So if I run
> >
> > "java -jar generated.jar"
> >
> > Class-Path is being ignored, because it is not well formed (jar name
> hhh.jar
> > is split over 2 lines).  How can I *generate class-path *in the correct
> > format? How do I set the String? Please note I am generating the
> classpath
> > programatically ( by extending the task and passing in the properties)
> >
> > I have tried inserting \n ( new line character after every jar entery),
> but
> > ManifestClasspath is still not correct as Jar task inserts a new line
> > character after every 71st character.
> >
> > formattedManifestClassPath = "aaa.jar \n bbb.jar \n ccc.jar \n ddd.jar \n
> > eee.jar \n fff.jar \n ggg.jar \n hhh.jar \n iii.jar \n jjj.jar \n kkk.jar
> \n
> > lll.jar \n mmm.jar \n nnn.jar \n ooo.jar \n ppp.jar \n qqq.jar \n rrr.jar
> \n
> > sss.jar \n ttt.jar \n uuu.jar \n vvv.jar \n www.jar \n xxx.jar \n yyy.jar
> \n
> > zzz.jar";
> >
> > Any pointers if you know will be very helpful. Is it is a bug?
> >
> > Regards,
> > Garima.
> >
>
>
>
> --
> David Weintraub
> qazwart@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

[Garima Bathla]

Avlesh,

Thanks, your reply does makes a lot of sense - and honestly what you
suggested I have already tried , the problem with that logic though is that
java -jar command ignores class-path which contains more than one space
character

so e.g.

Class-Path: aaa.jar ssssssssssssss ..(till 71 characters)
  bbb.jar


where s - space character till 71 characters

This is invalid class-path to java -jar command and it is ignored.

I do think this is a bug, not because Manifest.class implementation is not
following the specification, but as a result of following the specification
it is causing the functionality to break; Class-Path that is set if it
cannot be read - is being set incorrectly , hence I call it a bug.

On Mon, Jun 29, 2009 at 12:58 AM, Avlesh Singh <avlesh@...> wrote:

> Here is what the jar specification has to say on manifest's class-path
> attribute -
>
> The value of this attribute specifies the relative URLs of the extensions
> or
> > libraries that this application or extension needs. URLs are separated by
> > one or more spaces. The application or extension class loader uses the
> value
> > of this attribute to construct its internal search path.
>
>
> And this is the specification on the max_line_length attribute in the
> manifest:
>
> 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).
> >
>
> Bottomline, none of the ANT's implementation is buggy. It is just following
> the specs.
>
> *Solution (IMHO)*
> The solution possibly is to manually check your class-path-attribute string
> for the length 72. If your jar file name is getting splitted because of
> this
> length limit, add extra spaces (which is file according to the specs) until
> the 72nd character. Add your jar file name thereafter. This would not cause
> splits within your file names.
>
> I am curious to know if the above solution works.
> Good luck.
>
> Cheers
> Avlesh
>
> On Mon, Jun 29, 2009 at 12:32 PM, Garima Bathla <garima.bathla@...
> >wrote:
>
> > Dear Fellow memebers,
> >
> > I really need help , I have been stuck with same problem for few days
> now.
> >
> > Problem:
> > As we all know, manifest file syntax is very sensitive ( sensitive to
> > spaces, # of characters in a line, \n character). And I have learn it
> very
> > hard way that if Class-Path in a jar is not set as per the standards it
> > will
> > be silently ignored.
> >
> > I am in the process of generating MANIFEST.MF file programmatically by
> > Extending Jar Task; I am almost there, but the class-path that Jar task
> > prints in the Manifest file isn't formatted correctly.
> >
> > *Code snippet:*
> > *String formattedManifestClassPath = "aaa.jar bbb.jar ccc.jar ddd.jar
> > eee.jar fff.jar ggg.jar hhh.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar
> > nnn.jar ooo.jar ppp.jar qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar
> > www.jar xxx.jar yyy.jar zzz.jar";*
> > **
> > *Manifest.Attribute classpathAttribute = new
> > Manifest.Attribute(Manifest.ATTRIBUTE_CLASSPATH,
> > formattedManifestClassPath);
> >
> > *
> > *manifest.addConfiguredAttribute(classpathAttribute);*
> >
> > Now the problem is that the Class-Path in MANIFEST.MF file is generated
> as
> >
> > *Class-Path: aaa.jar bbb.jar ccc.jar ddd.jar eee.jar fff.jar ggg.jar hh*
> > * h.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar nnn.jar ooo.jar ppp.jar*
> > *  qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar www.jar xxx.jar yyy.*
> > * jar zzz.jar*
> > * *
> > So if I run
> >
> > "java -jar generated.jar"
> >
> > Class-Path is being ignored, because it is not well formed (jar name
> > hhh.jar
> > is split over 2 lines).  How can I *generate class-path *in the correct
> > format? How do I set the String? Please note I am generating the
> classpath
> > programatically ( by extending the task and passing in the properties)
> >
> > I have tried inserting \n ( new line character after every jar entery),
> but
> > ManifestClasspath is still not correct as Jar task inserts a new line
> > character after every 71st character.
> >
> > formattedManifestClassPath = "aaa.jar \n bbb.jar \n ccc.jar \n ddd.jar \n
> > eee.jar \n fff.jar \n ggg.jar \n hhh.jar \n iii.jar \n jjj.jar \n kkk.jar
> > \n
> > lll.jar \n mmm.jar \n nnn.jar \n ooo.jar \n ppp.jar \n qqq.jar \n rrr.jar
> > \n
> > sss.jar \n ttt.jar \n uuu.jar \n vvv.jar \n www.jar \n xxx.jar \n yyy.jar
> > \n
> > zzz.jar";
> >
> > Any pointers if you know will be very helpful. Is it is a bug?
> >
> > Regards,
> > Garima.
> >
>

[Avlesh Singh]

Maybe you are right, Garima.
I'll run a sample on my machine shortly to validate your use case and the
corresponding output.

Cheers
Avlesh

On Mon, Jun 29, 2009 at 9:53 PM, Garima Bathla <garima.bathla@...>wrote:

> Avlesh,
>
> Thanks, your reply does makes a lot of sense - and honestly what you
> suggested I have already tried , the problem with that logic though is that
> java -jar command ignores class-path which contains more than one space
> character
>
> so e.g.
>
> Class-Path: aaa.jar ssssssssssssss ..(till 71 characters)
>  bbb.jar
>
>
> where s - space character till 71 characters
>
> This is invalid class-path to java -jar command and it is ignored.
>
> I do think this is a bug, not because Manifest.class implementation is not
> following the specification, but as a result of following the specification
> it is causing the functionality to break; Class-Path that is set if it
> cannot be read - is being set incorrectly , hence I call it a bug.
>
> On Mon, Jun 29, 2009 at 12:58 AM, Avlesh Singh <avlesh@...> wrote:
>
> > Here is what the jar specification has to say on manifest's class-path
> > attribute -
> >
> > The value of this attribute specifies the relative URLs of the extensions
> > or
> > > libraries that this application or extension needs. URLs are separated
> by
> > > one or more spaces. The application or extension class loader uses the
> > value
> > > of this attribute to construct its internal search path.
> >
> >
> > And this is the specification on the max_line_length attribute in the
> > manifest:
> >
> > 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).
> > >
> >
> > Bottomline, none of the ANT's implementation is buggy. It is just
> following
> > the specs.
> >
> > *Solution (IMHO)*
> > The solution possibly is to manually check your class-path-attribute
> string
> > for the length 72. If your jar file name is getting splitted because of
> > this
> > length limit, add extra spaces (which is file according to the specs)
> until
> > the 72nd character. Add your jar file name thereafter. This would not
> cause
> > splits within your file names.
> >
> > I am curious to know if the above solution works.
> > Good luck.
> >
> > Cheers
> > Avlesh
> >
> > On Mon, Jun 29, 2009 at 12:32 PM, Garima Bathla <garima.bathla@...
> > >wrote:
> >
> > > Dear Fellow memebers,
> > >
> > > I really need help , I have been stuck with same problem for few days
> > now.
> > >
> > > Problem:
> > > As we all know, manifest file syntax is very sensitive ( sensitive to
> > > spaces, # of characters in a line, \n character). And I have learn it
> > very
> > > hard way that if Class-Path in a jar is not set as per the standards it
> > > will
> > > be silently ignored.
> > >
> > > I am in the process of generating MANIFEST.MF file programmatically by
> > > Extending Jar Task; I am almost there, but the class-path that Jar task
> > > prints in the Manifest file isn't formatted correctly.
> > >
> > > *Code snippet:*
> > > *String formattedManifestClassPath = "aaa.jar bbb.jar ccc.jar ddd.jar
> > > eee.jar fff.jar ggg.jar hhh.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar
> > > nnn.jar ooo.jar ppp.jar qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar
> > > www.jar xxx.jar yyy.jar zzz.jar";*
> > > **
> > > *Manifest.Attribute classpathAttribute = new
> > > Manifest.Attribute(Manifest.ATTRIBUTE_CLASSPATH,
> > > formattedManifestClassPath);
> > >
> > > *
> > > *manifest.addConfiguredAttribute(classpathAttribute);*
> > >
> > > Now the problem is that the Class-Path in MANIFEST.MF file is generated
> > as
> > >
> > > *Class-Path: aaa.jar bbb.jar ccc.jar ddd.jar eee.jar fff.jar ggg.jar
> hh*
> > > * h.jar iii.jar jjj.jar kkk.jar lll.jar mmm.jar nnn.jar ooo.jar
> ppp.jar*
> > > *  qqq.jar rrr.jar sss.jar ttt.jar uuu.jar vvv.jar www.jar xxx.jar
> yyy.*
> > > * jar zzz.jar*
> > > * *
> > > So if I run
> > >
> > > "java -jar generated.jar"
> > >
> > > Class-Path is being ignored, because it is not well formed (jar name
> > > hhh.jar
> > > is split over 2 lines).  How can I *generate class-path *in the correct
> > > format? How do I set the String? Please note I am generating the
> > classpath
> > > programatically ( by extending the task and passing in the properties)
> > >
> > > I have tried inserting \n ( new line character after every jar entery),
> > but
> > > ManifestClasspath is still not correct as Jar task inserts a new line
> > > character after every 71st character.
> > >
> > > formattedManifestClassPath = "aaa.jar \n bbb.jar \n ccc.jar \n ddd.jar
> \n
> > > eee.jar \n fff.jar \n ggg.jar \n hhh.jar \n iii.jar \n jjj.jar \n
> kkk.jar
> > > \n
> > > lll.jar \n mmm.jar \n nnn.jar \n ooo.jar \n ppp.jar \n qqq.jar \n
> rrr.jar
> > > \n
> > > sss.jar \n ttt.jar \n uuu.jar \n vvv.jar \n www.jar \n xxx.jar \n
> yyy.jar
> > > \n
> > > zzz.jar";
> > >
> > > Any pointers if you know will be very helpful. Is it is a bug?
> > >
> > > Regards,
> > > Garima.
> > >
> >
>

[Stefan Bodewig]

On 2009-06-29, Garima Bathla <garima.bathla@...> wrote:

> the problem with that logic though is that java -jar command ignores
> class-path which contains more than one space character

> so e.g.

> Class-Path: aaa.jar ssssssssssssss ..(till 71 characters)
>   bbb.jar


> where s - space character till 71 characters

> This is invalid class-path to java -jar command and it is ignored.

This is simply not true.
<http://ant.apache.org/faq.html#mangled-manifest>

If your java -jar really ignored the Class-Path created by Ant it
would be violating the jar specification.  Any Java implementation I
have tried myself does support Class-Path entries as formatted by Ant.

Stefan

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

[Steve Loughran]

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@...
For additional commands, e-mail: user-help@...

[Garima Bathla]

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 <stevel@...> 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@...
> For additional commands, e-mail: user-help@...
>
>