Re: Summary of the idéas.
On Wed, Sep 19, 2001 at 09:04:46AM +0200, Ola Lundqvist wrote:
> 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? :)
>From the phrase "The only good X is a dead one", where X can be anything
you don't like ;P
> > > 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.
The problem is that it's generally startup scripts which invoke
/usr/bin/java, and there is no rule that says they'll use -classpath
rather than setting $CLASSPATH. Tomcat 4.0 uses -classpath, but 3.2 and
3.3 set $CLASSPATH (after storing the old one in $OLDCP).
> 2) Have two different wrappers.
Again, if there's two wrappers, the startup scripts would need to be
modified to choose one or the other.
Any other suggestions?
As suggested elsewhere, another possibility is a ~/.cp_remove file,
containing regexps of classpath entries to ignore. Mine would contain
".*" to eliminate everything. I can write up a shell script to do this
if there's no better idea (and people still want a system classpath at
all;).
[..]
> > 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
Oops, didn't read carefully enough.
> > > * 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.
I think we should keep a clear idea of the target audience. Is this to
replace startup scripts? Tomcat's startup script doesn't need any help,
in my experience. If the target audience is developers (projects without
startup scripts), fine, but keep in mind that a Debian-specific solution
will not be popular in a world where cross-platform development is a
reality (not just Sun advertising). My projects have to be buildable on
non-Debian boxes too, so I can't use a Debian-specific mechanism. I know
that most open source projects are the same. For me and most open
source projects, an Ant script with a build.properties listing all
required jars is the only cross-platform build system.
> > - 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. :)
Yes, fixing classpaths sucks :P The only thing that sucks more is
fighting the subtle bugs that can arise from putting miscellaneous jars
in the classpath.
> 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?
Clean-classpath solutions exist, and are now used in most projects I'm
involved in. Tomcat 4.0 is an excellent example. In addition, there are
scripts like [1] to aid developers, which set up a project-specific
classpath with minimal effort.
--Jeff
[1] http://newgate.socialchange.net.au/~jeff/jpe/
> Regards,
>
> // Ola
Reply to: