mojavelinux.com: Open Source Advocacy

It's all about the packages

October 27, 2008

I just finished migrating my files to a Red Hat Enterprise Linux (RHEL) 5 installation after more than three years of using Ubuntu (Hoary → Breezy → Dapper → Feisty → Gutsy) exclusively. Trust that by no means I am not parting ways with Ubuntu. It's just that when I came on board with Red Hat / JBoss, the HelpDesk team put notable effort into setting up my "corporate standard build" with all the cryptohome, VPN, and backup goodness ready to go. I felt that in return I could give RHEL 5 a concerted effort. Besides, it's good research to understand the product offering that Red Hat sticks out there. I have also been having a lot of difficulty lately with the stability and performance of my Linux desktop (partly Ubuntu, partly my fault) and I needed a reliable installation so that I can maximize my productivity. Since both Red Hat and Ubuntu standardize on Gnome, there isn't that much of a change to the desktop experience. Where things diverge is in the administrative tasks. The topic I want to focus on in this entry is package management.

When I think back to my experiences using Red Hat, Fedora, and Mandrake, what I remember most is installing RPMs. And it was more than just installing them. It was locating them, locating their dependencies, resolving conflicts, and rebuilding them when all else failed. Then there was this general discomfort over whether I choose the right RPM from the right repository and whether it would jeopardize my ability to upgrade down the road. I would say that RPM management took up 80% of my time using the distribution until I really got settled in. If I needed to change anything, that 80% tax would have to be incurred again.

When I switched to Ubuntu, I completely forgot about the whole package management nightmare. The reason is that Ubuntu's package management is completely centralized. You don't have to go digging through third-party RPM providers (DAG/rpmforge, PLF and rpm.pbone.net come to mind) to find that magic stack of RPMs you are interested in. Instead, there is just central, universe, and multiverse. The names are indicatory because they are all-encompassing repositories. It's very rare that you fire up synaptic (an apt frontend) and search for a package with no results. If it exists and can be compiled by someone, it is likely in one of the Ubuntu repositories. The multiverse repository is especially important because it has the packages we really want: the good, bad, and ugly gstreamer plugins and mplayer and its slew of codecs. In contrast, when you fire up YumEx (a yum frontend) you cross your fingers hoping that the search turns up a package.

To me, the state of package management is the deciding difference between the two distributions, so significant in fact that it's enough to say that Ubuntu is far more enjoyable to use. Only because of my long nights spent wrestling with yum and RPM repositories can I make RHEL 5 work for me.

But hold the ranting. As evidenced by the recent announcement about the Extra Packages for Enterprise Linux (EPEL) project, Red Hat is not blind to the issue. "EPEL is a volunteer-based community effort from the Fedora project to create a repository of high-quality add-on packages that complement the Fedora-based Red Hat Enterprise Linux (RHEL) and its compatible spinoffs." There is hope after all! Or is there?

While I applaud the the effort to mimic the centralized universe repository in Ubuntu, it comes up short because:

1. it's not as universal as Ubuntu's repository
2. it's not complimented by a multiverse equivalent

Even with EPEL activated in yum, you still have to keep your fingers crossed that the package you are searching for will show up in the results. And because of Red Hat's ethical stance to keep a vacuum between Red Hat distributions and "ugly" packages (non-free packages or packages with license problems), you still have to look elsewhere. Unfortunately, EPEL isn't yet entirely compatible with DAG/rpmforge, which you absolutely must use to get all your not-so-legal-yet-necessary packages. Thus, memories of RPM conflicts and missing dependencies once again keeps you up at night.

Ubuntu is definitely leading in the category of package management. But I think that Red Hat / Fedora only needs to make a small shift to even the playing field. The EPEL needs to grow to be more comprehensive to match the universe repository and it needs to be compatible with DAG/rpmforge, which would become the unofficial multiverse-equivalent for RHEL. Then, finally, the package management nightmare will be over. Oh, and it would be nice if RHEL had some checkboxes to get this all setup rather than making the user to the legwork of getting the repositories setup.

