May 04, 2009
Ever since I first started using Maven 2, I envisioned having a console in which I could execute life-cycle goals without having to incur Maven's startup cost between every run. It just seemed to me such a waste for Maven to build up the project object model (POM) from the pom.xml only to run a single sequence of goals and immediately shutdown. It also gives the impression that Maven is slow. In fact, it's extremely slow when it's used in this way, especially multi-module projects. But it doesn't have to be if you take advantage of...
The maven-cli-plugin
Today my vision has come true thanks to Mr. Don (and the ease of collaboration made possible by git). Having a similar vision to mine, he wrote the maven-cli-plugin, hosted at github.com. This plugin uses the jline library to create an execution console for Maven 2 (i.e., command shell), shown here:
maven2>
At the prompt you can issue Maven 2 life-cycle phases or plugin goals. The console even supports tab completion of commands! In this entry, I'll explain how you setup and use this console to put Maven into hyperdrive.
Technically, the plugin has two consoles. One is for executing Maven 2 life-cycle phases, including all prerequisite phases, and the other is used to only run plugin goals (the life cycle is not executed). Those are the same two ways you use Maven 2 from your normal shell. In this entry, I'll be focusing on the execute-phase console.
A fork in the road
I was thrilled when I first discovered the plugin, but after giving it a shot I was disappointed to discover that it wasn't honoring profiles, which are a critical piece of the build (see issue 2). I didn't give up hope though. Since Mr. Don had done most of the legwork in creating the plugin, I figured it wouldn't be that difficult for me to figure out why the profiles weren't working. Sure enough, in under an hour I discovered the source of the problem and was able to apply a fix. That left me with the dilemma of how to distribute my changes. I wanted to be able to use the plugin in the Seam 3 examples, so I couldn't just maintain a hacked version on my computer. Github.com (and git) saved the day.
Following the process for creating a fork on github.com (for which they practically spoon feed you the instructions), I forked the code and committed my changes to a publicly accessible repository. You can access both the master tree and my forked tree. You'll need the version from my tree to use all the features I cover in this entry. Hopefully Mr. Don will merge my changes into the master tree soon, but the fact that you can get my code today is a true testament to the influence git can have on open source collaboration.
Now let's "git" on with the presentation.
Getting started
To get started, add a plugin repository where the maven-cli-plugin is hosted as a top level element in your pom.xml. I recommend using the JBoss maven repository because it hosts my forked version.
<pluginRepositories>
<pluginRepository>
<id>repository.jboss.org</id>
<name>JBoss Repository</name>
<url>http://repository.jboss.org/maven2</url>
</pluginRepository>
</pluginRepositories>
Alternatively, you can publish the plugin to your local or company repository. Grab the source from github.com or the binaries from the JBoss Maven repository. Remember, you need my forked version until my features get merged in. Follow the project at github.com to find out when that happens.
Next, define the maven-cli-plugin inside the build > plugins element in your POM. This just allows you to use the plugin prefix from the commandline, which is cli. You're also going to use this section to add some configuration options later.
<plugin>
<groupId>org.twdata.maven</groupId>
<artifactId>maven-cli-plugin</artifactId>
</plugin>
With the setup out of the way, I'm going to demonstrate three reasons why this plugin is game-changing. By the end, I guarantee you'll be jumping out of your chair.
#1 - Speed
Let's face it, Maven is dog-slow. That's because it has to parse that heap of XML the Maven developers call a POM. Then it has to figure out what it's supposed to execute. Then it pings the internet for updates. Then it enforces constraints. Then it runs through all the precursor phases (likely including tests). And finally it arrives at the phase you really want it to execute.
Of course, some of those steps can be trimmed using various flags, switches, and properties. But that means having to type, and remember, a ridiculously long command that is just something no human should be expected to do. More on that later. Let's deal with this startup cost once and for all.
We'll begin by firing up the maven-cli-plugin phase executor console. You run it just like you would any other Maven plugin:
mvn cli:execute-phase
After Maven goes through it's normal loading process, you are presented with a command prompt:
maven2>
From here you can type any of Maven's life-cycle phases, such as package, or a plugin goal (more on plugins later). Give it a try:
maven2> package
The first time the life cycle executes, you'll see a noticeable improvement in speed. By the second execution, it's blazing fast! You can just feel years being added back to your life. Power up!
Now it's time to extend the build with...
#2 - Profiles
One of the most powerful features of Maven is profiles. In fact, I think Maven is pretty useless without them. That's because in Maven, you really only have one "command" you can execute, the Maven 2 life cycle. There must be a way, then, to instruct that execution pass to perform different steps along the way. That's what profiles are for. With a profile, you can hook additional plugins to a phase as a way to weave that extra behavior into the build.
But we have a dilemma. Profiles are typically activated from the commandline either explicitly using the -Pprofile flag or through an activation, typically by assigning a property such as -Dproperty=value. How can we set the profile once we are in the command console? This is where my contribution to the maven-cli-plugin comes in.
The commands typed in the console are processed by the jline ConsoleReader from the maven-cli-plugin, not by Maven. That means we can allow any command we want, including flags like -P and -D. Fortunately, Maven was designed in such a way that an execution is isolated internally from parsing the POM. So it's possible to execute a life-cycle phase with a different set of profiles and properties, or even put Maven into offline mode for a single execution, without having to start the console again.
I hacked up the maven-cli-plugin to support the following flags:
- -P activates the profile specified immediately after the flag (no spaces); this flag can be used multiple times
- -D assigns a property specified immediate after the flag (no spaces) in the form name=value; this flag can be used multiple times
- -o puts Maven in offline mode for a single execution; if not specified, will inherit the setting used to start the console
- -N instructs Maven not to recurse into projects in the reactor
- -S skip tests, an alias for -Dmaven.test.skip=true
Here's an example of a command you can issue:
maven2> clean package -Prun-integration-tests -o
That would activate the run-integration-tests profile, run the clean plugin and the life cycle up to the package phase, all while executing Maven in offline mode (to avoid checks for missing pom files, snapshots, and plugin updates).
In addition, the maven-cli-plugin already supported specifying individual projects by artifactId. This allows you to execute a phase on a sub-project without having to descend into that project or use the -f flag.
Let's say you are working with an standard EAR project and you want to build the WAR. To package just the WAR, you would either have to change into the war directory and execute Maven or use the -f flag as follows:
mvn -f war/pom.xml package
With the maven-cli-plugin, you can accomplish the same thing using this command (note that "seam-booking-war" is the artifactId of the module):
maven2> seam-booking-war package
Ah, the simplicity! And now, for the grand finale!
#3 - Aliases
Aliases are the Holy Grail of Maven 2. When I switch people from Ant to Maven, the first thing they get annoyed about is the ridiculous commands they are required to type. To put it simply, if you want to run clean and package, there is no way to specify that with a single command. You have to type:
mvn clean package
Things get worse with plugins. All plugin goals must be namespaced. That's because Maven 2 technically supports any command in the world, as long as there is a plugin to execute it. To run Jetty on a WAR project, for instance, you have to type:
mvn run:jetty
If you want to run clean, package, and then start jetty, you have to type:
mvn clean package run:jetty
Let's say that you also need to expand the WAR in-place and you want to run offline. Then the command becomes:
mvn -o clean package war:inplace run:jetty
I think you can see where this is going. When I first setup the booking examples for Seam 3, the record for the longest commandline in the readme went to this command, which undeploys, packages, and redeploys an EAR to JBoss AS:
mvn -o -f ear/pom.xml jboss:undeploy && \
mvn -o package && \
mvn -o -f ear/pom.xml jboss:deploy
Uuuuugly! That's why the aliases feature of the maven-cli-plugin is absolutely game-changing (perhaps even life changing). In fact, combined with the other two features I have covered, they make Maven 2 better and faster than Ant, hands down. I'll go so far as to say that there has never been a faster, more convenient way to execute builds.
So what is an alias? Quite simply, a string of commands you would otherwise have to type in the console, aliased to a single word. You define them in the plugin configuration. Here's an alias I put together to deploy an exploded EAR archive to JBoss AS in the Seam booking example:
<plugin>
<groupId>org.twdata.maven</groupId>
<artifactId>maven-cli-plugin</artifactId>
<configuration>
<userAliases>
<explode>package -o -Pexplode</explode>
</userAliases>
</configuration>
</plugin>
After starting up the console, the user only has to type one word:
maven2> explode
It's no longer even necessary to prefix commands with mvn (or ant in the old days). Just one command. One word.
The execute-phase console also supports direct execution of plugin goals. That means you can include them in the alias command. The only limitation is that when you include one in an alias, you have to specify the fully qualified name of the plugin (groupId:artifactId) before the goal rather than just it's prefix (e.g., org.codehaus.mojo:jboss-maven-plugin rather than jboss). This next alias invokes the harddeploy goal of the jboss-maven-plugin after packing the project.
<userAliases>
<deploy>seam-booking-ear package -o org.codehaus.mojo:jboss-maven-plugin:harddeploy</deploy>
</userAliases>
You can even mix aliases with regular commands. Perhaps you want to clean first:
maven2> clean deploy
I find it nice to alias commonly used built-in Maven goals too, such as the one that lists the active profiles:
<userAliases>
<profiles>org.apache.maven.plugins:maven-help-plugin:active-profiles -o</profiles>
</userAliases>
The maven-cli-plugin also provides a handful of built-in aliases.
If this plugin isn't game changing, I don't know what is. All I can say as hell yeah!
See the Seam 3 booking example to see this plugin in action and read additional commentary.
Update: There is also a cli client for IntelliJ IDEA that can invoke builds remotely. Of course, the plugin supports this from the commandline too.
Update: I should also mention that this is a great way to debug Maven since you get an opportunity to attach a debugger before executing a command. First, set the MAVEN_OPTS environment variable:
MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
Then run cli:execute-phase, attach a debugger (port 8787 in this case) and execute a command.
Posted at 02:18 PM in Java, Programming, Usability | 
Permalink
| 
Comments (30)
April 02, 2009
What a year! There's no question that year 30 was the most eventful and life changing year of my life to this point. I truly feel like I have grabbed life by the horns and got it steered in the direction I really want it to head.
By far, the biggest accomplishment of the year was getting Seam in Action published. But writing my first book was the catalyst for many of the other events that took place. From start to finish of year 30, I presented for the first time at a software conference, which led to a half a dozen speaking engagements, more travel than I've ever done in one year, including my first ever trip to Europe, and the chance to meet a lot of prominent industry leaders. Writing the book also helped me be more prolific. I passed my 100th blog entry and posted 1000 tweets on Twitter, which I began using just before JavaOne. The gutsiest and most permanent decision I made all year was deciding to get LASIK, and in the words of Tiger Woods, "the results were fantastic". What follows is an account of this passage into my 30 somethings, most of which can be found in my tweet archive.
Read More...
Posted at 10:27 AM in Personal, Seam in Action | Permalink
|
Comments (3)
March 17, 2009
I didn't expect Ken Rimple for Chariot Solutions to be so quick in getting up part 2 of my Seam interview, which I introduced in a previous entry, so you get two posts in one day. If you had iTunes or your RSS feed reader working, you'd already be in the know.
In the second part of this two-part interview, we focus on the future of Java EE 6, including JSR-299, formerly known as Web Beans, and how Seam will change as the Java EE specification evolves. We also discuss varying front-end technologies such as Flex and AJAX, and a bit about workflow.
Resources we mentioned in the talk include:
- Granite DS - A Flex remoting framework that includes support for Seam as well as other platforms such as Guice, Spring and POJOs
- Flamingo - Another Flex (and JavaFX) remoting framework that exposes Seam and Spring services using a variety of protocols including AMF and Hessian.
- JSR-299. I emphasize that it is well worth your while to read it and something I think every Java EE developer needs to be aware of at some point in the near future.
- Web Beans - The namesake of the reference implementation (RI), which is being developed by Red Hat and its community as an open source project.
Thanks again to Ken for the hard work that I know went into publishing this interview.
Posted at 11:22 AM in Java, Seam, Seam News | Permalink
|
Comments (1)
March 17, 2009
I'll be speaking at two conferences back-to-back in March, which is about as much madness as I can handle. First I'll be traveling to Vegas to speak at TheServerSide Symposium at Caesar's Palace on my birthday (March 20th). It's interesting to note that just over 6 months ago I was near Caesar's real palace, or what's left of it. Then I'll be coming back home and speaking at Emerging Technologies for the Enterprise in nearby Philadelphia the following Friday. In both cities, I'll be speaking about Seam Security.
Always wanting to put on a good show (I mean, it is Vegas after all) I put together a fresh application that leverages Seam's new identity and permissions management API. It's a design comp manager that allows a designer to share designs with clients. The application showcases how Seam Security blends ACLs and rules in a truly unique and revolutionary way to provide a powerful and expressive security model.
While creating an application like that may sound difficult to achieve, my talk demonstrates that it's shockingly simple setup and start using. Like poker, though, it does take time to perfect. Authoring complex rules are not always easy. I spent nearly two days getting a feel for the API. But then again, I've got a killer app to show for my labor.
The full abstract of the talk is below.
Security is the cornerstone of your application's integrity and, consequently, you need to weave it throughout each layer, often in diverse ways. Seam Security allows you to evolve the security model of your application over time, keeping pace with the development cycle. You can start with a very simple configuration that applies an exclusive security blanket over the application to keep out guests and establish a basic identity for the user. You can then mature the security infrastructure gradually by adopting Seam's declarative approach to authentication or defining fine-grained authorization rules that enforce contextual restrictions at the level of database records, database fields, object fields and UI fragments.
Seam's security module, a central aspect of the Seam framework, offers a significantly simpler alternative to JAAS - the monolithic and cumbersome security model in Java EE. The talk begins with some definitions to sort out what we mean when we say "security". The talk then switches to a tutorial style, showing you first how to get your foot in the door by setting up a JSF form-based authentication routine in Seam using either a custom authentication method or a declarative approach where the authentication is handled by the framework. You are then presented with the numerous authorization styles that Seam supports ranging from binary, role-based, rule-based (Drools), and ACLs. Examples are presented to help you differentiate the four styles of authorization and when it is appropriate to use each one. In the process, you learn to appreciate that Seam's authorization is able to take the context (the target) of the restriction into account, a feature than many security frameworks overlook. Finally, the talk zooms out to show how to bring authentication under one roof using Seam's Open ID module.
See you at the tables...er, I mean conferences!
Posted at 05:26 AM in Java, Seam | Permalink
|
Comments (1)
March 17, 2009
Ken Rimple from Chariot Solutions connected with me over Skype to discuss Seam (which in truth turned out to be a series of long monologues by me about Seam and web application development).
In this first part of a two-part interview, I introduce the Seam framework and how it represents departure from both J2EE of old and Spring. We discuss ways in which it marries JSF to POJOs and EJB components, provides a stateful view of the world and makes programming easier for APIs such as Java Persistence. The most intriguing point you'll learn from this first part is how Seam appealed to me as an application developer working out in the field, a testament to the fact that Seam is first and foremost a practical solution.
There are three ways you can track down the podcast:
- Search iTunes for Chariot TechCast (Look ma, I'm on iTunes!)
- Subscribe to the RSS feed
- Cheat and get the MP3 using a direct download
This Tech Cast promotes the upcoming Emerging Technologies for the Enterprise conference in Philadelphia, PA hosted by Chariot Solution, at which I will be speaking about Seam Security.
This entry is the 100th post I have made on this blog. Add that to the list of major milestones I've hit while being 30.
Posted at 02:52 AM in Java, Seam, Seam News, Seam in Action | Permalink
|
Comments (1)
March 17, 2009
I'm speaking again this year at the Emerging Technologies for the Enterprise conference in Philadelphia, PA hosted by Chariot Solutions. It's one of few enterprise development conferences held on the East Coast that attracts high caliber speakers (and lots of framework passion) with such a remarkably low price tag (which is music to our savings accounts these days). Last year I gave an introductory to Seam talk. This year, I'll be presenting on Seam Security, highlighting its ease of use and showcasing the new identity and permission management API that was added in Seam 2.
I got involved with the conference last year through Manning, who, as event sponsor, was rounding up a bunch of its authors to speak so that they could take part the Web Framework Shootout panel. If you missed it, the audio from that panel discussion is available online, divided into two Chariot TechCast episodes (part 1, part 2). It's worth checking out because there certainly was a lot of shooting...off at the mouth, that is.
You can listen to the whole discussion to get the context. But I've distilled my responses for you into three short segments. I realize this post is long overdue, but since it retains more than just historical value, I've decided to move forward with publishing it.
- Segment #1: (01:10) I define what exactly Seam is in response to Marjan's poignant question about it
- Segment #2: (02:35) I introduce myself and give a broad overview of what Seam provides
- Segment #3: (01:30) I identify the business value in adopting Seam and contrast that with how little Struts 1 provides
The shootout was supposed to be about Web Frameworks, but the debate ended up playing out on two separate playing fields. The first debate was about Ruby vs the World, which got quite heated at times thanks to Obie and someone denouncing Twitter's ability to scale (which it mistakes for a fail whale). The second debate was about RIA built on JavaScript vs the more traditional server-side UI component model.
As you'll hear, I abstained from making incendiary comments and instead tried to emphasize the value Seam provides and how it really allows you to forget about much of this debate. First, because it makes the Java EE platform attractive and accessible and second, because it can plug into a wide variety of other UI frameworks, whether it be GWT, Wicket, Flex, or JSF and non-web frameworks, like JMS, Quartz, and jBPM.
Keep in mind that these excerpts are nearly a year old at the time of this post. However, it's interesting to hear what I had to say about Seam at the halfway point of writing Seam in Action. Seam's message hasn't changed all that much since then, even though the number and quality of the integrations has improved substantially. I wouldn't be surprised if I look back in a year and have the very same thing to say. Seam is all about trimming the fat (i.e., framework code) resident in the application so that what is left is core business logic. Some of the business logic may even get wrapped up in Seam's declarative programming model.
Posted at 02:25 AM in Java, Seam, Seam News, Seam in Action | Permalink
|
What, no comments?
January 21, 2009
As were many, I was moved by the passion of Inauguration Day 2009 in Washington. But one phrase, in particular, from President Obama's speech resonated especially strong with me because I feel it captured the principle of which a majority of us believe in as open source developers and supporters (substitute public dollars with community-developed software):
And those of us who manage the public's dollars will ... do our business in the light of day - because only then can we restore the vital trust between a people and their government."
The words that are not said, but somehow implied, is that by being open, you mobilized an enormous workforce to assist, guide, and support your effort, thus making your cause even stronger.
One can't help but to wonder what government would be like if it were run on mailing lists, IRC chats, and web forums instead of behind closed doors. Time will tell whether Obama will steer the US government in that direction, or perhaps a more suitable variant. There's no doubting his intent that he is going to try. In fact, the first post on the new whitehouse.gov blog states this goal quite candidly.
Posted at 03:15 AM in Open Source | Permalink
|
Comments (3)
January 05, 2009
It's a New Year and that means it's time for an announcement. I left a very cryptic blog posting about this news when it happened, so I've decided to post again and this time be more direct. Just before the turn of November last year (all of two months ago) I joined JBoss, a division of Red Hat, as a member of the Seam development team. I really wasn't planning on working for JBoss, even after I finished the book, because I was so focused on not being biased about Seam. But when I stopped to think about it, I realized that Red Hat champions the very same platform as I do: Linux, Java, and Open Source. Thus, I could do more with their support and vice versa.
Orientation week was a fascinating experience for me because, for the first time, I was in an office building where I wasn't the only one (or one of few) championing the open source model. I guess I will have to up my ante on being a rogue ;) And yes, you do actually get a Red Hat when you join the company. Previously, I thought it was just a joke.
In the spirit of open source, here's the letter I opened with when I joined the company:
Ever since programming blackjack and poker on the TI-85 calculator with his fellow classmates, Dan has believed in open, collaborative software development. But his introduction to Linux came four years later when his father, a market regulator executive, enlightened him with the recent success story behind the ticker "RHAT" and the promise its company made to change the computing industry forever. (Sadly, neither of them thought to purchase shares of stock at the IPO).
Fast forward a couple of months to the moment Dan became a Linux believer--at 3 AM in the morning waking his girlfriend (and future wife) to exclaim he had connected Linux to the internet through his cable modem (long before NetworkManager was around). Not once has he looked back, now proud of his 8 years of running Linux as his one-and-only operating system. As a result of a household mandate, his wife is now a 7 year Linux veteran as well.
Dan has spent his entire career working in enterprise software development, beginning as a junior PHP developer and eventually graduating to a senior Java EE developer, architect, visionary, and author of Seam in Action. Throughout that time, Linux has remained a hobby (some may even say crusade) of Dan's. But he was optimistic that someday his path would cross with Red Hat on a professional level. Today, he's proud to say it has. The first step was the joining of Red Hat and JBoss, which established a bridge in the industry between Dan's personal development stack, Java and Linux. The second was Dan's decision to dive deep into JBoss' middleware framework, Seam, which he accomplished by writing a book on the topic and dually becoming a member of the project. Dan quickly came to appreciate the high quality of software projects at JBoss and was honored to be offered a place on the team.
Dan hasn't done much other than focus on the book in the last year, but he looks forward to getting back to his non-tech hobbies, which include watching NFL football (Redskins), playing golf, snowboarding, traveling, and turning his house into an art project.
Vivre open source!
Posted at 04:29 PM in Personal, Programming | Permalink
|
Comments (5)
November 24, 2008
I'm a bit late on delivering this news, but as of two weeks ago, the two bonus chapters from Seam in Action (chapter 14 and chapter 15) have been published on the Seam in Action website after being polished, typeset, distilled to PDF. The chapters have been available online as Word documents since the release of the book, but have since been improved quite significantly, so I encourage you to scan through them even if you have already done so.
Chapter 14 covers Seam's business process integration (jBPM), starting off with a very gentle introduction to business processes that will be sure to get you excited about trying out a business process in your application. Seam's integration with Spring is covered inside and out in chapter 15, giving you a plethora of ideas on how to leverage the two frameworks together.
The best part is, the chapters are free! That means there are now four free chapters available! (1, 7, 14, 15) And those are complete chapters, not excerpts of a chapter with vital pages missing. There are two reasons for this. First, I really want you to get the information you need to use Seam effectively. It's also because I want you to appreciate how in-depth I went with this book so that you are confident in your decision to go "all in" and purchase it (Manning.com, Amazon.com). And please, after you read the book, consider posting a review on Amazon to share with others what you thought of it.
Posted at 11:16 AM in Java, Seam, Seam in Action | Permalink
|
What, no comments?
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:
- it's not as universal as Ubuntu's repository
- 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?
