July 2007 Archives
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 PageI asked him a few questions about Flex, the pricing model, what is open-sourced, what is not, related open source projects, and the viability of JavaFX. Read more for the interview…
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 http://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 (http://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
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?
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.