Update: In fairness, I have not tried Fedora 9 or 10 yet, so the package management situation may very well be improved. The focus of this entry was on the most recent RHEL, which is Red Hat's supported option. Regardless, my point stands: package management should be seamless, and it should include the packages the average Joe really needs (i.e., multiverse).

Posted at 07:17 PM in Linux, Open Source, Usability | Permalink | What, no comments?

A new chapter begins

October 22, 2008

Posted at 02:01 AM in Personal | Permalink | Comments (7)

Seam in Action at JavaRanch: Round 2

October 07, 2008

Now that Seam in Action is finally complete, I'm back for some more Q&A on the JavaRanch forums. This is your opportunity to challenge the author on some tough (or not so tough) Seam questions and win a signed copy of the book. The participation last time was great and we just about emptied the water cooler discussing Seam-related topics.

The giveaway starts on Tuesday, October 7th 2008.
The drawing will be held on Friday, October 10th 2008.

See you at the ranch! And thanks for those that wished me luck on finishing the book during the last promotion. It must have done the trick, because I had the book out only a couple of weeks later.

Posted at 01:37 PM in Seam in Action | Permalink | Comments (2)

My wishlist for GlassFish

October 06, 2008

I received a response to my post about how to deploy a seam-gen project to GlassFish from the GlassFish Group Project Manager, John Clingan. He asked me to provide feedback on how to improve GlassFish. I drafted a message to him with several items, which I want to share publicly.

My first long standing wish has already been addressed by a recent announcement. In GlassFish V3, session data is now retained across a restart. It has always been an Achilles heel of Java EE that redeployments are disruptive to manual testing (let's face it, that's how most developers work). Hot deployment was a step forward, but ultimately preserving session data is what makes the deployment truly smooth. Good job and keep working on ways to make a redeployment or partial deployment transparent to the developer's process.

Here are my other "bones" I have with GlassFish:

1. The JNDI MailSession in GlassFish does not support authentication over SMTP. In my opinion, this is a huge let down. With Gmail, and other providers, allowing their mail server to be used for free, it's the absolute easiest way for Java EE developers to setup JavaMail. GlassFish is all about easy, but alas, this task is not so since there is no support for authentication over SMTP.
2. It's not possible to establish a database connection in the console that uses an empty password. While it may appear silly at first, know that embedded databases such a HSQLDB work out of the box with the username "sa" and a blank password, so it just causes an inconvenience.
3. Developers have responded to my last post about GlassFish complaining that they cannot get the exploded EAR seam-gen project to work. There are two parts to this. First, perhaps there are some limitations with the exploded EAR in GlassFish. Second, I think it would go a long way for GlassFish developers to work with Seam developers to document how to customize a seam-gen application to deploy under GlassFish.
4. asadmin is a great tool, but one of the things it lacks is a set of built-in Ant tasks that a developer can incorporate into their build. You may notice from the wiki page that I have to create an Ant macro that calls out to asadmin from the commandline. I think it would be worthwhile to make <asadmin> a bonafide target in Ant. Any other build tool you want to target would also be helpful, but at the end of the day, Ant is king.
5. A fairly common task when you settle into an application server is to bring your own JPA provider. In fact, it's extremely common for newcomers to GlassFish to want to use Hibernate, specifically. But to use Hibernate requires customization since GlassFish uses TopLink Essentials (i.e., EclipseLink) as the default JPA provider. I'm not going to make the argument here that one is better than the other, but rather focus on the task of swapping between them. I feel that the administration console should provide a way to register a new provider and perhaps even know how to get the JARs (or perhaps you have to upload them as a zip file). Either way, you should not have to go into your GlassFish installation and start replacing JAR files because it's tedious and error prone.
6. It would be nice to have a JDBC driver manager. This is another JAR I have to manually copy into glassfish/domains/$domain/lib/ext. Plus, I would get a dropdown of Driver implementations when creating a new JDBC connection pool.

