On Wed, Sep 19, 2001 at 11:03:50AM +1000, Jeff Turner wrote:
> > There have been quite lot of discussion about the classpaths...
>
> :)
>
> The only good classpath is a dea.. clean one.
Just curious what does dea stand for? :)
>
> > 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.
Ok. The option should be there. I have two solutions.
1) Let the wrapper make a difference between $CLASSPATH and the
argument -classpath. One of them (-classpath?) does a complete
override, and the other one just mask.
2) Have two different wrappers.
> > 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.
Yes. But in this case we are talking about the jvm (java.*) classes
so that should not be a big problem. But you are right that it might
cause trouble if we define a set of standard (and external) packages,
see below.
> > * 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?
Probably yes, but with a nice tool around that data.
> Also consider that most programs' startup script has this info
> implicitly. If the startup script handles everything including classpath
> setup, what else is needed?
Yes that is true. This just simplifies things and make it easier
to handle (and build) libraries.
> > * 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.
Well it depends on what packages that are in the default classpath. :)
We can be _very_ restrictive about it.
> - 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.
Well I object :) I have personally had to manually fix all classpaths
personally. That is why I want a tool that fixes the classpath for
me when I tell what jars that I directly need. :)
But this have not much to do with a default classpath. I'm not
sure if I like the idéa myself. But I can be convinced. But if the
option to have a clean classpath exist this might(?) not be a problem,
or?
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 /
---------------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
