It is what it is

We have been working hard to get this release done with a great set of new features!!!

First and foremost, I’m very proud of the level support we have now reached for Eclipse. As you may know, Juzu relies much on Annotation Processing Tools (APT) since the beginning to bring exclusive features. Making Juzu work with Eclipse incremental compiler was very challenging because APT simply works differently. Among those features, the type safe template parameters with Eclipse is showed in this screencast

The dev mode feature has been improved a lot, specially now the error reporting is more accurate and sexy, this screencast will teach you everything about switching an application to dev mode in Liferay

Juzu comes as a package to download on this page. Alternatively you can also use the maven archetype to bootstrap an application

Finally, the Dependency Injection has been improved in order to allow the injection of external providers, in particular this is useful if you are using Juzu in the GateIn server and you want to inject GateIn services in a Juzu application, this is now trivial to do and is explained in the wiki.

For the future we plan to develop new features and improve step by step the project, on top of my mind the integration with Bean Validation would be a good thing to do. If you are interested to follow the Juzu project development you can join our Juzu group.

Juzu is an open source web framework I started to work on recently, for several reasons, the most important one is that there is no decent framework for developing portlet application in a simple and productive manner. There are other good and valid reasons.

Juzu deploys on the GateIn Portal and on the Liferay Portal. Perhaps it also deploys on other portals, there aren’t any good reason why Juzu would not work on other portal (except bugs).

Juzu integrates with dependency injection frameworks such as Weld (CDI) and Spring, theoretically it should work with any injection framework providing a good support of the JSR-330 specification (however it requires some custom integration work, as JSR-330 is really lightweight…)

Juzu is a work in progress, however it is advanced enough to deliver the infamous Booking application.

If you are interested in Juzu (using or helping), you can start to read this page.

We released last week the first milestone of GateIn 3.2, it was a long time since the 3.1 release and both Red Hat and eXo teams were quite busy working on the product and project side of GateIn.

Among the noticeable changes, you will find now a support for Jetty 6.1/Tomcat 7/JBoss AS 6 web containers, a improved Maven build compatible with Maven 3, a few UI improvements and many bug fixes. You can read more about it there.

I’m proud now to work with Bolek that will replace Thomas Heute as GateIn technical lead. Bolek was involved in the effort since the JBoss Portal projects and earned his credits by providing an Hibernate implementation of the now dead Slide project (JCR ancestor) and implementing much of the Portlet 1 TCK assertions in our testsuite (that proved to be invaluable when JSR 286 was implemented). He blogged about his new role in the project here.

If you are a fan of GateIn, the CRaSH shell is a must have companion for GateIn. CRaSH is a shell that provides a JCR access and allows to do stuff and hack GateIn. Use it at your own risks of course . Download of the latest beta-21 is here.

Finally it’s time of a few words about GateIn stuff that is another GateIn companion I started a few months ago on GitHub. It’s something more informal than a real project, it’s like a bunch of stuff that could be useful if you’re a GateIn user, at least it’s useful to me, it contains so far

• a CRaSH folder with command for adding users to GateIn
• gen : an XML generator for generating large navigations
• sqlman : a tool based on the great JBoss Byteman project that measures the access to resources, very valuable for monitoring database activity. Note that this tool is generic and does not depend on GateIn itself. We could extract it and find a better name (containing “spy”)

Nothing fancy, in it, mostly bug fixes (in particular for SCP CRASH-23 and CRASH-24).

I updated also the Google Code page to add links to GitHub where the project is now hosted and the online docs now have the PDF and the Javadoc.

Finally the project CI is now Jenkins hosted by my friends at Cloudbees. A special thanks to Arnaud for helping me setting this up.

The release is available on Google Code as usual.

So far the annotation API in Reflext was using the runtime API to provide annotation access. What I call the runtime API is what most of developers are used to when dealing with annotations.

When using the java.lang.reflect runtime, this works perfectly as the runtime provides obviously runtime annotation. Nothing special here. However at compile time, this runtime access is emulated by the compiler. The real API to access an annotation is the java.lang.model.element.AnnotationMirror interface that is a totally detyped access to an annotation. But the APT tries to be nice and provides an emulation of runtime annotation that works well until

• the introspected annotation is being compiled and it is not yet available under its class form
• the annotation is already compiled (coming likely from JDK or a dependency) but it has a Class parameter and that class is being compiled. In that situation the Class object is not yet available, consequently it fails.

For that matter there is now in Reflext an API that provides a detyped access to an annotation that works equally with runtime and compile time implementations (runtime annotation access is still possible of course) .Using such API is obviously less intuitive than using the annotation directly but when you don’t have the guarantee that you are the annotation type is already compiled it’s the only way to go.

We have just released CRaSH 1.0.0 Beta 8 on Google Code forge, in that release we have worked on two usability aspects of the shell:

• The capability for a command to prompt a value with or without echo of the value entered by the user. It is mainly used by the connect command to prompt the password when it is not entered via the -p option.
• The second feature is the up/down arrow associated to recalling previously entered commands.