Bugzilla Bug 176547

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.