Re: Summary of the idéas.
On Tue, Sep 18, 2001 at 02:44:00PM +0200, Ola Lundqvist wrote:
> Hi
>
> I'll try to summarize what have come up so far during the
> discussion.
[snip good stuff]
> To discuss:
> -----------
>
> * Should we allow library packages to provide different versions?
> Like libxalan2 that provides both xalan1 and xalan2 jars.
> * Should there be a script that automaticly fixes the symbolic
> links in the /usr/share/java directory.
> * Must programs also place their files in /usr/share/java.
I'd have thought program-specific jars are by definition, not shared,
and therefore do not belong on /usr/share?
>
> Classpath:
> ==========
>
> The problem is that there are a couple of jvms out there, and they
> are more or less compatible with each other. How do we solve this?
>
> Virtual machines:
> -----------------
>
> There have been quite lot of discussion about the classpaths...
:)
The only good classpath is a dea.. clean one.
> There are a couple of things that I have found that people think
> is good.
>
> * If the user specifies a classpath that one should override the
> "system classpath". But still the "system classpath" should be
> there if the user does not specify enough information.
Okay, but by "override", I mean *really* override, not just mask. Don't
rely on later versions being strict supersets of earlier versions,
thereby "hiding" the old version, because if they're not, I think you'll
get sealing violations.
> This can be done in the following way:
> /usr/bin/java (or similar) takes the $CLASSPATH and contacinates
> it with the "internal" classpath for the jvm.
> Like, CLASSPATH=$CLASSPATH:$INTERNALCLASSPATH before running
> the real jvm.
This amounts to adding another layer to hide the old layer. Bits of the
old layer can show through and cause problems.
> * All jvm:s and java compilers must follow this structure.
> * Or is there any disadvantages with this?
>
> Dependencies:
> -------------
>
> * Some sort of function should be there to get the classpath that
> a specific jar-file needs to run correctly.
That would be nice. Perhaps just a text file listing required jars?
Also consider that most programs' startup script has this info
implicitly. If the startup script handles everything including classpath
setup, what else is needed?
> * This tool should be implemented to help the developers and
> maintainers to create a good classpath before running the jvm.
> * It should also be possible to use it to create the necessary
> symbolic links, to for example tomcat. So it should probably
> spit out the jars that are needed, so you can do anything you
> want with them.
>
> Default classpath:
> ------------------
>
> * This discusses the default classpath, except the classpath that
> are needed by the jvm. Should there be any such thing?
Or rather, *can* any such thing exist without:
- breaking non-packaged programs which assume a clean classpath.
- upsetting a lot of developers who like to make a clean-classpath
assumption. I think most Apache coders fall into this category,
because most (all?) Apache projects ignore the classpath, and use an
Ant properties file to find jars. Perhaps other Apache people <waves
to Marcus Crafter> can confirm/deny this.
--Jeff
> * Ie, should we split out the packages in a "standard" part and
> a optional part.
> * Anyway they should be included in the right order.
> CLASSPATH=$USERCLASSPATH:$STANDARDJARS:$JVMJARS
> The java wrapper must implement this if it should be there.
>
[snip more good stuff]
> Well the parts that people do not object on, I'll include into
> the policy.
>
> Regards,
>
> // Ola
>
> --
> --------------------- Ola Lundqvist ---------------------------
> / opal@debian.org Björnkärrsgatan 5 A.11 \
> | opal@lysator.liu.se 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 /
> ---------------------------------------------------------------
Reply to: