This post originated from an RSS feed registered with Java Buzz by Weiqi Gao. Original Post: An Introduction To JPackage.org Feed Title: Weiqi Gao's Weblog Feed URL: http://www.weiqigao.com/blog/rss.xml Feed Description: Sharing My Experience... Latest Java Buzz Posts Latest Java Buzz Posts by Weiqi Gao Latest Posts From Weiqi Gao's Weblog

You are going to hear about them now. (Go ahead and get that soda, because a long story is coming.)

JPackage.org entered my consciousness via a comment from Peter on my blog 95 days ago:

I haven't tried it yet, but JPackage seems to be what you're looking for: http://jpackage.org/

I did take a look at the website, but did not pursue it further. My impression at the time was: "Who's going to install Java stuff out of RPMs?"

Time passed.

My second encounter with JPackage came 68 days ago when I was trying to figure out why Ant can't find my classes, as I blogged here.

While perusing /opt/apache-ant-1.6.2/bin/ant, this comment jumped out at me:

# Build local classpath using just the launcher in non-rpm mode or
# use the Jpackage helper in rpm mode with basic and default jars
# specified in the ant.conf configuration. Because the launcher is
# used, libraries linked in ANT_HOME will also be include, but this
# is discouraged as it is not java-version safe. A user should
# request optional jars and their dependencies via the OPT_JAR_LIST
# variable

"Hmmm, the JPackage people have infiltrated the Apache organization! Who are these people?" thought I.

Then, 11 days ago, as I upgraded this workstation to Fedora Core 3, it jumped right at me when I executed none other than the venerable java command:

[weiqi@gao] $ javac Foo.java
libgcj-javac-placeholder.sh

This script is a placeholder for the /usr/bin/javac
master link required by jpackage.org conventions.  libgcj's
rmiregistry, rmic and jar tools are now slave symlinks to these
masters, and are managed by the alternatives(8) system.

This change was necessary because the rmiregistry, rmic and jar tools
installed by previous versions of libgcj conflicted with symlinks
installed by jpackage.org JVM packages.

"Java related stuff is a mess." I yelled at the time.

Well, what would you do if a sign appears to you on three separate occations, all within less than 90 days?

I must investigate!

First stop, the web site. It's not the most intuitive web sites. It's simple and overwhelming at the same time. The bulk, say 97%, of the front page is taken up a list of hundreds of packages, each links to a package specific page that contains links to an RPM.

But if you follow the links and download the RPM and try to install it, you'd be wrong, because there's a better way.

The secret to JPackage.org lies in the handful of links at the top left corner of the page. In my opinion, the page would be better off if it contained only those links.

According to the FAQ, the recommended way of using JPackage.org is to:

1. Configure an automatic package management tool
2. Install the packages you want

For me, a Fedora Core 3 user, this means yum. Yum is the automatic system update tool that comes with Fedora Core 1, 2 and 3. With FC3, yum configuration just got easier. What I ended up doing is to create a couple of files in /etc/yum.repo.d:

[root@gao] # pwd
/etc/yum.repos.d

[root@gao] # cat jpackage16-generic.repo
[jpackage16-generic]
name=JPackage 1.6, generic
baseurl=http://mirrors.sunsite.dk/jpackage/1.6/generic/free/
gpgcheck=1

[root@gao] # cat jpackage16-fc3.repo
[jpackage16-fc3]
name=JPackage 1.6 for Fedora Core 3
baseurl=http://mirrors.sunsite.dk/jpackage/1.6/fedora-3/free/
gpgcheck=1

and to import the GPG key of the JPackage project:

[root@gao] # rpm --import http://www.jpackage.org/jpackage.asc

Now I'm in business. I want Ant:

[root@gao] # yum install ant
blah blah blah

I want Jython:

[root@gao] # yum install jython
blah blah blah

I even want Maven (just kidding :) ):

[root@gao] # yum install maven
blah blah blah
blah blah blah
Error: missing dep: java2html for pkg maven

I hit the first sour point of JPackage.org---not everything is in the repository!. Yum is really good at fanning out into the repo to bring back all needed dependencies, but it is powerless when the dependencies are not present in the repo. They are missing from the repo because of licensing issues. Chief among them are Sun stuff: the JDK, the various JSR interfaces, etc.

Sure I can download them myself, but that wouldn't provide the dependencies needed by JPackage.org package. It wouldn't fit very well with the overall pattern of how JPackage.org does things.

What JPackage.org want me to do is this (let's take the Sun JDK for example):

1. I would download jdk-1_5_0 8 -linux-i 1ff8 586.bin from Sun
2. I would then download a nosrc.rpm, java-1.5.0-sun-1.5.0-3jpp.nosrc.rpm from JPackage.org
3. I then wave my magic wand and create the real rpm, java-1.5.0-sun-1.5.0-3jpp.i586.rpm, the rpm that would satisfy the dependency requirements of other JPackage.org packages, out of the downloaded artifacts.

This is only slightly more complicated than what I currently do:

1. I download jdk-1_5_0-linux-i586.bin
2. I expand it to /opt
3. I modify my shell initialization files to add the appropriate directory to the PATH and jar files to CLASSPATH

Mika Hirvonen has written up a very clear HOWTO on building JPackage.org compatible rpms for Sun 1.5.0 JRE. The only thing I did that was different is that I'm using JPackage 1.6 instead of 1.5, and I'm on Fedora Core 3 instead of 2.

Once you get everything setup, it takes only one step to grab the nosrc.rpm, another step to download the Sun distribution, and a third step to generate all the rpms, which can then be installed.

The bad part about this exercise is that I have to do all of these manually. Here's a list of the nosrc.rpm's that I have installed:

These packages (40 rpms total) provided dependencies for 844 rpms in JPackage.org, including JBoss 3.0, JBoss 4, Jonas, JacORB, Hessian, Tomcat, Jetty, ArgoUML, JEdit, HSQLDB, iText, JasperReports, and many many more.

What I see JPackage.org do for me as a Java developer is to allow me get access to new unfamiliar Java packages faster.

Whereas in the past I have to visit websites, download tar.gz files, build them, and mess around with environment variables to get something working, I now can get it in one command.

For example, I've only used ArgoUML once several years ago for a day. I have wanted to redownload and install it to take another look again, but haven't found the time to do it yet. Now thanks to JPackage.org, ArgoUML is installed on my system. There is even a GNOME menu entry for it.

I sincerely wish the JPackage.org people success, for what they do saves me time and effort and allows me to get into contact with much more Java libraries then I would otherwise have time to.

Now I'll dive into the 2GB+ of Java stuff and learn something new.