Bug#588379: using jh_depends when a .jar exists in one than one package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I do not understand that these jars are mentioned in the classpath in the first place. The JVM should load these itself, so you should not have to mention them. The preferred way of choosing a JVM is by using the --jvm argument[1]. ~Niels [1] Just a heads up, the semantics of --jvm will change slightly in 0.32 in regards to how headless is interpreted. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw5jIoACgkQVCqoiq1YlqzrvQCgxysirDTuD0sA/6H4MZY0u9Oo oWgAn10bnMZH0S5Q4Z7SyC5hwbIEgwkr =CCWg -END PGP SIGNATURE- __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#588379: using jh_depends when a .jar exists in one than one package
Thanks for the reply
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).
Arduino is a derivative of Processing which compiles C code, but is
based on the Processing classes, and won't build unless tools.jar is
explicitly in the classpath (spits out undefined class errors).
tools.jar is apparently used when compiling code, that's why it's in
the jdk and not in the jre [1,2]. However, java-propose-classpath on
arduino.jar only sees symbols of three .jars: the arduino.jar itself,
and two java library packages (not the jdk).
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:
for LIB in \
java/lib/rt.jar \
java/lib/tools.jar \
lib/*.jar \
;
do
CLASSPATH=${CLASSPATH}:${APPDIR}/${LIB}
done
export CLASSPATH
We don't do that in debian, since CLASSPATH is defined before jh_build.
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.
[1]
http://packages.debian.org/search?suite=sidarch=anymode=pathsearchon=contentskeywords=tools.jar
[2]
http://download.oracle.com/docs/cd/E17476_01/javase/1.5.0/docs/tooldocs/solaris/jdkfiles.html
[3] http://arduino.googlecode.com/svn/trunk/build/linux/dist/arduino
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please
use
debian-j...@lists.debian.org for discussions and questions.
Bug#588379: using jh_depends when a .jar exists in one than one package
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 __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Processed: Re: Bug#588379: using jh_depends when a .jar exists in one than one package
Processing commands for cont...@bugs.debian.org: tag 588379 wontfix Bug #588379 [javahelper] using jh_depends when a .jar exists in one than one package Added tag(s) wontfix. thanks Stopping processing here. Please contact me if you need assistance. -- 588379: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588379 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#588379: using jh_depends when a .jar exists in one than one package
Package: javahelper Version: 0.31 Severity: wishlist When using jh_depends in the arduino package (and soon to be packaged processing-java package), jh_depends correctly identifies tools.jar and rt.jar to be from openjdk-6-jdk. However, those jars are also available in sun-java6-jdk. Users asked that the package depend on: openjdk-6-jdk | sun-java6-jdk. Would it be possible to have a quirk where if jh_depends finds jars from openjdk-6-jdk it replaces java:Depends with openjdk-6-jdk | sun-java6-jdk? Right now I'm not using the substitution variable and listing the packages individually so I can have Depends: openjdk-6-jdk | sun-java6-jdk __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
