Building Spring 3 working with Git

Until today, I've been keeping up on the Spring 3 development off the svn repository with svn. There is a great post by Chris Beams from SpringSource that provides adequate detail and is a great resource to read as a precursor to this post. In general, I'm moving all my development over to Git, and it was time to get Spring 3 inline. It was not without pain. For those who just want a quick reference, I will provide a quick step by step on how to achieve the end goal of setting up a git client to the spring 3 svn repository. Following that I will provide details for those who want a deeper understanding.

Quick Step-by-Step Spring 3 with Git

1. In the directory you would like the spring project execute : "git svn clone --stdlayout https://src.springsource.org/svn/spring-framework"
   
2. change directory to the newly created spring-framework directory
   
3. copy forked script from github.com/kensipe named git-svn-clone-externals to the current directory; make executable and run.
   
4. run "git svn show-ignore > .gitignore"
5. run "git gc"
6. from the current directory you'll need to create the following directories
mkdir org.springframework.instrument/src/main/resources/
mkdir org.springframework.instrument/src/main/resources/META-INF
mkdir org.springframework.instrument.classloading/src/main/resources
mkdir org.springframework.instrument.classloading/src/main/resources/META-INF
mkdir org.springframework.asm/src
mkdir org.springframework.asm/src/main
mkdir org.springframework.asm/src/main/java
mkdir org.springframework.core/src/main/resources
mkdir org.springframework.core/src/main/resources/META-INF
mkdir org.springframework.expression/src/main/resources
mkdir org.springframework.expression/src/main/resources/META-INF
mkdir org.springframework.web/src/main/resources
mkdir org.springframework.web/src/main/resources/META-INF
mkdir org.springframework.orm/src/main/resources
mkdir org.springframework.orm/src/main/resources/META-INF
mkdir org.springframework.context.support/src/main/resources
mkdir org.springframework.context.support/src/main/resources/META-INF
mkdir org.springframework.web.portlet/src/main/resources
mkdir org.springframework.web.portlet/src/main/resources/META-INF
mkdir org.springframework.test/src/main/resources
mkdir org.springframework.test/src/main/resources/META-INF
mkdir org.springframework.integration-tests/src/main
mkdir org.springframework.integration-tests/src/main/java
mkdir org.springframework.integration-tests/src/main/resources
mkdir org.springframework.integration-tests/src/main/resources/META-INF
mkdir org.springframework.instrument/src/test/java
mkdir org.springframework.instrument.classloading/src/test/java
mkdir org.springframework.asm/src/test
mkdir org.springframework.asm/src/test/java
mkdir org.springframework.aspects/src/test/java

7. export ANT_OPTS="-XX:MaxPermSize=256m -Xmx1024m"
8. change directory to "build-spring-framework" directory
9. run "ant"
10. wait 20 minutes :)

The background and detail
The first line is standard git-svn to get the repository. If you are new to Git, this will take a few minutes long then a standard svn checkout. It is copying all the changes throughout history to your local .git repo. Fortunately spring 3 is still young from a history standpoint.

svn external - The first issue
The first thing to note is that part of the build process for spring 3 is a project which is added to this svn project as an external, which led me to this post on why svn externals are evil :) evil or not we have to deal with them. This led to a post by Alieniloquent which has some good explanations, followed by what I eventually settled on, a post by Andre Pang, which includes a script he created, which I forked off github. Kudos to Andre!! The script he created (which I can see using again the future), provides a one execution solution to what Alieniloquent blogged. It is beautifully simple. The script provides the following:

1. pulls down all the svn externals (spring 3 only has one)
2. creates a symlink (mocking what svn would have done)
3. adds the symlink and the .git_externals directory to the excludes file

If you wanted to check your svn externals for other projects use the following command: "git svn propget svn:externals ." in the root of the project directory.

The next step is to get all the svn ignores into the .gitignores file.

version control directory management - the next issue
The explanation behind this issue is that svn allows for and manages empty directories... git does not. git only manages content. There are a number of empty directories which the spring build files expects to be present for the build to succeed. This is based on a standardize build system and a lack of error handling in the build system. If I get some time, I'll send a patch to the springsource guys to fix this. At this time you will have to create all the directories listed.

jvm out of memory issues - the last issue
ant will run out of memory without these changes.... first you will run out of perm space, followed by heap. You may be able to get by with less; I didn't spend much time here. The standard defaults will fail.

Also if you need to update your master branch with git... "git svn rebase" will do the job!

I need to say thanks to those bloggers already noted and to fellow NFJS speaker Matthew McCollough.

JSR-299 Web Bean Review

As several JCP specifications are reaching there final stages, I decided to have a look at two of them. Truth be known, I actually was going to look at one of them jsr-299, the specification previously known as web beans, here forth now known as Java Contexts and Dependency Inject. There was sufficient enough mention of ejb-lite that I decided to have a look at its specification, jsr-318.

