betelgeuse@pena /etc/env.d $ qfile 40vtk sci-libs/vtk (/etc/env.d/40vtk) betelgeuse@pena /etc/env.d $ cat 40vtk VTK_DATA_ROOT=/usr/share/vtk/data VTK_DIR=/usr/lib/vtk-5.0 CLASSPATH=/usr/share/vtk/lib/vtk.jar Setting a global classpath is problematic because you get the jar to your java classpath even when you might not want to. It should be set in wrapper scripts (created using for example java-pkg_dolauncher). Please contact the java team if you need any help.
Hi Petteri, Thanks much for the heads up! Unfortunately, I am not very familiar with gentoo's way of handling java stuff:( Could you possibly point me to package in portage that does it properly and think I might be able to go from there. Thanks for your help. cheers, Markus
(In reply to comment #1) > Hi Petteri, > > Thanks much for the heads up! Unfortunately, I am not very familiar with > gentoo's way of handling java stuff:( Could you possibly point me to package > in portage that does it properly and think I might be able to go from there. > > Thanks for your help. > > cheers, > Markus > Pretty much everything inheriting java-pkg-opt-2 should be useful. Probably would be useful to add java to metadata.xml so that we can fix these issues ourselves without asking. Basically on Gentoo you the java-config tool to query the installed packages for CLASSPATH or in ebuilds use the eclass functions. Feel free to join #gentoo-java to ask questions.
I had a brief look at the java eclasses and it looks to me that java-pkg_dolauncher is not what we want since vtk.jar is only a library containing some vtk class wrappers. I am not sure if CLASSPATH is needed at all since I've never compiled java code against a library located in a jar. So, for now I've removed the CLASSPATH part in the ebuild completely and added you guys to metadata. So please feel free to change as you like. Thanks, Markus
(In reply to comment #3) > I had a brief look at the java eclasses and it looks to me that > java-pkg_dolauncher is not what we want since vtk.jar is only a > library containing some vtk class wrappers. I am not sure if > CLASSPATH is needed at all since I've never compiled java code > against a library located in a jar. dolauncher is for applications. It creates an intelligent wrapper script that calculates CLASSPATH from dependencies.
Since the CLASSPATH is gone from 40vtk is it all right to close this bug then? Thanks, Markus
(In reply to comment #5) > Since the CLASSPATH is gone from 40vtk is it all right > to close this bug then? I would say so, unless there are ebuilds in tree that depend on that CLASSPATH. But I found only mayavi depending on vtk and that seems to be not using the java part.
(In reply to comment #6) > > I would say so, unless there are ebuilds in tree that depend on that CLASSPATH. > But I found only mayavi depending on vtk and that seems to be not using the > java part. > Yeah that's what I was supposed to check too. If that's the case then let's close this.
