-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 9 Jul 2001, Guillaume Rousse wrote:
>>>(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.
Yes, it works now. It didn't when I sent the message, but I didn't
investigate the source of the problem.
>>IMHO it would be better to make the packages 'noarch' rather than
>>'i386'.
>
>Evey java package is noarch.
Yes, you are right. Sorry, I just saw lots of 'i386' packages and
just assumed they were 100% Java.
>>>For the second, we created a dedicated mailing list,
>>>[EMAIL PROTECTED]
>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 :-).
>>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.
But I recognize that in practice the world is not like that. Different
implementations of the same API will have different bugs and different
performance characteristics. Even though it's intended that any of them
could be used, an application may rely on the quirks of one particular
version.
But if an application is fussy in that way, it's the application's
problem. If it needs its own particular implementation of DOM, and
nobody else's will do, then the jar file for that implementation should
go in the application's own directory. (And you could file a bug report
against that application, asking that it shouldn't rely on quirks of one
particular DOM library.)
Meanwhile, for more portable programs you pick one single
implementation, hopefully the best available, and make this the system
standard and the one that is installed in /usr/share/.
>They could be of different version also.
Only a problem if there are incompatible changes between versions. If
new versions are backwards-compatible then just install the latest - as
happens with C libraries, Perl modules and everything else. If there
are two incompatible versions then yes, some special treatment will be
needed (as happens for Qt and other libs).
>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.
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'). 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.
- --
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
iD8DBQE7ScIFIMp73jhGogoRAq/hAJ9uQzamLnnAXY4kU/mtk9OVai7JdQCaAppZ
M8wlIAdbhDO7mZz5zn4b34s=
=GsgZ
-----END PGP SIGNATURE-----
