Mike Gratton wrote:
> Joe Emenaker wrote:
>
> > Granted, my example was entirely contrived, but it was to make a point.
How
> > about a more plausible example:
> >
> > foo.jar makes reference to "../bar.jar". [snip]
>
> I'd still say that's a broken way of using manifest classpaths, for the
> same reason you outlined. If I encountered an app which does such a
> thing, then I'd talk to the author to get it fixed, or use somthing
> else. Using a manifest classpath for a jar containing a library, rather
> than an application is also a bad idea. Again, I'd try to get it fixed,
> or not use it.
>
> However, here's an example of a non-broken way of using a manifest
> classpath, which I think works quite nicely.
>
> You've written an application with depends on a library in foo.jar, and
> you distribute it with your app. In this case, I'd do the following put
> foo.jar in ${APPLICATION_ROOT}/lib. I'd then create a jar in
> ${APPLICATION_PATH} containing the application's classes with a manifest
> which specifies the main class and a classpath of lib/foo.jar.
Well, this brings us full-circle back to the original topic of using
symlinks for lib jars.
What I seem to be hearing is that manifest classpaths should be discouraged
in anything other than jars that come with an app. In fact, to quote, you
said "Using a manifest classpath for a jar containing a library, rather than
an application is also a bad idea.".
If that's the case, then one could make the argument that symlinks in
/usr/share/java are okay again, provided that jars that come *with* apps are
placed in some app-specific directory (or, at the least, the ones that are
mentioned in any manifest classpath are placed in an app-specific dir).
So, does this re-kindle the symlink issue?
- Joe