Before I get started, my position on the subject of ejbs should be known. I actually thought that ejbs were on the way out... with the lack of testability and the extra unnecessary complexity for most projects prior to ejb3. EJB3 greatly improved this, but IMHO was too little too late. Spring + Tomcat already provided what folks were looking for. Additionally the number of clients using JSF is a dying breed. Once again, JSF 1.0 missed the boat with non-bookmarkable pages, etc. While there are shops sticking with these Sun driven standards which are produced out of the JCP, the majority of support appears to come out of vendor interest and not developer interest. My earlier work on projects with JSF led me to appreciate a couple of frameworks; 1. facelets, 2. a4jsf, and 3. SEAM (when working on jboss). jsr-299 (web beans) seems to be the formal standardization of SEAM.

My thoughts on jsr-299
It appears that @ annotations are the new shiny toy, and there is no end to specifications going crazy with them. jsr-299 defines 34 new annotations. The goal of the specification as defined on the spec home page, is to unify JSF managed bean component model with the EJB component model... well I've stated my position on this. So either this specification is too little too late and a benefit mainly to jboss, or perhaps there is something to be gained beyond this spec stated goal.

There were several interesting ideas out of the specification. The first was the creation of an extensible annotation model. So if there are not enough annotations in the world for you, you can create your own that work with the framework. This is accomplished through the new javax.inject.@BindingType. This appears to provide fine grain autowiring qualifier. One of the examples given defines
@LDAP
class LdapAuthenticator
implements Authenticator { ... }

followed by the declared injection of an LDAP Authenticator:
@LDAP Authenticator authenticator

Another interesting idea is producers... I really like the concept here. Page 3 and 4 illustrate an example where a @SessionScoped @Model Login class has a @Produces @LoggedIn User getCurrentUser() method. Abbreviated below:
@SessionScoped @Model public class Login {
@Current Credentials credentials;
@PersistenceContext EntityManager userDatabase;
private User user;

@Produces @LoggedIn User getCurrentUser() {
if (user==null) {
throw new NotLoggedInException();
} else {
return user;
}
}

Then the getCurrentUser() method is invoked for the inject as listed below:
@Model
public class DocumentEditor {
@Current Document document;
@LoggedIn User user;
@PersistenceContext EntityManager docDatabase;
public void save() {
document.setCreatedBy(currentUser);
em.persist(document);
}
}

The last interesting part of the specification is the event framework. I don't understand why this is in the specification. There appears to be no dependency for the event framework on the other parts of the specification. It doesn't comply with the stated goal of unification of JSF and EJB. It would make sense for this to be separate. Mainly to use it separate from all other aspects of web beans.

Thoughts on jsr-318
I did not review the entire specification yet. I was checking out some of the mentioned ejb-light details mentioned in jsr299. As mentioned, outside of being required by clients to help them with ejbs or ejb light projects, I'm really not interested. There is however one very interesting addition to the ejb specification, that is the @Asynchronous annotation. This is long over due. In addition to its obvious benefits, a method annotated as asynchronous can also return a value defined as java.util.concurrent.Future where V is the return value type. The return of the Future object provides the ability to check status (isDone()) or to cancel the request. Very cool. For a quick list of EJB 3.1 changes, checkout Ken Saks blog.
The concept of EJB-lite is lost on me... I already have that it is Spring.

Summary
If you are looking to stay in the world of EJBs and JSF, then these newly defined specifications are of great value to you and your shop. jsr-299 fills a number of gaps in the jee space and provides the power of Spring in a standardized way. Clearly jsr-299 will be part of the new jee 1.6 specification, at least in several of the profiles. If you are not using either JSF or EJB or nether, then it is unclear what value this brings to the community. It will be interesting to see if a vendor implements this specification (or a portion of it), in a world without JSF. It appears that the jsr-299 specification helps vendors more than it helps developers.

Spring JavaScript

I'm sitting in Keith's Talk @ NFJS Orlando on Spring JavaScript . I've worked with a lot of the spring framework on varies projects over time. I have not until now had a chance to look at what SpringSource was doing with JavaScript. This is great technology which desires some blog time in the future.

There is an underlying theme in the approach Keith is describing which I really like. The concept is a design approach where ajax provides value-add to a client which allows for javascript. Yet the application still functions without it.

Impressions from a one hour guided tour. Things I liked:

1. Choice of dojo as the underlying framework
2. Design approach
3. Use of Tiles
4. Leveraging of yahoo performance rules for script compression and optimization

Things to look forward to:

1. Binding of multiple decorations to the same html element
2. Closer look at Spring's CSS Framework

Great example application was demo to show off spring capabilites... but it is actually a very useful application reporting dependencies of osgi bundles. Take a look: http://springsource.com/repository/