Re: [Cooker] Packaging Java class libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, David Walluck wrote: I propose that Java libraries be installed under /usr/share/java/, either as .jar files or as subdirectories full of .class files. And /etc/profile.d/java should do something like: for i in /usr/share/java/*; do export CLASSPATH=$CLASSPATH:$i done This is how we do it (we being me and someone else, the only two on this list that seemed really interested in Java). Mandrake, as a company, doesn't seem to care much. They do not offer the JDK Hmm... in that case there is no 'Mandrake policy' on Java. Unless things like Kaffe and GNU Classpath are packaged and actually used. I ask because I want to create RPMs of some (free) Java libraries and I want to know where to put the files. If there isn't a Mandrake convention for this stuff then we could look at what Red Hat do. Some RedHat contrib packages install in /usr/share/java/ (good) and install a new script in /etc/profile.d/ for each package (bad). But that is only contribs, I wonder what happens for the main part of the distribution? Do Red Hat even put any Java libraries into the main distribution? I'll have to go and check. (And if SuSE, Caldera, TurboLinux or any of the other semi-proprietary RPM-based distros have some convention for Java, we could look at that. Also see what Debian, Slackware and Stampede do. I'm sure Debian has some well-thought-out Policy on Java stuff.) There are no java rpms in Cooker. for example. So I wouldn't contribute the packages I build into Cooker-contrib, because they'd be a bit useless without a JDK to run them on. But I would still like to get them 'out there' for RedHat-like systems. Problem is, in X the ~/.bash_profile doesn't seem to be read, and /etc/profile is over-written by msec all the time, so I can't figure out a good way to get these into the path except a single script in /etc/profile.d would probably do the trick. Yes, that's what I'm suggesting. Install a file in /etc/profile.d/. This is the Right Way to set environment variables because it's just a file you can install or uninstall with RPM - no patching or appending to existing files. And you'd probably want for i in *.jar instead of * incase there are some directories or properties files or something else in that directory, I thought the directory might contain subdirectories of .class files too. Some Java libraries are still distributed this way rather than as .jar files. If you think that /usr/share/java/ might be used for stuff other than compiled Java classes, then create a subdirectory /usr/share/java/classes/ and add the contents of that to CLASSPATH. Although this conflicts with what some other people are doing, putting stuff directly into /usr/share/java/. Maybe say that we should add: - - /usr/share/java/*.jar - - /usr/share/java/classes/* to the CLASSPATH. - -- 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 iD8DBQE7SWTrIMp73jhGogoRAlwSAJ0URlqNEQcQprdzyuXZfzPUHlydBQCfcmBK qppNX+39F39Xz/k5/4X0SH4= =9dbp -END PGP SIGNATURE-
Re: [Cooker] Packaging Java class libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, Axalon wrote: [Java] Precedence set by Kaffe pkg, which is atleast in theory compliant with the standard. /usr/java should be broke apart into /usr/lib, /usr/bin, and /usr/share/name. I agree, but try telling Sun that :-P. I think that we should let Sun have their stupid broken /usr/java/ for the official Sun JDK and related packages. But we shouldn't use that directory for any new stuff. Global libs (for lack of knowledge?) would get installed into the generic CLASSPATH (/usr/share/kaffe\jre\jdk\java/lib), Do you mean that Kaffe has its own directory for class files, like /usr/share/kaffe/whatever/lib/. and that other Java environments would have a different directory? I think it would be much better to have a single directory for 'all globally-installed Java libraries'. Of course the individual Java implementations can have their own directories too, but there should be one definite place where libraries can be installed. Suppose I wanted to package the Java version of the Xerces XML parser. What directory should the RPM install into? If it installs into /usr/share/kaffe/... then the library wouldn't work with the Sun or IBM JDKs. If it installs somewhere else, it wouldn't work with Kaffe, and so on. So while it is okay for Kaffe to have its own lib directory (perhaps for 'system' packages which are specific to that JVM), there needs to be a way to install a Java library and have it Just Work. where as application specific would create thier own dir under /usr/share/prog\pkg and use a wrapper to alter the CLASSPATH. Yes, that sounds sensible. Things like ant, the Java build tool, could do that. Although you do want to avoid libraries being installed as 'application specific' when in fact they are just libraries which could be used elsewhere. This doesn't mean a socalled global HAS tobe put into the global path, they could all be stuffed into /usr/share/prog\pkg to allow for version mixing.. I think that *if* an application needs a specific version of some library, and this is some wacky version that isn't likely to be used by anyone else, then it's okay for that application to have its own copy of the class files. However, if you get an app which just says 'this requires the com.foo.bar packages', then that library should be installed as a separate library package, if it is distributable. With C programs, Linux distributions don't allow much messing around with specific versions of libraries. We don't allow gif2png to use version 1.2.3 of libpng while xemacs needs version 1.4.6. They should both be compiled to use some common version, probably the latest stable version, and if gif2png doesn't work with the latest libpng, then that is a bug. In cases of incompatible new versions (normally a major version number change, as in Qt 1.x vs 2.x), the two versions may both be installed with a small name change to distinguish them, but even then the older version disappears as soon as possible. Distros don't allow prima donna applications that insist on having *that* exact version of a particular library and carrying it around with them. Java has not yet developed a good mechanism for making sure that a standard set of libraries is installed, so often you find prepackaged apps including their own copies of libraries because this is easier than telling the user 'first go and install X, then Y and Z...'. But if you can get the stuff properly packaged and the dependencies noted, there is no need for all this. We should try as hard as possible not to have application-specific bits of library installed in random places. Especially not to have fifteen slightly different implementations of org.w3c.xml.DOM or whatever. But of course class files which are specific to one application are okay, and should be installed in that application's own directory. - -- 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 iD8DBQE7SWkEIMp73jhGogoRAl+CAJ0dYN7V9flmBtAmkzF6cTfTICjhPACcCxT/ 2OQDlkRyW+x3VrOHA8pipgU= =SXKx -END PGP SIGNATURE-
Re: [Cooker] Packaging Java class libraries
In Mon, 9 Jul 2001, Edward Avis cum veritate scripsit : [...] If you think that /usr/share/java/ might be used for stuff other than compiled Java classes, then create a subdirectory /usr/share/java/classes/ and add the contents of that to CLASSPATH. Although this conflicts with what some other people are doing, putting stuff directly into /usr/share/java/. Maybe say that we should add: - - /usr/share/java/*.jar - - /usr/share/java/classes/* to the CLASSPATH. Yes, that looks fine! Maybe a switched order should be preferred in order to show other users who want to build their own srpms that /usr/share/java/classes/* has the higher priority and then /usr/share/java/*.jar . Frank -- Sending unsolicited commercial email to this address may be a violation of the Washington State Consumer Protection Act, chapter 19.86 RCW. Frank Meurer [EMAIL PROTECTED], PGP ID: 0x5E756DA8 Key fingerprint = 169A 1138 8DB4 528F 2F01 20A6 EDD8 49C3 5E75 6DA8
Re: [Cooker] Packaging Java class libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jul 2001, Frank Meurer wrote: Maybe say that we should add: - - /usr/share/java/*.jar - - /usr/share/java/classes/* to the CLASSPATH. Yes, that looks fine! Should first check what other distributions do. Maybe a switched order should be preferred in order to show other users who want to build their own srpms that /usr/share/java/classes/* has the higher priority and then /usr/share/java/*.jar . Hmm, maybe. I'm not sure which style of packaging I prefer. I don't think it matters that much. - -- 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 iD8DBQE7SWxfIMp73jhGogoRAr+0AJ90++lAdTUa2cqg6IaEbVIgKXGt5wCeLecX pahMvzlb5zfzrzV5Re+9TIs= =hJye -END PGP SIGNATURE-
Re: [Cooker] Packaging Java class libraries
Sorry for catching this thread lately. There are already several existing java packaging project. See RPMS for java development (http://freshmeat.net/projects/rpms4java/), recentely announced on sourceforge, and jpackage project (http://jpackage.sourceforge.net), which wasn't publicy announced yet. I'll speak for the second one, as i'm one of the packager, along with Cristian Zoffoli (another cooker folk), Henry Gomez (official jakarta packager), and Pete Chown. The goal for the project are double : - create and maintain a set of high-quality coherent java package for several Linux distributions (currently Mandrake RedHat) - discuss and create standard for java packaging For the first point, see current package list (http://jpackage.sourceforge.net/packages.php) For the second, we created a dedicated mailing list, [EMAIL PROTECTED] May i invite everyone interested to follow the discussion on this list, as there will be other people interested here ? 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. 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. 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. -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, and can provoke name clashes. It's a lot better to have launch script establishing correct CLASSPATH before starting application. -- Guillaume Rousse [EMAIL PROTECTED] GPG key http://bohm.snv.jussieu.fr/~rousse/gpgkey.html
Re: [Cooker] Packaging Java class libraries
-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
Re: [Cooker] Packaging Java class libraries
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
Re: [Cooker] Packaging Java class libraries
-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
Re: [Cooker] Packaging Java class libraries
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
Re: [Cooker] Packaging Java class libraries
Guillaume Rousse wrote: Corrected now. You can subscribe by going there http://sourceforge.net/projects/jpackage, as well as look as the reply from Do I have to use the sourceforge page or can I send some subscribe message to this list. If so, how? 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. Well yes, so do I, because of namespace conflicts, but unfortunately not everything has a wrapper, unless a script is provided in place of java, that checks if a classpath has been set, and if not, tries to construct an all-encompassing one -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Packaging Java class libraries
-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
Re: [Cooker] Packaging Java class libraries
On Sun, 8 Jul 2001, Edward Avis cum veritate scripsit : I have my .bashrc set up to do this automatically for every file in a certain directory. It would be possible to add a new script in /etc/profile.d/ to do this. I install 3rd party jars in a shared directory (NFS) and change/add my CLASSPATH in my .bashrc. Due to development with developer jars with rapidly changing API's we use different versions of different packages and adjust our CLASSPATHs to make sure that the software and its API's will harmonize. But the guy at home with his freshly blown away windoze system and his shiny new Linux Mandrake System there must be a solution for click- and-run. Sun sometimes recommend that you install new .jar files in /usr/java/jre/lib/ or /usr/java/jre/lib/ext/. Then they get picked up automatically without needing to be in the CLASSPATH. But I think this is not really appropriate for stuff that doesn't come from Sun, and I'm not sure that /usr/java/ is a good place for anything, although Sun seem to have claimed it. Why not? I guess that a symlink from /usr/java to a better place should also work. Which JDKs and JRE do actually behave like you described??? One guy has packaged lots of Java stuff for Red Hat's contrib section, for example http://www.rpmfind.net/linux/RPM/solaris//RPMS/i386//Acme-1.0-2.noarch.html. This installs a tree of .class files under /usr/share/Acme/ and adds two new scripts to /etc/profile.d/ to add this directory to the CLASSPATH. Personally, I think that having every package add a new script to profile.d/ is messy. Better to have a single one and have it automatically pick up things installed under some specified directory. Agreement. So is there a Mandrake policy or precedent for this stuff? Do any other distributions have a policy we could copy? If not, I propose that Java libraries be installed under /usr/share/java/, either as .jar files or as subdirectories full of Agreement but what says the Linux Standard Base? I would prefer this directory /usr/share/java/ and a symlink to it from /usr/java. And in /usr/share/java/ there should be the jre/lib dirs you mentioned above. .class files. And /etc/profile.d/java should do something like: for i in /usr/share/java/*; do export CLASSPATH=$CLASSPATH:$i done Hmmm... doesn't look bad! But... maybe there will be (with a /huge/ growing number of jars etc.) some broken dependencies or conflicts due to the wrong sequence of jars in CLASSPATH. E.g.: You install a package which needs i.e. the new JMF 2.1.1 and comes with it. For /this/ software the new jmf jar must be prepended to the old classpath. If the installer and/or /etc/profile does it right then the new software will run, but /old/ software which needs the old JMF 1.x won't run anymore. (I know that you can't deliver JMF due to license but it's only an example.) How does you think about that? And what about a *big* CLASSPATH if you have installed dozens of java packages? Frank -- In C we had to code our own bugs. In C++ we can inherit them. Sending unsolicited commercial email to this address may be a violation of the Washington State Consumer Protection Act, chapter 19.86 RCW. Das Verschicken unverlangter kommerzieller email an diese Adresse ist verboten (LG Traunstein, 2 HK O 3755/97 vom 14.10.1997, CR 1998, 171f). Frank Meurer [EMAIL PROTECTED], PGP ID: 0x5E756DA8 Key fingerprint = 169A 1138 8DB4 528F 2F01 20A6 EDD8 49C3 5E75 6DA8
Re: [Cooker] Packaging Java class libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, Frank Meurer wrote: [installing Java library .jar files] Sun sometimes recommend that you install new .jar files in /usr/java/jre/lib/ or /usr/java/jre/lib/ext/. Then they get picked up automatically without needing to be in the CLASSPATH. But I think this is not really appropriate for stuff that doesn't come from Sun, and I'm not sure that /usr/java/ is a good place for anything, although Sun seem to have claimed it. Why not? Well, it's an okay place for the official Sun JDK. Sun distribute an RPM for Linux that installs in /usr/java/, with an elaborate directory structure underneath for binaries, .jar files and so on. What Sun do, IIRC, is to have /usr/java/jdk-1.3.1/ and under there a jre/lib/ directory for libraries. We can't make other packages dependent on the '1.3.1' bit, and we can't really make them depend on knowledge of Sun's odd directory structure, which might change in the future. So some other place is needed. You could make another directory under /usr/java/, such as /usr/java/lib/, but I think it might be more FHS-compliant to have something under /usr/share/. Which JDKs and JRE do actually behave like you described??? I don't know; what I do know is that with Sun's JDK you can dump packages into /usr/java/jdk-1.3.1/jre/lib/ext/ and they'll magically start working. But this is not very deep magic, it could easily be reproduced for a different directory with a simple shell script or wrapper for 'java'. I propose that Java libraries be installed under /usr/share/java/, Agreement but what says the Linux Standard Base? Nothing specific in there about Java. Do you mean the FHS? There's noting about Java in there either, but it does say: 18. Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share. That sounds like Java libraries... OTOH, they are libraries, despite being architecture-independent, so maybe /usr/lib/ is better. After all, Perl libraries go in /usr/lib/perl5/ not under /usr/share/. (Goes and checks the FHS) Oh no, the FHS specificially covers this: 19. For example, the perl5 subdirectory for Perl 5 modules and libraries. Right. So even though something may be a 'library' in some sense, if it's architecture-independent it should go in share/ not lib/. I would prefer this directory /usr/share/java/ and a symlink to it from /usr/java. I am a bit annoyed that Sun unilaterally decided to grab the directory /usr/java/ and install random stuff under it in a not very sensible directory layout. They can do that on Solaris if they want, but preferably not Linux. I don't think we should encourage them by putting anything more in there :-) Since /usr/java/ contains binaries, documentation and all sorts of stuff, I don't think it's appropriate for /usr/share/, which I think is for architecture-independent files (like Java libraries!). for i in /usr/share/java/*; do export CLASSPATH=$CLASSPATH:$i done But... maybe there will be (with a /huge/ growing number of jars etc.) some broken dependencies or conflicts due to the wrong sequence of jars in CLASSPATH. Mostly this will not happen due to Java's package rules. A library from one vendor will have classes called com.snakeoil.palisade.Whatever and another vendor will use com.gerbil-gratings.simphoni.Whatever so they can't clash. This even happens for different libraries implementing the same spec, such as XML DOM. You set a string in your source code to decide whose implementation to use. E.g.: You install a package which needs i.e. the new JMF 2.1.1 and comes with it. For /this/ software the new jmf jar must be prepended to the old classpath. If the installer and/or /etc/profile does it right then the new software will run, but /old/ software which needs the old JMF 1.x won't run anymore. Ah, but that is the same problem you have with RPM packages anyway. The way people often get around this is to make the new, incompatible version install with a different name, eg 'bash2'. (Or maybe rename the old version, as in 'bash1'.) I expect that this also happens when Java libraries get incompatible new versions, eg: com.snakeoil.palisade4_2_1.Whatever com.snakeoil.palisade5_3_0.Whatever Really you have to say that it's up to the library author. However if users do want finer control over what .jar files get searched first they can always edit their CLASSPATH themselves. I think that most likely they would just add the necessary .jar files to the front. And what about a *big* CLASSPATH if you have installed dozens of java packages? Not a problem - if you've installed dozens you presumably want to use them all. Considering the general speed of Java, I don't think the small extra startup time would be significant :-) Again, if you do want fine control over this, you could set CLASSPATH by hand. But the default setup should be that you can install some libraries and
Re: [Cooker] Packaging Java class libraries
In Sun, 8 Jul 2001, Edward Avis cum veritate scripsit : [...] for i in /usr/share/java/*; do export CLASSPATH=$CLASSPATH:$i done But... maybe there will be (with a /huge/ growing number of jars etc.) some broken dependencies or conflicts due to the wrong sequence of jars in CLASSPATH. Mostly this will not happen due to Java's package rules. A library from one vendor will have classes called com.snakeoil.palisade.Whatever and another vendor will use com.gerbil-gratings.simphoni.Whatever so they can't clash. This even happens for different libraries implementing the same spec, such as XML DOM. You set a string in your source code to decide whose implementation to use. Actually they WILL clash! But maybe only for work-in-progress code. But as a developer I have exactly *these* pbs... ;-( But that's another story and it surely won't happen to the guy who just substitutes windoze with Linux Mandrake on his home peecee... [...] old version, as in 'bash1'.) I expect that this also happens when Java libraries get incompatible new versions, eg: com.snakeoil.palisade4_2_1.Whatever com.snakeoil.palisade5_3_0.Whatever Ahrrrg! Really you have to say that it's up to the library author. However if users do want finer control over what .jar files get searched first they can always edit their CLASSPATH themselves. I think that most likely they would just add the necessary .jar files to the front. And the guy with his shiny new Linux? And what about a *big* CLASSPATH if you have installed dozens of java packages? Not a problem - if you've installed dozens you presumably want to use I know but that's not... er... NICE! :-) them all. Considering the general speed of Java, I don't think the small extra startup time would be significant :-) The guy must buy an GHz-Athlon. ;-) [...] -- Sending unsolicited commercial email to this address may be a violation of the Washington State Consumer Protection Act, chapter 19.86 RCW. Frank Meurer [EMAIL PROTECTED], PGP ID: 0x5E756DA8 Key fingerprint = 169A 1138 8DB4 528F 2F01 20A6 EDD8 49C3 5E75 6DA8
Re: [Cooker] Packaging Java class libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, Frank Meurer wrote: [Java] A library from one vendor will have classes called com.snakeoil.palisade.Whatever and another vendor will use com.gerbil-gratings.simphoni.Whatever so they can't clash. Actually they WILL clash! Huh? import com.snakeoil.palisade.*; or import com.gerbil-gratings.simphoni.*; There's no problem unless you mix the two. com.snakeoil.palisade4_2_1.Whatever com.snakeoil.palisade5_3_0.Whatever Ahrrrg! It is a bit horrid, I agree. I don't know whether Java library vendors are actually doing this. It is clear to me that you cannot have two different versions of the same Java class installed system-wide. Not unless they use different names as above. This is exactly analogous to RPM packages where you can't have both sed-3.02 and sed-3.03. If you want two versions of something, one of them has to be renamed, as Mandrake and others have done with XFree86, Qt, bash and lots of other stuff. So the problem of having clashing versions of the same class would simply not arise. Rpm would uninstall the old version when installing the new. If you deliberately want to keep using an older version for some things, and a newer version for others, probably the best strategy is to have one installed system-wide, one in your home directory, and change the CLASSPATH as needed. This is the same as what you'd do with .so files, C header files, Perl modules or whatever. - -- 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 iD8DBQE7SH1gIMp73jhGogoRAj78AJ92xGg6ztjrWIUefaz0iU2pjF+/jQCfQL/k Fo6pfFcbZqUzBDNbb5jxH3I= =qFCn -END PGP SIGNATURE-
Re: [Cooker] Packaging Java class libraries
Edward Avis wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What is the convention for RPMs of compiled Java libraries? Snip Would this solve the problem with Konqueror and Java issues? Or has it been solved w/o me finding out? -michael- -- Science is built up with facts, as a house is with stones. But a collection of facts is no more a science than a heap of stones is a house. La Science et l'hypothèse. Henri Poincaré
Re: [Cooker] Packaging Java class libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jul 2001, michael wrote: What is the convention for RPMs of compiled Java libraries? Would this solve the problem with Konqueror and Java issues? Probably not. We're discussing adding new libraries of Java code to the system, and where to put them. - -- 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 iD8DBQE7SKqJIMp73jhGogoRAlCQAJ9BVYpFO9dvFmgQFOloBYSS81Uo8QCeKKHH i2znkX790cOVygy3Ze3MTs8= =599q -END PGP SIGNATURE-
Re: [Cooker] Packaging Java class libraries
On Sun, 8 Jul 2001, Edward Avis wrote: If not, I propose that Java libraries be installed under /usr/share/java/, either as .jar files or as subdirectories full of .class files. And /etc/profile.d/java should do something like: for i in /usr/share/java/*; do export CLASSPATH=$CLASSPATH:$i done This is how we do it (we being me and someone else, the only two on this list that seemed really interested in Java). Mandrake, as a company, doesn't seem to care much. They do not offer the JDK (or are maybe prohibited by law). Still, if Sun won't let you I'm sure IBM would love too seeing as they say they are pro-Linux these days. I had heard they were going to distribute Sun JDK only on the commercial CD, but they still do not seem to have an official stance on Java support. There are no java rpms in Cooker. for example. Problem is, in X the ~/.bash_profile doesn't seem to be read, and /etc/profile is over-written by msec all the time, so I can't figure out a good way to get these into the path except a single script in /etc/profile.d would probably do the trick. And you'd probably want for i in *.jar instead of * incase there are some directories or properties files or something else in that directory, -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Packaging Java class libraries
On Sun, 8 Jul 2001, David Walluck wrote: On Sun, 8 Jul 2001, Edward Avis wrote: If not, I propose that Java libraries be installed under /usr/share/java/, either as .jar files or as subdirectories full of .class files. And /etc/profile.d/java should do something like: for i in /usr/share/java/*; do export CLASSPATH=$CLASSPATH:$i done This is how we do it (we being me and someone else, the only two on this list that seemed really interested in Java). Mandrake, as a company, doesn't seem to care much. They do not offer the JDK (or are maybe prohibited by law). Still, if Sun won't let you I'm sure IBM would love too seeing as they say they are pro-Linux these days. I had heard they were going to distribute Sun JDK only on the commercial CD, but they still do not seem to have an official stance on Java support. There are no java rpms in Cooker. for example. Problem is, in X the ~/.bash_profile doesn't seem to be read, and /etc/profile is over-written by msec all the time, so I can't figure out a good way to get these into the path except a single script in /etc/profile.d would probably do the trick. And you'd probably want for i in *.jar instead of * incase there are some directories or properties files or something else in that directory, Precedence set by Kaffe pkg, which is atleast in theory compliant with the standard. /usr/java should be broke apart into /usr/lib, /usr/bin, and /usr/share/name. Global libs (for lack of knowledge?) would get installed into the generic CLASSPATH (/usr/share/kaffe\jre\jdk\java/lib), where as application specific would create thier own dir under /usr/share/prog\pkg and use a wrapper to alter the CLASSPATH. This doesn't mean a socalled global HAS tobe put into the global path, they could all be stuffed into /usr/share/prog\pkg to allow for version mixing.. About rpm. There is nothing in rpm that would disallow useing two or more concurrent versions of a package. The problem here is the .rpm's just aren't designed for this, which is obvious when you rpm -i and get file conflicts. The way around this is useing a Nomad(tm?) approach. Useing update-alternatives(?) to reset links as needed on an app by app basis. -- --Axalon
Re: [Cooker] Packaging Java class libraries
In Sun, 8 Jul 2001, David Walluck cum veritate scripsit : On Sun, 8 Jul 2001, Edward Avis wrote: [...] do not seem to have an official stance on Java support. There are no java rpms in Cooker. for example. IMHO the licenses of the Blackdown port should allow to integrate it. Problem is, in X the ~/.bash_profile doesn't seem to be read, and I use qvwm as WM and all xterm entries (actually it's rxvt) are called with -ls to start a login shell. But .bashrc is always read (unless you specify --norc or another rc file with --rcfile on invokation of bash). /etc/profile is over-written by msec all the time, so I can't figure out a Ahrrg! So many fixes I've put in this dirty stuff! And I've given up to send the bugfixes to Mandrake because none of them was fixed in the next version. (NFS, rights, uid's - I don't remember exactly.) You'll have to put up the fight with msec! ;-) good way to get these into the path except a single script in /etc/profile.d would probably do the trick. And you'd probably want for i in *.jar instead of * incase there are some directories or properties files or something else in that directory, What about subdirs e.g. 'find * -type f -name *.jar'? Frank PS: Nice emailaddress @anti-microsoft.org! -- Sending unsolicited commercial email to this address may be a violation of the Washington State Consumer Protection Act, chapter 19.86 RCW. Frank Meurer [EMAIL PROTECTED], PGP ID: 0x5E756DA8 Key fingerprint = 169A 1138 8DB4 528F 2F01 20A6 EDD8 49C3 5E75 6DA8
Re: [Cooker] Packaging Java class libraries
On Sun, 8 Jul 2001, Axalon wrote: Precedence set by Kaffe pkg, which is atleast in theory compliant with the standard. /usr/java should be broke apart into /usr/lib, /usr/bin, and /usr/share/name. Global libs (for lack of knowledge?) would get installed into the generic CLASSPATH (/usr/share/kaffe\jre\jdk\java/lib), where as application specific would create thier own dir under /usr/share/prog\pkg and use a wrapper to alter the CLASSPATH. This doesn't mean a socalled global HAS tobe put into the global path, they could all be stuffed into /usr/share/prog\pkg to allow for version mixing.. Are you familiar with java packages? There is really no such concept as this, especially when .jar's are single files. -- Sincerely, David Walluck [EMAIL PROTECTED]
Re: [Cooker] Packaging Java class libraries
In Sun, 8 Jul 2001, Edward Avis cum veritate scripsit : Actually they WILL clash! Huh? Yeah! ;-) import com.snakeoil.palisade.*; or import com.gerbil-gratings.simphoni.*; There's no problem unless you mix the two. Example: My Program uses LIBOLD (com.firm.lib) and I also use programs which need LIBNEW (also com.firm.lib). CLASSPATH is LIBNEW:LIBOLD:other. My other programs will run but not my own program. As an actual example at least JMF with its changes but same namespace will cause such pbs. (just for information for other readers who doesn't know much about the practical use of this nice language called Java... ;-) ) [...] If you deliberately want to keep using an older version for some things, Actually there are cases where I *must* keep old versions (i.e. for customers) and new versions (i.e. for research) both in use. and a newer version for others, probably the best strategy is to have one installed system-wide, one in your home directory, and change the CLASSPATH as needed. This is the same as what you'd do with .so files, C header files, Perl modules or whatever. That's what I do all the time (supported by different targets in makefiles etc.). But that's should not happen to the guy with his shiny new linux... ;-( Frank -- Sending unsolicited commercial email to this address may be a violation of the Washington State Consumer Protection Act, chapter 19.86 RCW. Frank Meurer [EMAIL PROTECTED], PGP ID: 0x5E756DA8 Key fingerprint = 169A 1138 8DB4 528F 2F01 20A6 EDD8 49C3 5E75 6DA8
