Ainsi parlait Edward Avis :
> >Sorry, it is yet a private list. I'm asking my other fellow to open it, so
> >stay on cooker for now.
> Okay, I'll stay on this list. Please ignore the Reply-To header in my
> previous message :-).
Corrected now. You can subscribe by going there
http://sourceforge.net/projects/jpackage, as well as look as the reply from
Henry you should have missed.
> >>Has anyone benchmarked to find out whether having more things in the
> >>CLASSPATH actually makes a noticeable difference to Java startup speed?
> >
> >Agreed, there isn't any benchmark here. Anyway, i don't like to have
> >my CLASSPATH polluted by cumbersome classes used once every year,
> >making it unpractical to read.
>
> % echo $CLASSPATH | tr : "\n"
>
> Looks nice enough especially if most of the jar files are stored under a
> common root. I don't think that this is a good reason not to add
> libraries to CLASSPATH.
>
> >Some classes are present in several libraries : w3.org.xml, for instance,
> >appears in every XML parser.
>
> Fair point. Although this is because, in principle, the different
> implementations should be interchangeable. You should be able to pick
> one particular Java XML parser, say 'this is the standard for our
> system', and all apps will use it.
>
> You could enforce that with dependencies; each implementation of
> w3.org.xml.dom 'Provides' the service 'java_xml_dom'. Then have a rule
> saying that only one package can provide this service, and it's an error
> to have two different ones installed. Debian can do this, I don't know
> whether RPM can.
Already the case : every such rpm provides jaxp (and sun reference
implementation provides sun-jaxp), but that doesn't mean you can't have two
different implementation present.
[..]
> >Standard wrapper is easy to create and maintain,
>
> Not necessarily. Suppose you have an application which needs the Foo
> library, which is included as part of the Apache Project's Footle
> distribution.
>
> Because jar files are _not_ being automatically added to the CLASSPATH,
> your wrapper script needs to add the necessary filename itself. But
> what is the filename?
>
> /usr/share/foo.java
> /usr/share/footle.java
> /usr/share/apache-footle.java
> /usr/share/classes/Footle/
> or lots of others. It's not possible to write the wrapper script
> without relying on what the particular filename is going to be. Since
> there is no standard naming convention for .jar files, it's not possible
> to know in advance.
As WE are the packager, we do know what the name is :-)
By having our ant package requires our xerces package, we know that unless
using a --nodeps flag, there will be a xerces.jar present in /usr/share/java.
That's one of the strenght of a coherent package set.
> OTOH, if you just arranged that everything in /usr/share/ gets added to
> the CLASSPATH, then you don't worry about filenames - if the necessary
> libraries have been installed, they will work.
>
> >I think people developping in java know how to set and establish their
> >CLASSPATH.
>
> Of course. People developing in Perl would know how to set PERL5LIB.
> But it is a pain!
>
> I'm fed up with having to set CLASSPATH for every library, that's why I
> want to package them!
>
> >Morevoer, i think they like to have precise control over it,
>
> You still have precise control. You're always free to add or remove
> things from the CLASSPATH variable, or set it to whatever you want.
> That doesn't change.
>
> But the default setup, for users who haven't changed anything, should
> work as smoothly as possible.
>
> >My main concern was about newbies, and there a launch script would
> > definitely be more useful : think about typing just argouml (with
> > completion) rather than java
> > org.tigris.argouml.MainClassWhichIForgotTheName
>
> Yes, that's still better (although look at Linux's 'Java binary
> support').
I made a package for this one, see java_binfmt-1.0.2-1mdk.i586.rpm :-)
> But even if you do have wrappers, they are easier to
> maintain if they don't have to add extra stuff to the CLASSPATH and
> don't depend on knowing the filenames of jar files.
>
> For cases where a particular version of a library is needed, for
> packages that need other environment variables set anyway, and for
> anything else out of the ordinary, you can and should write a wrapper
> script. But if we can make 80% of Java stuff work out of the box
> without needing wrappers, we should do so.
I find definitly more easy to construct a CLASSPATH from nothing when realy
needing it, than looking into the current one when facing to a real one. As i
use IDE for large project, anyway, they keep track of CLASSPATH for me.
I also think it's safer to keep environment clean, so to avoid potential side
effect. For example, some building script (exemple: ant) test libraries
availability by testing CLASSPATH : should we have to nullify it before any
build to have precise control over what's getting build ?
And as wrappers are definitely more confortables, and we do have name
controls, i prefer wrappers.
--
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://bohm.snv.jussieu.fr/~rousse/gpgkey.html
