Nine ways of identifying Class-Path in manifest that don't work

[Composer]

I've read several posts about Class-Path and they generally seem to
assume that I know how to specify the location of a directory relative
to the directory of the jar being executed. I'm running OS X.

The jar to be executed is
/Java projects/myname/utilities/DesktopApp.jar

The external jar containing classes I need is
/Java projects/javamail/mail.jar

So the external jar file is two directories up and then one directory
down from my main jar.

The compiler is perfectly happy finding the classes in mail.jar.
If I explicitly load all the classes from mail.jar into
DesktopApp.jar, it executes fine.

Here are the variants I have tried in my manifest:

Class-Path: .;.../javamail/mail.jar
Class-Path: .;../javamail/mail.jar
Class-Path: .;./javamail/mail.jar
Class-Path: .:.../javamail/mail.jar
Class-Path: .:../javamail/mail.jar
Class-Path: .:./javamail/mail.jar
Class-Path: .../javamail/mail.jar
Class-Path: ../javamail/mail.jar
Class-Path: ./javamail/mail.jar

All nine of these attempts result in NoClassDefFoundError when I
execute DesktopApp.jar.

Am I being really stupid?

 

[Knute Johnson]

I've read several posts about Class-Path and they generally seem to
assume that I know how to specify the location of a directory relative
to the directory of the jar being executed. I'm running OS X.

The jar to be executed is
/Java projects/myname/utilities/DesktopApp.jar

The external jar containing classes I need is
/Java projects/javamail/mail.jar

So the external jar file is two directories up and then one directory
down from my main jar.

The compiler is perfectly happy finding the classes in mail.jar.
If I explicitly load all the classes from mail.jar into
DesktopApp.jar, it executes fine.

Here are the variants I have tried in my manifest:

Class-Path: .;.../javamail/mail.jar
Class-Path: .;../javamail/mail.jar
Class-Path: .;./javamail/mail.jar
Class-Path: .:.../javamail/mail.jar
Class-Path: .:../javamail/mail.jar
Class-Path: .:./javamail/mail.jar
Class-Path: .../javamail/mail.jar
Class-Path: ../javamail/mail.jar
Class-Path: ./javamail/mail.jar

All nine of these attempts result in NoClassDefFoundError when I
execute DesktopApp.jar.

Am I being really stupid?

Relative paths to included jar files always struck me as problematic
because it depends on your current directory to determine relative path.
That said, assuming you are executing from the /Java projects
directory, I think Patricia has your fix. But a couple of things to
remember, the manifest file must end with a new line/carriage return or
it won't work correctly.

From the jar docs:

"Class-Path :

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

So I don't know for sure whether you could specify
/Java projects/javamail/mail.jar but I suspect that would work also
and might work out better if you are going to deploy the entire
directory tree. If not, I wouldn't use a path but just the .jar file
name in the Class-Path entry and deploy everything to the same directory.

 

[Lew]

I've read several posts about Class-Path and they generally seem to
assume that I know how to specify the location of a directory relative
to the directory of the jar being executed.  I'm running OS X.

The jar to be executed is
   /Java projects/myname/utilities/DesktopApp.jar

The external jar containing classes I need is
   /Java projects/javamail/mail.jar

So the external jar file is two directories up and then one directory
down from my main jar.

The compiler is perfectly happy finding the classes in mail.jar.
If I explicitly load all the classes from mail.jar into
DesktopApp.jar, it executes fine.

Here are the variants I have tried in my manifest:

Class-Path: .;.../javamail/mail.jar
Class-Path: .;../javamail/mail.jar
Class-Path: .;./javamail/mail.jar
Class-Path: .:.../javamail/mail.jar
Class-Path: .:../javamail/mail.jar
Class-Path: .:./javamail/mail.jar
Class-Path: .../javamail/mail.jar
Class-Path: ../javamail/mail.jar
Class-Path: ./javamail/mail.jar

All nine of these attempts result in NoClassDefFoundError when I
execute DesktopApp.jar.

Am I being really stupid?

Your using it wrong. Relative paths in the manifest should never
involve going up, only across and down. You're supposed to copy the
necessary JARs into the installation directory of the application JAR,
or some descendant thereof.

The whole point of JARs is to provide a portable application delivery
vehicle. If you start depending on hard-coded absolute paths then you
have defeated the purpose.

Copy your JARs into the directory where the application JAR resides,
or some subdirectory thereof like "lib/" and the bluebirds of
happiness will sing.

 

[EJP]

/Java projects/myname/utilities/DesktopApp.jar
/Java projects/javamail/mail.jar

i.e. ../../javamail/mail.jar, as Patricia said.

Class-Path: .;.../javamail/mail.jar

.... is meaningless.

Class-Path: .;../javamail/mail.jar

That refers to /Java projects/myname/javamail/mail.jar, which doesn't exist.

Class-Path: .;./javamail/mail.jar

That refers to /Java projects/myname/utilities/mail.jar, which doesn't
exist.