By no means is this a comprehensive list, but just happens to be what has been on my mind lately. If I think of other ideas, I will likely follow up with another post. However, what I am really interested in is if you have suggestions for John and the GlassFish team. Feel free to post them in the comments.

UPDATE: I forgot to mention that I was impressed by how quickly Sun picked up on my initial post and was willing to ask for input. It shows that Sun (specifically the GlassFish team) is keeping a thumb on the pulse of the community, which I feel is critical part of having a successful and useful project.

UPDATE 2: I had forgotten to add my point about managing the JPA provider

UPDATE 3: The only limitation with GlassFish deploying an exploded EAR is that all EJB modules must be exploded. That means the jboss-seam.jar must be placed into the EAR as an exploded archive.

UPDATE 4: Added point about managing JDBC drivers.

Posted at 02:08 AM in Java | Permalink | Comments (11)

An author's most proud moment

October 03, 2008

There are many "firsts" in a person's life, but as you grow older you have to start working harder to achieve them. I certainly didn't slack off leading up to the moment when I could take my book off the bookstore shelf and hold it in my hands.

Apart from experiencing this "first", I went into the bookstore to see my book because sometimes I forget that it actually exists outside of my office. Sure enough, there is was. And it was even facing out! (Honest, I did not give myself a better shelf placement).

While I am enjoying this hard-earned moment, at the same time I am starting to wonder whether I will have the energy to do it again. Having said that, you are probably wondering if I ever go on vacation. Well, here's proof that I do...occasionally.

Granted, the day after this picture was taken (July 2008) I hopped on a plane to go to Italy for the Seam and Hibernate Planning Meeting. Hey, at least my feet touched the sand!

Posted at 03:50 AM in Personal | Permalink | Comments (1)

Deploying a seam-gen project to GlassFish

October 03, 2008

seam-gen creates projects that deploy to JBoss AS out of the box. However, a Seam application can run on any Java EE application server or servlet container with the proper packaging. I have created a page on the Seam in Action wiki that provides instructions for how to modify the build script of a seam-gen WAR project to support deployment to GlassFish (in addition to JBoss AS), as I promised I would do in Seam in Action. Unfortunately, the configuration on applies to WAR projects at this time, though it's certainly possible to deploy seam-gen EAR projects to GlassFish. It's just a matter of putting the files in the right place and I haven't yet committed the time to finding the right build configuration. Keep an eye out for updates as I will likely update the instructions when I nail it down.

Before you run off to discover how to modify your build, I want to mention a couple of things about GlassFish. It's fairly well-known amongst my colleagues and readers of my book that I like GlassFish, and I have cited those reasons in the appendix of Seam in Action. But there is a specific reason that I like GlassFish as it pertains to the build configuration I set forth on the wiki page.

GlassFish has a very sexy administrative console, but it also has a very sexy commandline tool known as asadmin. The asadmin tool gives you virtually unbounded control over the application server, including core tasks such as starting and stopping the application server, deploying and undeploying applications, and setting up database connection pools, amidst a plethora of other controls. You'll see that my modified seam-gen tool takes advantage of a handful of these commands. I encourage you to execute the help command to find out what else asadmin is capable of doing.

When choosing software, there is one thing that you should demand as a developer: efficiency. GlassFish gives you efficiency through automation, which is undoubtedly the most effective way to become efficient. As soon as you have to open up a configuration file, know that you are wasting time. Manual processes are not only slow, though. They are non-reproducible. As the wise authors of The Pragmatic Programmer advise, if you have to do something twice, script it. GlassFish volunteers itself to participate in a script and is the reason why I choose it as my preferred application server.

Posted at 03:45 AM in Java | Permalink | Comments (7)