Bug 176547 - sci-libs/vtk sets a global CLASSPATH
Bug#: 176547 Product:  Gentoo Linux Version: unspecified Platform: All
OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2
Resolution: FIXED Assigned To: markusle@gentoo.org Reported By: betelgeuse@gentoo.org
Component: Java
URL: 
Summary: sci-libs/vtk sets a global CLASSPATH
Keywords:  
Status Whiteboard: 
Opened: 2007-04-30 11:11 0000
Description:   Opened: 2007-04-30 11:11 0000 
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.

------- Comment #1 From Markus Dittrich 2007-04-30 12:48:30 0000 ------- 
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

------- Comment #2 From Petteri Räty 2007-04-30 14:00:23 0000 ------- 
(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.

------- Comment #3 From Markus Dittrich 2007-05-01 12:37:23 0000 ------- 
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

------- Comment #4 From Petteri Räty 2007-05-01 13:47:08 0000 ------- 
(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.

------- Comment #5 From Markus Dittrich 2007-05-01 17:03:55 0000 ------- 
Since the CLASSPATH is gone from 40vtk is it all right
to close this bug then?

Thanks,
Markus

------- Comment #6 From Vlastimil Babka (Caster) 2007-05-01 17:10:47 0000 ------- 
(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.

------- Comment #7 From Petteri Räty 2007-05-01 18:10:45 0000 ------- 
(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.