Extreme productivity with JSF 2.0 and Deltaset

I am going to introduce you to the newly created "Deltaset Project". I have just released the first publicly avaiable version - 0.8.1.
It is the logical 'next step' after my prevoius post : http://dmakariev.blogspot.com/2010/01/jsf-20-with-spring-3-and-spring.html
The number of people, who read it, is quite impressive.. 14,429... If you type "jsf 2.0 spring 3" you can see that same post, and refenreces to it,
occupying the first page of google, bing and yahoo. And definitly , I have not used any SEO techniques :).

I want to say big "THANK YOU GUYS !" to everyone who has appreciated that post; to all the great comments; to all the mails which I've received.

My biggest issue was that the ideas, which I've presented here, were not ready for support, change and mass usage. It was just a showcase of "how a java web application could be developed efficiently".

Now ... after several months of work, few sleepless nights, several small scale presentations, I'm ready to demonstrate the newly released productivity tool:


The project is licensed under GPLv3, it is hosted on Google Hosting.
You can see the new demo at http://deltaset-demo.appspot.com

Quick Start

Deltaset requires you to download and install:
  1. Create project :
    mvn archetype:generate -DarchetypeCatalog=http://deltaset.googlecode.com/svn/maven2/
    you should choose number (1) - the 'deltaset-gae-archetype'.

  2. Add domain object (you should be in the base directory of the application - where the pom.xml was created):
    mvn -Pdeltaset -Dcmd=crud=Person:[firstName,lastName,birthDate:[@type:date]]
  3. Build :
    mvn package
  4. Run:
    dev_appserver target\YOUR_APP_NAME

Now... Let's create a small Pet Clinic :

  1. Open the script.ds file from the base directory of your project.
    At the end of the file you will see the model :


  2. Change it.. as you like :)
  3. Generate :
    mvn -Pdeltaset -Dcmd=file=script.ds
  4. Build and run.

What happened till now ?

First.. just few minutes have passed..

A brand new, full blown, java web application was created.

But what exactly was created?

During the 'archetype:generate' I have used "org.deltaset.demo" for groupId and package,
and "demo" for artifactId.

Here is the directory structure of the application:
¦ +---java
¦ ¦ +---org
¦ ¦ +---deltaset
¦ ¦ +---demo
¦ ¦ +---aspect
¦ ¦ +---config
¦ ¦ +---converter
¦ ¦ +---domain
¦ ¦ +---persistence
¦ ¦ +---repository
¦ ¦ +---resource
¦ ¦ +---user
¦ ¦ +---web
¦ +---resources
¦ ¦ +---META-INF
¦ ¦ +---org
¦ ¦ +---deltaset
¦ ¦ +---demo
¦ +---script
¦ ¦ +---templates
¦ ¦ +---mapped
¦ ¦ +---test
¦ +---webapp
¦ +---resources
¦ ¦ +---app
¦ ¦ +---css
¦ ¦ ¦ +---img
¦ ¦ +---internal
¦ +---secured
¦ ¦ +---person
¦ +---WEB-INF
Let me give you brief explanation of what is contained in the folders :
for simplicity I will use
JAVA_FOLDER instead of src/main/java/org/deltaset/demo
WEB_FOLDER instead of src/main/webapp

JAVA_FOLDER/aspect - your aspectJ classes should go here. Currently there are 2 simple java classes, using the @Aspect syntax. The aspects could be used for crosscutting concepts like logging, performance measuring, etc.. or just ignored :)
JAVA_FOLDER/config - your Spring @Configuration java classes.
JAVA_FOLDER/converter - here would be generated the JAXB domain to xml or json converter classes / acctually delegating decorators :) /
JAVA_FOLDER/domain - your generated domain classes (enum and JPA @Entity classes )
JAVA_FOLDER/persistence - here is the AppEngineEntityManagerFactory SINGELTON.... implemented as recomended by Google Application Engine documentation,
and also the UnonwedLoader helper static class... needed for handling some of the relations in the entities.
JAVA_FOLDER/repository - your generated Repository classes ( @Repository form Spring)- / also known as DAOs :) /, they are defining the transaction boundaries (@Transactional from Spring) and the security access (@RolesAllowed - javax.annotation.security.RolesAllowed )to the domain objects.
JAVA_FOLDER/resource - your generated RESTfull endpoints
JAVA_FOLDER/user - this package is responcible for Login and Preferences handling... you will have to be chang it, according to your requirements.
JAVA_FOLDER/web - your generated JSF @ManagedBean classes ( using the javax.annotation.ManagedBean and injecting dependencies with @Inject)

src/main/resources - the standard Maven resources folder: persistence.xml, properties files, etc
src/main/script - here are the groovy and template files needed by the generator. The 'starting' point is the 'CommandProcessor.groovy'

