Is Glassfish an OS Project?

Right before JavaOne, I was added as the first developer outside of Sun to work on their Glassfish project (open source J2EE 5 server). This is great, the team is big, or so it seems. But I'm not sure there are really any other developers contributing. Why not? Is it the license or the company?

My opinion is that open source is two things-- open code and open processes. If the Glassfish project is ever going to form a community around their product, they need to open their processes. The code going in is available to everyone, but right now, their ideas aren't.

A project as big as Glassfish is like a moving train. Right now, with how talented the developers are at Sun, this train is moving very quickly. To someone who would like to get involved and contribute, they aren't going to easily be able to 'hop on' by peeling through the code as it's checked in.

What a potential developer would first need to do is get advance knowledge of the ideas that are being brought to the table. What's one developer thinking vs. another and where might your ideas help the project out? What's the next obvious step? Contributing your ideas in code.

I'm hoping that Glassfish will make that push to communicating on their Java.net lists. Maybe Sun's developers don't need any input right now, but input will never hurt you.

Facelets Documentation

Facelets is going awesome, and I mean a.w.e.s.o.m.e.

Between adding features and tweaking the compiler, I've put together some documentation:

https://facelets.dev.java.net/nonav/docs/dev/docbook.html

Also, I might be moving my blogging over to Java.net. I would like to start a series on 'JSF Myths' to squelch many misconceptions that 'casually' interested developers complain about.

A Small Note on UI Design

All too many times, people designing web pages start out by boxing all of their content out into strict columns with graphical elements. Graphical elements such as backgrounds or lines that visually separate content.

During initial design phases, you may think that everything works visually. Long term, this can cause problems in your design since it loses it's ability to 'flex'. I'm not talking about strict 680 pixel versus 100% widths, I'm talking about handling visual use cases.

If you've gone through the work of strictly specifying all content areas such as a menu, submenu, text, header, etc-- what happens when the ideal case is to just show a table with just a few buttons? You can't because you've partitioned out your layout visually with graphical elements already. You may not always need to present a submenu or info box on all pages. So don't create a layout that always requires it.

A good example of proper UI design that can accomodate change while keeping a consistent look and feel is Apple.com. You have your header treatment, but all of the content below is placed on a 'whiteboard' where your UI can adapt to different requirements. There are no lines restricting where and how content can be placed, every page is ideally suited and layed out to support interaction with the user.

In summary, pursue a consistent look and feel with your web site, but don't start designing your UI with presumptions that a 2 column or 3 column layout is ideal for every page. This will allow you to keep your UI much simpler (and possibly more performant) when you don't force or cram content into your page based on the layout you came up with in photoshop in one afternoon.

Oracle's ADF Faces

Adam Winer, from Oracle, e-mailed me late last night and informed me that he had ADF Faces working with Facelets! It was a great test for Facelets and Adam was able to find several bugs pertaining to backwards compatiblity with JSF 1.1. For me, the point of getting ADF operational was to catch compatability bugs. The good thing is that nothing was overly major, except one issue that is somewhat beyond my control.

When JSF loads ViewHandlers from configuration files, there's an ordering issue that could arise between dependencies. Since ADF and Faclets have their own ViewHandlers, Adam had to deal with resolving ViewHandlers outside of JSP. This was probably a good thing to have happen as the integration can only improve both frameworks (ADF & Facelets).

With Adam's issues, I will be filing and correcting them all by the end of the week and doing another (major) release. I'm also working on writing up a series of articles on Facelets for Kito Mann's JSFCentral.com.

I'm somewhat battling with backwards compatibility overall. I don't like having Facelets include if/else checks everywhere to behave differently depending on the JSF API version. No matter what, this can lead to some issues down the road and I will have to cut off JSF 1.1 support and proceed with JSF 1.2. When Oracle releases ADF Faces for JSF 1.2, then I will probably release a JSF 1.1 compatible final and continue on. Most components available extend UIComponentBase, so they will not have any issues with the JSF 1.2 API, they will simple just work.

I'm in agreement with Eugene's comments from my last post that Facelets should stay focused on tree creation and templating. Keep things simple. I would be open to creating a 'contrib' folder within Facelets where developers could contribute TagHandlers specifically for Facelets as a separate build target.

Update

Facelets has been going great. I'm getting lots of great remarks and help from the community. Again, thanks to everyone!

Now that I have a JSF 1.1 compliant version available that can work with MyFaces too, I'm going to concentrate on putting together a 'dashboard' demo application for Facelets to show off some of the features.

Truthfully, I think it will be somewhat difficult to do a proper demo application since Facelets is just a ViewHandler for building trees of JSF Components. So demo'ing an inputSecret component with Facelets really isn't that big of a deal. I'm hoping to also put together some components of my own, but I'm unsure if it makes sense to release them under Facelets when they could be used with JSP or whatever. In any case, I think Adam Winer from Oracle's ADF group was going to start looking at ADF and Facelet integration this weekend.

I will be extending the templating functionality of Facelets too. Currently templating works off of a parent->child relationship. Meaning templating only works one level deep. Soon you will be able to nest templates 5 or 6 layers deep to specify complex layouts. Think of it as extending an Object 3 levels deep and being able to override any method, except we are talking about parts of a document.

Anyways, I'm off to Milwaukee, WI this weekend-- should be a blast, hopefully I don't get hurt :-)