The blueprints are back, The Petstore is back and Google smashes them exactly one hour later. What I’m talking about? This morning Sun did a presentation of their new Blueprints for Web 2.0 (sorry, it is not my choice of words) Applications. And to support their technical vision (what else is a generic blueprint) they reincarnated their Petshop. A lot of Dojo based bling bling, a lot of not easy to understand javascript and of course JSF. I also attended a session by Bruce Johnson and Joel Webber, both from Google, who presented their vision and their tool support for AJAX applications. Two complete different visions, two complete different worlds. Sun’s vision is all about their standards (JSF, EJB3), Google’s vision is focused on the regular web developer who do not understand the hairy javascript constructions needed to get a fancy interface. Sun’s vision does not look at the end-user experience at all (that is up to the developer). Google instead gives the developer the right instruments to support seamless end-user practice.
Google’s web toolkit has shown the light only one day ago and the blog-o-sphere is already filled with articles explaining what it is and what it does. So I’m not going into details (yet again standing behind a conference terminal and my back starts hurting) but I was pretty impressed by their innovative approach (They compile Java code into javascript!), their support for browser history aware ajax applications and their support for RPC (not only java based, in theory you can define the UI using Java, compile it to javascript and provide a PHP backend for service calls). The only practical problem I found after a quick scan through their website is the way they licenced the stuff. The javascript widget libraries are open source (apache based) but the actual compiler is as closed as an unlockable safe deposit box.
Of course, I’m writing this down just a few minutes after their marvelous act so the presented material still needs to land down smoothly in my java wasted brain but I’m already under the impression Sun’s blueprints might need a complete refresh.
Yesterday I visited a session by Jetbrains Dmitry Jemerov about IntelliJs’ new product called teamServer (TS-5033 : IntelliJ IDEA: Integrated Team Environment) and I really was flabbergasted by the presented material. 
Everybody knows Continous Integration is a must have in your projects and everybody also knows Continuous Integration does not work or at least does not work the way we really want it to work. TeamServer might change this. They developed it to support their own development. In other words, the developed it from the perspective of the developer (they eat their own dogfood), not the perspective of a company whos only core activity is building A continuous integration product. And just as their famous IDE(A), this product is stuffed with a lot of intelligent features that make life as easy as possible. And these features are making the difference.
One of the most remarkable features is the way they treat the check-in process. Instead of just checking-in code into the underlaying revision system, the tool is performing a build and test cycle first. So only changes that pass this phase will be added to the shared code repository. It is impossible to break the build. (Question, how many times did you do a check out of the code base and figured out the build was broken and the person responsible for this has left the building?)
Other interesting features are the way Team Server integrates with your IDE. No more bloats of email messages you never are going to read but instead nice taskbar indicators and direct pointers from (your own, not someone else’s!) build problems to actual source code. As expected the integration works for their own IDE only but there are plans to make it available as Netbeans and Eclipse plugins.
Besides the continuous integration aspects, the tool is featuring collaboration between developers also. For example, It is possible to do a diff action between your code and your coworkers code who’s sitting at the other side of the room (or worse, at the other side of the world) without using cumbersome mechanisms like e-mail or even worse, check-in/check-out.
Of course I need the proof of the pudding first but I think its worth to take a look at the the Team Server early access program site and try it.
So what if you want to develop a rich portal application, let’s use the standards!
Standards are their to make live easy for you, right…..? 
I want to create a Portal application with a rich and easy to build interface, this leads me to the following standards JSR168, the portal standard and JSR127 the JavaServer Faces specification. First of all I want to find a portal that supports this standard and does not provide to much overhead. This lead me to the JSR168 Portal Jetspeed (http://portals.apache.org/jetspeed-1/). Jetspeed 1 also provides support for JSR168 under the codename Jetspeed Fusion.
Yes there are other alternatives like Exo and Liferay that do the job but these provide to much overhead for my “simple” requirementSo the most important step is done I found myself a suitable OpenSource Portal with JSR168 support. Now we need to install it and as always Apache provides a out of the box solution including Jetspeed and Tomcat 5.0.3. The next step should be easy we need to create a rich JSR168 portlet application using JSF technology. In my opinion this should be as simple as 1.2.3. We just need to include the JSF jar into your project and start developing the portlet following the JSR168 API. After that we can just create a war-file which will be automatically deployed by Jetspeed.How wrong can one be, standards are not their to work with each other out of the box one must create a bridge for these two standards to work together. In this case I need to use the Apache Portals Bridges project ( http://portals.apache.org/bridges/ ) for these two standards to work together. The bridge consists of a generic Portlet-class which forwards your actions according to your configuration in the portlet.xml. All in all it’s not the work that triggers me but the bridging method, is this also based on any standards?? Or will we have to build bridges to support bridges?? So why do we need a non-standard bridge, which by the way impacts your flexibility to code portlets, to couple two standards? Aren’t both standards all about presentation? And why isn’t the JSF standard not supported by JSR-168 (or the other way around)? JSR-286 seems to make some promises about a tighter integration but besides to late, it is still a long way to go.So, until then we’re struck with bridges and our history has learnt us how dangerous bridges can be 
