Bug#588379: using jh_depends when a .jar exists in one than one package

[Matthew Johnson]

tag 588379 wontfix
thanks

Hi Scott, I'm the other Javahelper maintainer,

On Sun Jul 11 11:12, Scott Howard wrote:
> "Processing" is a java package which compiles java code, so it depends
> on the jdk. The package won't build unless tools.jar is explicitly in
> the classpath at build time (I'm not too familiar with that package, i
> work with arduino so I don't know what happens if tools.jar isn't in
> the classpath at runtime for processing).

The question I have is - if the Class-Path: in the jar manifest contains just
"tools.jar" - how is this loaded by the JVM? I would expect it wouldn't know
where to look. If you explicitly list the path to tools.jar, then it'll only
load the one from that JVM - and hence you should depend on just that.

I expect what you actually want to do is either list both in the manifest or
select it at runtime and hence don't need it in the manifest (and, I see below,
this latter is what you do).

My view is that this really is a corner case and the automated tools 
like jh_depends are designed for the common case, so the easiest solution
may be to just list the depends yourself.

> Maybe we can use javahelper to define one classpath during build time
> and another for runtime? (I've tried but haven't found how to do it
> yet using jh_build and setting CLASSPATH and/or using .classpath, and
> I haven't tested if the package would even work - just a theory) I
> have a feeling that having a different classpath than the build time
> classpath isn't that good of an idea, especially when upstream's
> wrapper for launching the .jar [3] does the following:

Well, your wrapper here is setting the classpath, so you don't need it to be in
the jar. The other option would be to use jh_build to build (doesn't upstream
have a build system?) and then jh_classpath to remove the classpath, then you
can put the depends in manually and have the wrapper script (as it does) set
the classpath at runtime.

> This might be a really unique case, but I guess the quirk would be if
> tools.jar is found in the classpath to include either the openjdk OR
> sun jdk since the file exists in both and only one is installed during
> build time (the one in main). I'd understand if it's too much to
> change and maintain the change for the few java packages that would
> depend on tools.jar, I'll defer to your experience and opinion.
 
Yeah, I think that's probably the case here, but thanks for asking about it -
it's certainly an interesting case!

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20100711/d2a99415/attachment.pgp>