WEB_FOLDER/resources - as defined by the JSF 2.0 spec. In this folder is the 'app' custom component jsf library.
interesting files are page.xhtml, internal/layout-two-column.xhtml and the menu.xhtml. You will have to customize them to fit your requirements.
WEB_FOLDER/secured - here would be generated more folders, with names created from the names of your domain classes.
Each folder will contain the needed xhtml files. For a real application you will spend some time in that folders during customizing the UI :)

This should be 'just enough description' to give you a quick start introduction for creating your own applications with "Deltaset"

What about your own archetype ?

I will make some copy/paste from the start page of http://www.deltaset.org :
You can easy create your own specific productivity environment, based on the project initially created with DeltaSet.
Just execute :
mvn install -Darchetype=true
If you want to use your newly created archetype.Then... type:
mvn archetype:generate -DarchetypeCatalog=local

Plain JSF 2.0 and Expression Language 2.2 on Google Application Engine

There might be some of you, who just want to use the JSF 2.0 / Expression Language 2.2 integration with Google Application Engine.

So... Hey.. you don't have to tear apart the 'deltaset-gae-archetype' folders.
just use number (2) from the archetype Catalog : 'hello-jsf-el-2-gae-archetype'

mvn archetype:generate -DarchetypeCatalog=http://deltaset.googlecode.com/svn/maven2/

Deltaset Technology highlights

  • JSF 2.0 with Expression Language 2.2
  • JSR 303: Bean Validation - using Hibernate Validator
  • JSR 330: Dependency Injection for Java - using Spring 3.x
  • integrated with Spring Security 3.x
  • JSR 311: JAX-RS 1.1 for building RESTful Web services - using Jersey 1.3
  • JAXB 2.1 - using https://jaxb.dev.java.net/
  • JPA 1.0 - using DataNucleus for Google Application Engine
  • Aspect Oriented Programming - using AspectJ
  • JPA 2.0 - using EclipseLink (under development...)
  • JQuery 1.4.2
  • JQuery UI 1.8.4

Deployment environments

  • Google Application Engine
  • Jetty/Tomcat - Servlet 2.5 (under developmet...)
  • Glassfish (under development...)

What's next ?

Hopefully soon I will cover the following topics:

  • JSF 2.0 and Expression Language 2.2 on Google Application - how was that made possible ?
  • Request only CRUD for JSF 2.0
  • Using JSF 2.0 templates as Lego Blocks
  • Modular applications with JSF 2.0 (no OSGi)
  • Multitenant applications with Deltaset
  • Code generation with Deltaset (how-to create your own productivity tool)
  • Deltaset Faces - why is it a cool custom component set ?
  • JSF 2.0 and HTML 5 in the context of Deltaset (and not only)
  • JSF 2.0 and Spring Security
  • Deltaset on Jetty/Tomcat/Glassfish

Was the project inspired by Spring Roo?

Well.. not at all :)

The initial idea was implemented in the end of 2007, it was based on JSF 1.2 and Richfaces, but never made it to the public (mainly due to lack of time.. ). It was used just in few proprietery projects.

During my "small scale" demonstrations, I was asked several times questions like:

"is there any relation to Spring Roo", "what is the difference with Spring Roo", "why don't you just create a jsf add-on for Spring Roo".

I've answered to them, and I want to answer in front of all of you, who might be thinking about them now.

The only relation with Spring Roo is that the both projects are trying to solve the issue with java productivity. And basically thats almost all in common :)

The aproaches are completely different. Spring Roo uses AspectJ inter-type declarations (ITDs) as a code generation technique.
Deltaset uses plain Groovy templates.

Spring Roo is 'roundtrip' generation
Deltaset is one-way.

Spring Roo tryes to manage your generated code 'invisibly' - it is trying to stay out of your way, and still to controll the artifacts, you don't want to manage by hand.
Deltaset just creates the needed files, and leaves everything else to you :)

Spring Roo claims that you will '100% develop in Java'. Here I disagree.. ITDs are definitly a brilliant code-generation architecture, but this is not 100% Java, this is AspectJ :),
If you want to use Spring Roo, you must use either Eclipse with AspectJ support , or SpringSource Tool Suite. They are great IDEs, but .. I like Netbeans :).
Also.. try to explain AspectJ and ITDs to junior level developers... or to anyone who doesn't have experience with AspectJ.. well it is not that easy.
Deltaset generates standard java files..

Spring Roo generates 'Rich Domain Objects'.Nice.. but.. try using method level security :).. not trivial, at least until the Spring Roo guys upgrade to Spring Security 3.0.3.RELEASE - https://jira.springframework.org/browse/SEC-1232 /
Deltaset generates plain old 3-tier architecture. It generates method-level security by default:)

Spring Roo uses Spring MVC and Google Web Toolkit
Deltaset uses JSF 2.0

So .. what is that comparasion showing.. : Deltaset is not copy of Spring Roo,

and by the way Spring Roo is Great Technology! ...quite polished :) I really like it !

As final words.. I hope that you, dear reader, have enjoyed that post... And even more... That you are conviced, you have to try the 'Deltaset way'.

