-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 9 Jul 2001, Guillaume Rousse wrote:
[[EMAIL PROTECTED]]
>You can subscribe by going there http://sourceforge.net/projects/jpackage,
I've subscribed. Future messages on this subject will go only to that
list. For real this time :-).
>as well as look as the reply from Henry you should have missed.
He seems to disagree with me and agree with you... but we can discuss
this some more :-).
>>>Some classes are present in several libraries : w3.org.xml, for instance,
>>>appears in every XML parser.
>>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.
>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.
But it would be good to have one 'recommended' implementation, to say
'if you develop your own apps, please use this one'.
>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.
You don't think that instead of requiring xerces, it should require
'java_w3c_xml_parser' and then use whatever implementation is installed?
I suppose that requiring xerces.jar is okay. It's not too bad to assume
that nothing else will use that name. And if you need a particular
version you can use xerces-1.2.3.jar.
In fact, I think that the version number should always be included in
the jar file's name, to allow for multiple versions installed easily.
Then xerces.jar could be a symlink to one of the versions, probably to
the latest version.
If an app needs a particular version of xerces, it could use
xerces-x.y.z.jar. If it just needs 'xerces' and should work okay with
the latest version, it should use xerces.jar. And if it needs xerces v1
and not the incompatible version 2, it should use xerces-1.jar.
Like is done for .so files:
xerces.jar -> xerces-2.3.4.jar
xerces-2.jar -> xerces-2.3.4.jar
xerces-2.3.jar -> xerces-2.3.4.jar
xerces-2.3.4.jar
xerces-1.jar -> xerces-1.2.3.jar
xerces-1.2.jar -> xerces-1.2.3.jar
xerces-1.2.3.jar
>That's one of the strenght of a coherent package set.
I suppose there is a slight clash of purpose. You want to create a set
of packages, but I was asking on the Mandrake list about a policy
allowing other people to create packages. So I didn't want to assume
that people would behave in a 'coherent' way :-)
However I think your assumption is okay. Work out a convention for
packages as part of a coherent set, and it should be possible for third
parties to create packages following that convention and have them work
well together.
[should the CLASSPATH be set automatically to include the contents of
/usr/share/java/?]
>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.
But you can still do that! Nothing stops you from doing
% unset CLASSPATH
% export CLASSPATH=whatever...
But you shouldn't be forced to do that just to get something to compile.
In some cases it may be unavoidable, but where it is not, the CLASSPATH
should be set to something that's going to work.
>As i use IDE for large project, anyway, they keep track of CLASSPATH
>for me.
In which case you'd also not have a problem with an autodetected
CLASSPATH, since your IDE would change it anyway!
>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
But isn't that what you want? Ant is trying to find out what libraries
are available on the system. Surely if a library is installed, ant
should be able to find that out?
>should we have to nullify it before any build to have precise control
>over what's getting build ?
The same thing applies to configure scripts for non-Java programs.
'Checking for libtiff... yes'. If you want precise control over what's
being built, you have to set LD_LIBRARY_PATH so as to fool the configure
script into not noticing what is installed.
If you want to do that, you can. But the autodetection is there for a
purpose and the default needs to be that it works correctly. Otherwise
what is the point in having autodetection at all?
>And as wrappers are definitely more confortables, and we do have name
>controls, i prefer wrappers.
Sure, have wrappers for any Java app if you want them. If you have a
wrapper it doesn't really matter what the CLASSPATH is, since you can
set it to what you like. I'm arguing that the default setting, in the
absence of any wrappers or manual setting of variables, should be a
CLASSPATH that includes the libraries currently installed on the system.
Do you think that the naming convention for jar files I described above
is a good idea? I think it would solve the problem of having multiple
conflicting versions in the CLASSPATH. Suppose you set that variable
with:
for i in `echo /usr/share/java/* | grep '^[^.]+\.jar$'`; do
export CLASSPATH=$CLASSPATH:$i
done
Then the default path would include xerces.jar but not xerces-2.3.4.jar
or xerces-1.2.3.jar. In other words, it would have the 'preferred'
(most recent) version of every Java library. Of course if your
application specifically needs an older version, you need to set
CLASSPATH by hand - but that is no worse than before.
This doesn't overcome the problem of having multiple implementations of
the same API included in the path; basically the one that had the
alphabetically earliest filename would be picked. But I think that
picking one at random is a better choice than including none of them and
forcing the user to set variables by hand. It will work most of the
time, which is a lot better than none of the time.
- --
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
iD8DBQE7SfX5IMp73jhGogoRAqtZAJ93Oh5oi6Muf/eukf7IYL9XwoiJgQCdF3va
IcD48z8Dzj6UH9mNR7Geqv8=
=j4+K
-----END PGP SIGNATURE-----
