restlet v1.0.4 was released last week with improved Spring integration. Check out the change log or download the zip archive.

The public restlet maven repository will be updated on the 1st August.

Well done Jerome, Thierry et al!

If you are using Commons Lang, Commons Collections, Commons BeanUtils, or anything else from the project formerly known as Jakarta Commons, you should know that the Jakarta Commons project has moved to a new web site: Apache Commons Project.

The Cairngorm Microarchitecture is a lightweight yet prescriptive framework for rich Internet application (RIA) development. - from Adobe Lab’s Cairngorm Page

Three years ago, Dan Diephouse founded the XFire project to provide an alternative to Apache Axis. In the subsequent years, XFire has matured into an easy-to-use, high-performance SOAP stack with first-class support for the Spring Framework: once the challenging newcomer, now the new standard for deploying web services on the Java platform. I recently had a chance to sit down with both Dan Diephouse and Paul Brown of Envoi Solutions to discuss the merger of XFire and IONA’s Celtix project into a new project, Apache CXF, currently under incubation at the Apache Software Foundation.

In the following interview, I ask both Dan and Paul about CXF. What differentiates CXF from projects like Apache Axis? How has XFire been affected by the Apache Incubator? And, some questions about corporate support of open source projects?

Read on for the full interview with Dan Diephouse and Paul Brown.

Wicket graduated from the incubator, or so I’ve heard. I’m never 100% sure of what has or has not graduated. Anyway, unlike a number of widely used open source libraries, Wicket is easy to checkout from source, compile, install, and have running up in Eclipse because it happens to use Maven 2 as a build system. In other words, you don’t have to fish around for instructions on running some byzantine Ant build, it’s all summed up by the following commands:

• svn co https://svn.apache.org/repos/asf/incubator/wicket/trunk wicket
• cd wicket
• mvn install eclipse:eclipse
• (start eclipse…)
• (File -> Import -> Existing Projects into Workspace) *don’t click copy, leave ‘em where they are
• (configure your M2_REPO classpath variable to point to your local repository)

Done - took you maybe 5 minutes start to finish…

And, that’s the way it should be. No need to read some readme file to try to figure out what software needed to be installed, or what other projects need to be in what relative directories, etc…

maven 2 just works.

Update 9:09 PM: Thanks to Mr. Locke for correctly pointing out that I left out the import projects step in the comments.

The new Java EE 6 specification was approved on July 16th. It passed with an overwhelming majority: 14 yes votes, 1 no vote (Apache), and 1 abstention (Borland). The story here isn’t that the JSR passed with flying colors, it is that this is the first major JSR approved since the open letter from the Apache Software Foundation and the problems caused by the Field of Use restrictions on the TCK. This JSR passed but with a statement about licensing from IBM, and two statements of future expectations from Red Hat and Intel.

IBM voted yes with a comment:

IBM’s vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM’s preferred licensing model.

Intel also made a similar statement:

The Spec Lead has told us there are no “field of use restrictions” on implementations for this particular JSR. The Apache open letter about Java SE (https://www.apache.org/jcp/sunopenletter.html) claimed that a confidential license for a required JCP test suite restricts how Independent Implementations of that JCP spec can be used. Licenses to test for JCP compatibility must not be used to limit or restrict competing, compatible implementations; licenses containing such limitations do not meet the requirements of the JSPA, the agreement under which the JCP operates. For every JCP ballot, we will ask the Spec Lead whether such restrictions exist in their license.

Red Hat filed a similar comment along with a YES vote. Note the emphasis:

The spec lead of the EE6 specification has confirmed that the EE6 TCK would contain no “field of use restrictions”, as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing.

However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR.

Consequently, in the future, for any submitted JSR (by SUNW or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.

And Apache voted NO with the following comment:

The Apache Software Foundation’s vote is based on the point of view that this spec lead - Sun - is in violation of the JSPA

https://www.apache.org/jcp/sunopenletter.html

and therefore shouldn’t be allowed to start another JSR until the above matter is resolved.

This vote is not a comment on the technical merits of the JSR. If not for the issue of the spec lead, the ASF would have otherwise voted “yes”.

From the jcp-open list at the ASF, Geir Magnusson’s from the 15th:

I’d like to vote “no” simply on the grounds that from our point of
view, this spec lead - Sun - is in violation of the JSPA, and
therefore we don’t think they should be allowed to start another JSR
until the matter is cleared up

In software development we are often encouraged to decouple things in order to achieve greater flexibility in our code. So we decouple model objects from views, interfaces from their implementation, etc.

Here, I would like to write about different kind of decoupling, front-end from back-end. In many cases, projects tend to depend on resources that are either unreliable or overloaded. For example, besides your “main” database, you may need to write data to some LDAP server that is overloaded or you need to provide some data to the resources over the unreliable network connection. In most of these use cases, these operations are triggered by users through the user interface (web or stand-alone application). It is totally unnecessary (and usually unacceptable) to have your users wait a few minutes for operation to complete or in worse case to have dysfunctional system just because one resource is unavailable.

JBoss Seam and Adobe Flex are two promising technologies. Seam makes it easy to build stateful web applications. It integrates the Java EE frameworks together. Flex is a great rich application development framework. The question is can they and should they be used together?

Seam till its 1.x versions used JSF as the main UI framework. This implied that it was built around a server side UI model. Flex on the contrary is a client side UI framework. Oops! so we have a big disconnect right away! Not really, there possibly are some viable options to make them work together. In the latest version of Seam 2.0.0 BETA the coupling with JSF has been loosened. Also, in the past its been demonstrated that JavaScript UIs (built on frameworks like DOJO or any other) could directly remote to Seam server side components. Remember though that JavaScript runs within the browser whereas Flex applications runs within the Flash VM. Does that matter?One option is to have Flex as the front end and make Flex components remote to Seam? Technically this is a possibility and may be good in situations where Flex is used as a pure view description technology. In fact has anybody wondered writing a JSF render kit for Flex? That would be one nice looking but ugly under the hood hack. The state and event management would be all mixed up and one would end up writing more wiring to save the two together than use in isolation. I know some of you may oppose this thought and may cite cases where you have used Applets as a face for Servlets or similar server side technologies. Yes it works, is it elegant though? And what were the big wins of making them work together anyway? This the same question I ask when I read articles that claim that Spring MVC can work smoothly with Flex and Java Portlets can work effortlessly with Flex. Is it better to make complicated applications by spending more time and energy as opposed to building clean applications faster? In other words is it better to do the right thing or focus on making everyone happy?

So what does it mean in the context of our main exploration of making Seam and Flex work together? We have looked at the dry option of remoting a Flex face to a Seam server side. We could possibly liven it up by managing state on both sides - client and server - and introduce something that could be called a State Transfer Object (STO) to transfer the state information back and forth. Doesn’t sound good! It reminds me of the pain of using DTOs. Is there any other option? My answer is that I don’t know of one yet. I am trying to write a bridge between the two, following the principle of delegation and inclusion of common contexts wherever possible and ofcourse cheating (oh sorry! drawing inspiration) from the JavaScript remoting integration and the GWT integration in the Seam code base. If and when its ready, it would show up as an open source tool for everybody to play with and I will annouce its arrival. BTW, if anyone else here is interested in hacking that with me, you are most welcome to join in. In the meanwhile I would certainly like to hear your experiences in making these two work together. Both real life experiences and armchair musing are welcome.

On a recent flight from Boston to Melbourne i decided to have a play around with buildr and convert a small rest based web application from maven to buildr. Buildr is a ruby-based DSL build system for Java applications. The ruby plugin comes from the folks @ Intalio and born from their frustration in using maven for build management. The documentation on the rubyforge site is very good and provides a good introduction but to do more you’ll probably need to browse the ruby source code.

It took about a day of playing around before i managed to replicate my maven build, which included compiling, testing, packaging a war and running up the war on an instance of a jetty server.

All extension tasks (ala maven plugins) are written in Ruby so you get all the power and benefits of a turing complete language as opposed to the constraints of maven plugins. It’s definitely much easier to extend buildr with new tasks than to write a maven plugin.

You may have seen Assaf’s claims that builds are faster under buildr and my initial experience seems to confirm this.

If you’re looking at using it beyond a small project have a look at Apache ODE’s Rakefile, which is used to manage multi-project builds.