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
signature.asc
Description: Digital signature