Class-Path: .:.../javamail/mail.jar

See above.

Class-Path: .:../javamail/mail.jar

That's the same as above with : instead of ;. The separator in a
Class-Path is a space. You don't need to specify '.'.

Class-Path: .:./javamail/mail.jar
Class-Path: .../javamail/mail.jar
Class-Path: ../javamail/mail.jar
Class-Path: ./javamail/mail.jar

See above.

 

[John B. Matthews]

I've read several posts about Class-Path and they generally seem to
assume that I know how to specify the location of a directory relative
to the directory of the jar being executed. I'm running OS X.

The jar to be executed is
/Java projects/myname/utilities/DesktopApp.jar

The external jar containing classes I need is
/Java projects/javamail/mail.jar

So the external jar file is two directories up and then one directory
down from my main jar.

The compiler is perfectly happy finding the classes in mail.jar.
If I explicitly load all the classes from mail.jar into
DesktopApp.jar, it executes fine.

Here are the variants I have tried in my manifest:

Class-Path: .;.../javamail/mail.jar
Class-Path: .;../javamail/mail.jar
Class-Path: .;./javamail/mail.jar
Class-Path: .:.../javamail/mail.jar
Class-Path: .:../javamail/mail.jar
Class-Path: .:./javamail/mail.jar
Class-Path: .../javamail/mail.jar
Class-Path: ../javamail/mail.jar
Class-Path: ./javamail/mail.jar

All nine of these attempts result in NoClassDefFoundError when I
execute DesktopApp.jar.

Knute's right about using spaces in the manifest Class-Path, and
Patricia's right about the relative path. If you're deploying on Mac,
consider building an application bundle:

<http://developer.apple.com/mac/library/documentation/Java/Reference/Java
_InfoplistRef/Articles/JavaDictionaryInfo.plistKeys.html>

The build.xml and Info.plist files in this project are an example:

<http://robotchase.sourceforge.net/>

 

[Roedy Green]

The compiler is perfectly happy finding the classes in mail.jar.
If I explicitly load all the classes from mail.jar into
DesktopApp.jar, it executes fine.

Try dumping out the System properties. Dump out the CWD. This may give
you a clue.

See http://mindprod.com/applet/wassup.html
http://mindprod.com/jgloss/properties.html
http://mindprod.com/jgloss/classpath.html
http://mindprod.com/jgloss/cwd.html

 

[Martin Gregorie]

So I don't know for sure whether you could specify
/Java projects/javamail/mail.jar but I suspect that would work also
and might work out better if you are going to deploy the entire
directory tree. If not, I wouldn't use a path but just the .jar file
name in the Class-Path entry and deploy everything to the same
directory.

Or leave the jar files in the structure that you downloaded and unpacked,
and put symbolic links to them in the same directory as your jar file.

 

[Knute Johnson]

Or leave the jar files in the structure that you downloaded and unpacked,
and put symbolic links to them in the same directory as your jar file.

Lot of advantages to using Linux but Winblows doesn't have links .

 

[Owen Jacobson]

I've read several posts about Class-Path and they generally seem to
assume that I know how to specify the location of a directory relative
to the directory of the jar being executed. I'm running OS X.

The jar to be executed is
/Java projects/myname/utilities/DesktopApp.jar

The external jar containing classes I need is
/Java projects/javamail/mail.jar

So the external jar file is two directories up and then one directory
down from my main jar.

The compiler is perfectly happy finding the classes in mail.jar.
If I explicitly load all the classes from mail.jar into
DesktopApp.jar, it executes fine.

Here are the variants I have tried in my manifest:

Class-Path: .;.../javamail/mail.jar
Class-Path: .;../javamail/mail.jar
Class-Path: .;./javamail/mail.jar
Class-Path: .:.../javamail/mail.jar
Class-Path: .:../javamail/mail.jar
Class-Path: .:./javamail/mail.jar
Class-Path: .../javamail/mail.jar
Class-Path: ../javamail/mail.jar
Class-Path: ./javamail/mail.jar

All nine of these attempts result in NoClassDefFoundError when I
execute DesktopApp.jar.

