[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.
>   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.


> * Ie, should we split out the packages in a "standard" part and
>   a optional part.
> * Anyway they should be included in the right order.
>   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: