It’s been a good few weeks for stories and information about JBoss Rules and Drools, the open source project upstream of the JBoss subscription offering. Here is a quick summary of the recent stories. Post a comment if you know of any others we all should pay attention to.
“How do I get our software in to Fedora?”
This question has been a common one over the last year, brought to various parts of Fedora and Red Hat from software developers, community managers, and product teams working on open source software for various ISVs. Now that OpenJDK 6 is Java EESE 6 TCK certified, there is an even greater incentive for Java ISVs to get closer to the Fedora way of doing things. If your language has a free and open source implementation, it is probably in Fedora and might already be available in Extra Packages for Enterprise Linux (EPEL.) For example, take a look at how many Perl modules are available (I count 359 for el5, 236 for el4.)
Fedora anticipated this attention from ISVs when it created the EPEL project. In EPEL, package maintainers can branch any software and it’s dependencies for a special repository that provides Fedora packages for specific versions of Red Hat Enterprise Linux.
In one move, Fedora created a new and unique repository that has a compelling pathway for contributions. Fedora’s EPEL has a niche amongst repositories — be like Enterprise Linux. Focus on security updates and bug fixes to packages, not rebasing to the latest from the upstream project. This makes it possible for a contributor community to maintain nearly 1500 EPEL packages for Red Hat Enterprise Linux 4 and nearly 3000 EPEL packages for Enterprise Linux 5. Some of these packages may get branched for an Enterprise Linux update.
The answer to the how do I? question comes to this:
Along the way, you have an opportunity to grow a community around the open source software that matters the most to you. Getting software in to Fedora means a six to eighteen month jump on the Enterprise Linux beta. You can develop your software along with the operating system it runs on, and you may be able to help influence how other parts of Fedora are created.
(Edited to change “Java EE” to “Java SE”; OpenJDK 6 is Java SE compliant.)
The first candidate release (CR1) for JBoss Application Server 5 has been released. There is a lot of good background from Sacha Labourey and feature details from project lead Dimitris Andreadis. Now that version 5 of the new application server has been through alpha and beta stages, this candidate release is a great opportunity for developers to get knowledge and practice on the next gen app server.
(Tip of the hat for Ales Justin’s post about the CR1. Ales also posts new information about SpringDeployer and VFS .)
The first morning of JavaOne was a great serendipitous event. How often does something fall into place like this: I saw Barton George, who looks after Sun’s relationships with Linux communities, and we decided to cook up a podcast about OpenJDK 6 in Fedora 9. As we walked to the recording room, I commented that it would be great if we could get Tom Fitzsimmons, too. Not two beats later, we rounded a corner, and there stood Tom with Patrick Macdonald. Of course they were available and happy to record with us, and away we went.
Hear Barton (and a little bit of me) interview Tom and Patrick about the journey of OpenJDK and IcedTea: OGG and MP3
Patrick Macdonald, Tom Fitzsimmons (kneeling), and Karsten Wade. Photo: Barton George from this post The discussion covered the history of making a 100% free and open source runtime in Fedora from the initial Java open source code, which itself was 96% of a complete and self-building JDK. This remaining 4% was filled with components from GNU Classpath by the IcedTea team. The term “IcedTea” came from the package name used because, at that time, Fedora didn’t have a trademark license to use “OpenJDK”. Of the GNU Classpath code used, some if it ended up completing the circle to be included in OpenJDK. Based on relationships made at FOSDEM 2007, the team from Fedora/Red Hat were able to work with folks from Sun and other places to do work in the community in advance of resolving the remaining 4%, and do it in a way that could be more easily folded into OpenJDK. What is riveting about this story is the speed and quality of the outcome that is clearly due to the open source methodology used. By opening all the code that they could, Sun made it possible for others to fill the gaps Sun could not immediately fill. By working closely throughout that process, all of the open source code was used and tested in the community. Sun had time to choose the right license so the code could be merged. If Sun had waited until they could open all the code, we would have lost an entire year of development (at least.) Now that OpenJDK 6 is available in EPEL 5 for Red Hat Enterprise Linux 5, it is only a matter of time before it gets certified to appear in an update. This is being worked on by Keith Seitz and Mark Wielaard, who have “not many” test suites to complete to be ready to pass the TCK. Once that is done, the implementation can be called “Java compliant”, which is an important step to being ready for an Enterprise Linux 5.x update. Listen to the audio to get all the details, and check out Barton’s blog entry for his viewpoint.
At the JBoss booth at JavaOne 2008, I spoke with RichFaces developer Alexander Smirnov (OGG, MP3.) Alexander is the founder of the Ajax4jsf project, which he started as a personal side effort. It grew out of his interest in JSF and was originally run as a stand alone, self-hosted project.
As he developed Ajax4jsf, Alexander began working with the MyFaces community, and started communicating more with the larger JSF community. He moved the project to SourceForge at the suggestion of RichFaces lead developer Sergey Smirnov (no relation.) Exadel began developing the RichFaces JSF components library and Alexander joined the project as a framework background developer.
At the time it moved to java.net, Ajax4jsf had grown more useful when integrated with the RichFaces component library. RichFaces, however, was still not open source. The combined projects came to the attention of JBoss, which contracted with Exadel to open source both projects as JBoss projects. These were recently combined into a single project under the RichFaces name, available through JBoss.org. (RichFaces is combined with the JBoss Tools Eclipse-based developer environment to make up the JBoss Developer Studio subscription offering.)
Current activity for the RichFaces project includes a focus on building RichFaces functionality within JBoss Portlet Bridge. JBoss Portlet Bridge implements JSR-301 to provide support for not only JSF running in a portal, but also Seam and RichFaces.
Joining forces with JBoss has brought significantly more usage, ten times or more in terms of downloads. In particular, Alexander says there is an obvious increase in forum questions and discussions. In terms of attracting contributors, there are currently very few code contributions from the community outside of Exadel and JBoss. Alexander and Sergey describe the development process for the RichFaces team as being structured with a well-oiled process, which creates a higher barrier of entry for people outside of the team. As early ways to bring in external contributors, there are current needs for testing, defining future requirements, and requesting features and enhancements.
For the future roadmap of RichFaces, Alexander says that the next step is toward semantic web technologies.
This afternoon I caught a few minutes with Ivelin Ivanov, a lead developer on the Mobicents project. Mobicents is the first certified open source platform for developing and deploying JSLEE applications.
This audiocast is available from the JBoss.org podcast channel, in OGG and MP3 formats.
Continuing with the audiocast series from JBoss World 2008, this is EJB3 lead developer Carlo de Wolf talking about EJB 3 for Java developers new to Enterprise JavaBeans. The audio is available in OGG Vorbis and MP3 formats. Slides from the presentation are available.
As an ongoing joint operation, this audiocast is the first that is fed into the JBoss.org podcast channel (ATOM feed.) This is fun, as it allows us to distribute not only a title and rich description, but a thumbnail image full of meaning:
Fresh from Australia, via JBoss.org, this is nearly an hour-long presentation on Web Beans. As the specification lead and originator of the JSR, Gavin has a lot to say on the subject:
Gavin provides an exceptionally nice walk-through behind not just how Web Beans works, but why it works the way it does. He provides comparison to AOP features, and even demonstrates the recursive nature of Web Beans functionality being used to define Web Beans functionality. Meta-annotations are cool. Meta-meta-annotations are even cooler.
We’ve broken the talk into 3 easy-to-digest chunks:
Can’t be much clearer than a free book. Heiko W. Rupp’s publisher has released the book as a free PDF in German, with a small courtesy survey in front of the download. The book is also available from Amazon.de.
Thanks to Mark Proctor for this view inside of a JBoss developer support ticket for Drools.
I thought I would share with our readers a thread from our priority support system. It’s an interesting thread as it covers some complex constraint problems in good detail, which I think most rules users might find interesting, and it also demonstrates the level of support we provide to our priority customers. This conversation is printed “as is” with only the user and customer names removed.
Ironically, it’s not always easy to get a view into these type of interactions. Red Hat Knowledgebase has what might be called distilled results of customer interactions. Yet development support is different: there is a greater value in the conversation, and thus a greater value to other knowledge seekers. How much value?
Where knowledge is freely shared, everyone gains. Sure, there is an obvious bump for Drools, but all users of this open source software get value when we show each other how to better use it. We seek answers in various forums because another person may have encountered a similar situation. Contributing to that knowledge stream helps it become more useful to all contributors and users, who are us. Why not have a developer support ticket work as an extension of an open collaboration methodology?
The next time you need an answer, maybe it is available from a knowledgebase, via web search, or on the JBoss forums. If not, having developer support is one option, and perhaps the answers you receive might be useful to others in the community. If you write about it, drop me a message or tag it in del.icio.us (dev.fu feed) with the tag “for:dev.fu“.
