On Wed, Apr 03, 2002 at 05:31:53PM -0800, Joe Emenaker wrote:
>
> > I was just thinking of a simple way to set up my classpath so I made
> > this suggestion. But if it is not common to do somthing like that, then
> > I have to live with that. And maybe collecting all libs might not lead
> > to the expected result, because of combining libs in different versions
> > with the same classes in it. Then you need a script that checks the
> > consistency of the classpath and warns when there are classes more
> > then one time in the classpath
>
> I'm beginning to think that we need a requires/provides database for java
> libs or something. One thing I've noticed about JDK 1.4 is that there's a
> lot of stuff now included in the basic package that used to be available as
> a separate package. Javasoft's XML libraries are one example. So, with
> previous versions of the JDK, you'd need to specifically include your XML
> parsing libs... but you don't with JDK 1.4.
>
> So, I'm wondering if it would be worthwhile for a Debian system to have a
> database very similar to the dpkg database... describing which packages
> depend upon which other ones... and which JVM's provide which packages
> natively. That way, if I need the javax.xml libraries, my startup script
> could include something like:
I think it is worth it, yes. For issues that virtual packages can fix
it should be used. Like if someone packages a free implementation of
something that a jvm provides a virtual package should be used also
so the jvm can add it too.
> JVM="JDK1.3"
> CLASSPATH=${CLASSPATH}:`require-java-library "$JVM" javax.xml`
>
> When JVM is "JDK1.3", then the require-java-library script would return the
> path to the jar that had the javax.xml tree in it. If JVM were "JDK1.4", the
> script would return nothing at all, since the javax.xml stuff is included in
> JDK1.4. This is kind of a crude example. I've got some other ideas that
> would make this a bit slicker... but you get the idea.
But as you have noticed a CLASSPATH database is needed too to tell where
it is stored.
> This can help reduce the problem of multiple jars in the classpath having
> the same packages. It should also reduce the number of unneeded jars in the
> classpath... which can't hurt execution times.
Agreed.
If people have suggestion on how to implement it I'll be more than happy.
Regards,
// Ola
> - Joe
>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
--------------------- Ola Lundqvist ---------------------------
/ [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \
| [EMAIL PROTECTED] 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
