Re: Re:RPM's (was: Jakarta - A study in self defeating projects)
Hi Yoav et al, Is there good information around somewhere about how to make RPMs for Java libraries? For instance, HttpClient provides nothing by itself and should be put into the classpath of each project you need to use it with. It's not a good idea for installers to put things into the extensions directory of the JRE because it can cause conflicts, hides the fact that the jar has to be redistributed with the application and the installer likely has no idea with JVM it needs to install into anyway. The jpackage RPMs work the other way round. There is a single repository (not related to a JVM) which holds all the libraries for a system. Applications then make use of these libraries by dynamically generating a classpath containing only those libraries that the application requires. This does mean that anyone creating an RPM needs to patch any launch scripts to use the classpath generation tools, but it's the only way really. The RPMs for libraries are really just providing dependency information so that when I request an installer (apt/yum) to install an application the installer can go off and ensure that all the dependencies are satisfied before installing the main app. So given that, is it useful to have RPMs for Java libraries and if so, how should they be packaged? Very useful, I don't need to find out what version of what library is needed for what app. It's all sorted out by an installer when the RPMs are installed. The system also handles ongoing upgrades of apps as well as initial installs My personal opinion is that Java libraries should be packaged as tar.gz and .zip archives complete with documentation as well as a plain jar file if it's totally standalone (though that's not essential). I've never wanted an installer and always actively avoid them for libraries. Complete programs (eg: tomcat and maven) on the other hand I'm all for having an installer for and thus RPMs would be great. Again RPMs are really archive files with added dependency data which is then used by an installer. -- Jeff Martin Memetic Engineer http://www.custommonkey.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:RPM's (was: Jakarta - A study in self defeating projects)
On 12/10/2004, at 11:00 PM, Shapira, Yoav wrote: Hi, The folks at JPackage.org already track several Jakarta projects and issue RPMs for them: for example, they've been doing this with Tomcat for a long time. We appreciate their work. We've spoken on the tomcat-dev list about issuing our own RPMs, and I think it was Costin (Manolache) who was very interested and knowledgable in this area, so he might be a good person to ask if you're interested in more Jakarta/RPM work. Hi Yoav et al, Is there good information around somewhere about how to make RPMs for Java libraries? For instance, HttpClient provides nothing by itself and should be put into the classpath of each project you need to use it with. It's not a good idea for installers to put things into the extensions directory of the JRE because it can cause conflicts, hides the fact that the jar has to be redistributed with the application and the installer likely has no idea with JVM it needs to install into anyway. So given that, is it useful to have RPMs for Java libraries and if so, how should they be packaged? My personal opinion is that Java libraries should be packaged as tar.gz and .zip archives complete with documentation as well as a plain jar file if it's totally standalone (though that's not essential). I've never wanted an installer and always actively avoid them for libraries. Complete programs (eg: tomcat and maven) on the other hand I'm all for having an installer for and thus RPMs would be great. Yoav Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 3420 4584 0422236329 35 Prenzler St Upper Mount Gravatt 4122 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