Have fun :)
And I'm definitly waiting for your feedback, questions and proposals ;)


  1. Hi Dimitar,
    Thanks for the great framework. Just few feature I would like to see.

    1. Seperation of GAE code from the core. i.e. Users should be able to use it outside GAE with very little or no modifications.

    2. Integration with JSR 299 (may be Weld). Not sure how this can be done though.

    3. Primefaces integration. This is a low priority :-) I know this is pretty easy

    4. More modular maven project whcih can be scales to enterprise level big projects

    1. Apache myfaces can be used instead of refernece impl. So that you don't need to patch the existing reference jsf impl.

  2. Hi Murali Mohan Rath,

    thanks for the feedback :).. regarding your proposals.. most of them are just around the corner.. The most probable way of appearing is:

    1. Primefaces - this is really the easiest :)

    2. Archetype for Tomcat/Jetty/, and probably separate for Glassfish :
    the biggest difference between the GAE and JEE is the JPA implementation of DataNucleus for BigTable.. it needs some workarounds for the support of OneToMany and ManyToOne.. And :) now I should implement them in the standard way :)

    3. Modular maven project for enterprise level projects. This is with the highest prio for me.. Actually the whole project is developed with that idea in mind.. I've released the current version, to verify with the community, how that kind of code generation would be appreciated. So.. to keep it simple for involving I have decided to exclude from the very first 'public release' the multi project archetype.

    Things which I will consider, but I haven't planned:

    1. Apache MyFaces - that will probably simplify the current patching process. I just have bad memories about performance since 1.1 :) I will check the latest version.

    2. JSR 299 (Weld) - I'm still not convinced in the benefits of that spec. I'm currently supporting the JSR 330 (@Inject) through spring and I am planning to introduce Google Guice in a separate archetype. If anybody succeed in convincing me in the benefits of JSR 299 (with arguments... not just passion ) I will include it.

  3. "JSR 299 (Weld) - I'm still not convinced in the benefits of that spec. I'm currently supporting the JSR 330 (@Inject) through spring and I am planning to introduce Google Guice in a separate archetype. If anybody succeed in convincing me in the benefits of JSR 299 (with arguments... not just passion ) I will include it."

    1. This is a standard; a better selling point to my manager

    2. CDI can do anything that is done by Spring DI.

    3. CDI type-safe but Spring? no.. Not a big reason though. I have used spring and never had problem due to this. Again a selling point.

    If I am developing for a JEE 6 server I would definitely use the standard JSR 299 implementation from the app server for DI. Use EJBs for the services. I don't see any value in using spring's DI and add extra libs.

    Then comes other pieces of utilities provided by Spring e.g spring-jms. Yes I might consider using spring; but spring is not the only option available.

  4. Hi Murali Mohan Rath,
    Thanks again :),
    The points which I fully agree are:
    1. JSR 299 is a standard, working out-of-the-box in JEE 6 servers. Also JEE 6 servers support JSR 330, EJB 3, JPA 2, container-managed transaction and security. So.. for the Glassfish archetype.. I will use just the JSR 330 without Spring... My goal is to have the simplest possible meaningful archetypes (no additional jars)
    2. Because JSR 299 is standard, it is probably easy to sell to the management... But.. It depends.. on the management :)
    3. JSR 330 is good - "CDI can do anything that is done by Spring DI", I would put in the same category Google Guice.

    The point to which I don't agree :
    Type-safety - If you pay attention to how I'm using the JSR 330 in the published archetype, you will see that it is type-safe :), and because the provider is Spring - means that nowadays it could be type-safe also. (here it really depends on the coding style, with Spring you can definitely create a huge number of difficult to maintain xml files )

    Otherwise.. I don't see benefits of Weld over Spring Framework in a non JEE 6 environment. Spring is far beyond the DI Container : Transaction Management, Security, AOP...

    At the end - I'm not convinced by the JSR 299 (no need to use it even in JEE 6 server)
    But I'm absolutely convinced by JSR 330 - this is the spec that was really needed.

  5. "Otherwise.. I don't see benefits of Weld over Spring Framework in a non JEE 6 environment. Spring is far beyond the DI Container : Transaction Management, Security, AOP...

    At the end - I'm not convinced by the JSR 299 (no need to use it even in JEE 6 server)"

    Transaction management: Won't you get that by default in a JEE 6 server?

    Security: did you mean spring-security?

    AOP: I have used spring in projects. I didn't have to write many Aspects. And even CDI and EJB provide you Intercepters which can do the same task as AOP.

  6. Hi Murali Mohan Rath,
    probably I was not completely clear.. :
    1.Transaction management - read carefully my previous answer. I've said that this features are provided by JEE server, but not by JSR 299.
    The main benefits from the Spring Framework are in "NON JEE server" like tomcat, jetty, Google application engine.
    2.Security - yes I mean spring-security.


Popular posts from this blog

JSF 2.0 with Spring 3 and Spring Security 3 on Google Application Engine

JSF 2.0 with Maven 2 plugins for Glassfish v3, Jetty and Tomcat