-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 9 Jul 2001, Guillaume Rousse wrote:
>There are already several existing java packaging project. See RPMS for java
>development (http://freshmeat.net/projects/rpms4java/),
They seem to store .jar files straight in /usr/share/java/. Each RPM
has an accompanying /etc/profile.d/ script which adds all .jar files in
/usr/share/java/ to the CLASSPATH. That's okay for now, but really
such a script would be better written once and included as part of the
distribution.
>and jpackage project (http://jpackage.sourceforge.net),
I see that the website doesn't have much content yet.
Why two projects?
>(http://jpackage.sourceforge.net/packages.php)
I can't download anything from there via anonymous FTP, is it not public
yet?
IMHO it would be better to make the packages 'noarch' rather than
'i386'.
>For the second, we created a dedicated mailing list,
>[EMAIL PROTECTED]
How do I subscribe to that list? The SourceForge website is really
unhelpful :-(.
>May i invite everyone interested to follow the discussion on this list,
>as there will be other people interested here ?
Yes, that sounds sensible. I'm going away on holiday for nearly a week,
but when I get back I can rejoin the discussion.
This message is cc'ed to [EMAIL PROTECTED]; I will
send future messages about Java only to that list and not to
[EMAIL PROTECTED]
>Now that i've advertised my own business :-), about the on-going discussion:
>-/usr/share/java is a widely-agredd consensus location for java file, for
>their arch-independant nature. Structure under this root is unclear, altough.
At the moment most packages seem to just put the .jar files directly
under there. Since each package normally has only one or two .jars,
that's not too messy.
>For the moment, i store directly jar file under this root, and create subdirs
>for apps, on the same model as /usr/lib and /usr/lib/postgres, for instance.
So an application would store its files in several subdirectories all
over the place - like ant might have /usr/bin/ant, /usr/share/ant/,
/usr/man/man1/ant.1.bz2, and maybe some others. That is good, because
it's the Unix convention to store files grouped more by type than by the
application they came from.
>Using distinct directories for class files and jar files could be a good
>point, but i would like to use the standard names lib and classes then.
So would I. But since putting jar files directly under /usr/share/ is
pretty well established, as a compromise it might be best to have a
standard name classes/ but not one for jars/.
>-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.
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.
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.
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.
- --
Ed Avis <[EMAIL PROTECTED]>
Finger for PGP key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7SZnsIMp73jhGogoRAi0IAJ0ZWU0AWK2LS+73ICCzQHRmSbRUFgCcCLxJ
eLwTb8lsZLZtEg2qRACVxBY=
=ZyBF
-----END PGP SIGNATURE-----
