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 --------------------------- > / [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 / > ---------------------------------------------------------------
