Ainsi parlait Edward Avis :
> On Mon, 9 Jul 2001, Guillaume Rousse wrote:
> >and jpackage project (http://jpackage.sourceforge.net),
>
> I see that the website doesn't have much content yet.
Use rpm index page instead (http://jpackage.sourceforge.net/packages.php)
On my own local mirror, it weighs a little 263 Mo
> Why two projects?
Cause few discussion about merging has not been succesful. And there are
maybe tons of others similar project of individuals lurking around :-)
>
> >(http://jpackage.sourceforge.net/packages.php)
>
> I can't download anything from there via anonymous FTP, is it not public
> yet?
I just tried jpackage.sourceforge.net/pub/jpackage, everything seems OK.
> IMHO it would be better to make the packages 'noarch' rather than
> 'i386'.
Evey java package is noarch. arch-dependant are either other apache project
packages (such as xalan-c), java-related native progs (jikes, java-wrapper),
or native code part of java apps (tomcat-apache connectors).
> >For the second, we created a dedicated mailing list,
> >[EMAIL PROTECTED]
>
> How do I subscribe to that list? The SourceForge website is really
> unhelpful :-(.
Sorry, it is yet a private list. I'm asking my other fellow to open it, so
stay on cooker for now.
> >-directly adding every class and jar file fo CLASSPATH is wrong IMHO,
> >whatever the way used (script, link to JDK_HOME/lib/ext dir, and so on),
> >because it adds lots of useless symbols for the classloader,
>
> They're not useless... you wouldn't install the library if it were
> useless.
>
> Has anyone benchmarked to find out whether having more things in the
> CLASSPATH actually makes a noticeable difference to Java startup speed?
> I don't think it will, but obviously without benchmarking I can't
> substantiate that.
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.
> If speed really is a problem then there might be a case for keeping the
> CLASSPATH as small as possible. Apart from that I can't see a good
> reason.
>
> >and can provoke name clashes.
>
> No, because of Java's package name rules. The only possibility for name
> clashes is in two versions of the same library, in which case rpm would
> erase one before installing the other. Eg if you upgrade from
> xerces-j-1.2.3 to xerces-j-2.3.4, the old jar files will be removed.
Some classes are present in several libraries : w3.org.xml, for instance,
appears in every XML parser. They could be of different version also.
> In special cases where an application really does need a different
> version of the library from that installed globally, it can have its
> own application-specific library directory (under /usr/share/whatever/)
> and have a wrapper to set the CLASSPATH.
>
> >It's a lot better to have launch script establishing correct CLASSPATH
> >before starting application.
>
> For applications like ant, which always come with a Unix shell script
> wrapper, that is okay. But what about applications which are started
> with just 'java Classname'? Surely we don't want to have to create a
> new wrapper script for every single Java application that might get
> installed.
Standard wrapper is easy to create and maintain, and allows lots of useful
customization. I recently adapted our own ant script for ArgoUML, allowing me
to use IBM JDK for running it instead of my default Sun JDK.
> And what about when you are developing Java code? Suppose you write
> some code that imports a set of Java classes. When you try to compile
> it, the compiler says that the class is not found. Fine, you go and
> install the necessary package. But then after installing it still
> doesn't work!
>
> Would you really say to the user that every time you want to run the
> compiler, you have to fiddle about setting the CLASSPATH by hand so that
> it includes the jar files you need? The idea of packaging Java
> libraries as RPMs is to make them easy to install. If the user still
> has to change environment variables by hand, then what is the point of
> packaging? It would be almost as easy to download the .jar file itself
> and add it to your CLASSPATH.
>
> Think about the PATH for executables. When a new application or utility
> is installed, its executables normally go into /usr/bin/ so they are
> directly included in PATH. Users do not have to set PATH by hand to
> include the binaries for this particular application, nor does the
> packager have to include wrapper scripts.
>
> Yes, it does take a very long time to list all the possibilities when
> you hit TAB in bash. But that is outweighed by the convenience of
> installing a package and having it just work - which is the way things
> should be.
>
> Yes, there is a chance of name clashes if something in /usr/bin/ has the
> same name as something in /bin/. But again this is not serious enough
> to worry about. In Java, name clashes are more difficult because all
> packages include the DNS name of the author. With binaries, rpm will
> check for filename conflicts when installing (so you can't have two
> different files called /usr/bin/frob in two packages). It's true that
> this checking doesn't work so well for Java, since the same class could
> be defined in packages with different filenames for the .jar, but the
> basic checking of not allowing two files called xerces.jar is still
> there.
>
> In short, I think the worry about name clashes is exaggerated and it
> certainly does not outweigh the advantage of having a library install
> and work straightaway - which is the whole point of making packages.
I think people developping in java know how to set and establish their
CLASSPATH. Morevoer, i think they like to have precise control over it, where
such a general mechanism would not allow it.
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
--
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://bohm.snv.jussieu.fr/~rousse/gpgkey.html