Others have already identified the problems with using relative paths
in a manifest's Class-Path: entry. However, it's also worth being aware
that the path separator in the manifest is a space, NOT colon ) or
semicolon (.

-o

 

[Knute Johnson]

NTFS does, though admittedly it has poorer UI support for links than
*nix systems (no "ln" command).

Does it work under Windows? Or are you talking about the icon shortcuts?

If I've somehow misconstrued your use of the word "Winblows", I
apologize, but I'm surprised to see that sort of inane anti-Microsoft
invective coming from you. Seems more suited to some of the dumber
people who post here, not the bright ones. The whole "my OS is better
than your OS" thing isn't exactly a becoming stance.

Pete

My comment was really meant to be flip but you're right I shouldn't call
them names.

 

[Roedy Green]

If I've somehow misconstrued your use of the word "Winblows", I
apologize, but I'm surprised to see that sort of inane anti-Microsoft
invective coming from you. Seems more suited to some of the dumber
people who post here, not the bright ones. The whole "my OS is better
than your OS" thing isn't exactly a becoming stance.

I think Knute has been around the block enough and has used other OSes
besides Windows to be able to publicly give Windows a few
well-deserved kicks. What he is doing is not at all like the mindless
team spirit of those who have only ever used one OS or one language.

 

[Roedy Green]

Maybe that's
when they added symbolic links to NTFS too…I'm not sure.

Originally NTFS theoretically had symbolic links but there was no
support for them of any kind. I still don't think there is any
support from them in the user GUI. I think MS thinks of them as too
complicated for its end users. They are more a programmer convenience
tool.

 

[Martin Gregorie]

Lot of advantages to using Linux but Winblows doesn't have links .

Of course, but the OP seems to be using a *NIX judging by his path
separators.

 

[Tom Anderson]

Of course, but the OP seems to be using a *NIX judging by his path
separators.

He said in his original post he was on OS X, which is at least related to
unix, even if it may not be a true one.

tom

 

[John B. Matthews]

Of course, but the OP seems to be using a *NIX judging by his path
separators.

He said in his original post he was on OS X, which is at least
related to unix, even if it may not be a true one.[/QUOTE]

I'd never looked too closely at the pedigree, but it is quite the
heterotic little hybrid:

<http://en.wikipedia.org/wiki/Darwin_(operating_system)>
<http://en.wikipedia.org/wiki/Heterosis>

 

[Arved Sandstrom]

He said in his original post he was on OS X, which is at least related
to unix, even if it may not be a true one.

tom

Starting with Leopard Mac OS X actually is a true UNIX - it's got the
UNIX 03 certification. The first BSD-based OS to actually get this
certification, in fact.

AHS

 

[Tom Anderson]

Starting with Leopard Mac OS X actually is a true UNIX - it's got the
UNIX 03 certification. The first BSD-based OS to actually get this
certification, in fact.

Huh! I am highly surprised to hear that - both that it passed, what with
all OS X's weirdnesses, and that Apple bothered getting it done. Props to
them.

tom

 

[Composer]

Thanks to everyone. (I'm the original poster.)

Patricia Shanahan, the syntax you suggested works fine.
It's not a syntax I would have invented, had anyone asked me
to invent a logical method of specifying a relative path,
but there it is. Thanks.

Knute Johnson, you may be right that the best approach would be
to put both jars in the same directory. When I distribute this
little app to some friends, I may arrange it that way. Lew,
you will hopefully agree with this. Your suggestion of putting
mail.jar in a lower level strikes me as impractical; I can
imagine multiple apps which want to use this general-purpose
functionality, and it can't be in a subdirectory of ALL of them.

John B. Matthews, thanks for the suggestion but I'm deploying
to some friends on Windows in addition to my own use on the Mac.

Martin Gregorie, I love your suggestion of putting an Alias or
Shortcut into the main jar's directory. Unfortunately I haven't
been able to make it work. On the Mac, I created an Alias named
mail.jar (and double-checked that this was the true UNIX filename)
but the main jar didn't seem to like it. On Windows XP, I created
a Shortcut (and used the Command Prompt to ensure that its true
filename was mail.jar) but again the main jar was unhappy. Shame.
This would have been my preferred solution.

To those involved in the discussion about UNIX, as far as I know
OS X is built on top of a true BSD UNIX. I don't know much about
UNIX, but OS X does support both HFS (Apple) and UFS (UNIX) file
systems. OS X generally uses colons as separators but is also
willing to accept slashes.

Thanks again to all.

 

[markspace]

Patricia Shanahan, the syntax you suggested works fine.
It's not a syntax I would have invented, had anyone asked me
to invent a logical method of specifying a relative path,

This is really odd because it is the syntax everything uses to specify
relative paths. Unix shell, Windows, HTML, etc.

Seriously curious: what is your experience that you've never seen a
relative path go up two levels before?

To those involved in the discussion about UNIX, as far as I know
OS X is built on top of a true BSD UNIX. I don't know much about
UNIX, but OS X does support both HFS (Apple) and UFS (UNIX) file
systems.

UFS sometimes is called BSD FFS or just FFS.

 

[Lew]

Lew,
you will hopefully agree with this. Your suggestion of putting
mail.jar in a lower level strikes me as impractical; I can
imagine multiple apps which want to use this general-purpose
functionality, and it can't be in a subdirectory of ALL of them.

Yes, actually, it can, and moreover should, at least in the . directory of
each of them. That's the point of manifest paths for JARs. Each JAR is
assured of the libraries and the correct versions thereof that it needs. I
recommend putting the libraries in the relative path of each JAR that needs them.

If you really need a certain version of a certain library, say, mail.jar or
whatever, to be common to all Java apps in a particular environment, consider
the extensions mechanism.