Nitin has posted 391 posts at DZone. View Full User Profile

Leaving Woodstock – ICEsoft Provides Migration Path for RIA Developers on NetBeans IDE

  • submit to reddit
While Sun recently abandoned support for Project Woodstock, an open-source JSF component repository launched in early 2007, love and peace may still reign for NetBeans users as they look to migrate their Woodstock applications to ICEfaces. 

ICEsoft technologies and the NetBeans community this week jointly announced a new migration path for existing Project Woodstock applications to ICEfaces, an open source Ajax framework for building and deploying rich, JSF-based applications.  Earlier this month, the ICEfaces community celebrated the one millionth download of the framework in less than two years.  

With the latest ICEfaces plugin for NetBeans IDE 6.5 (available here), it is now possible to add the ICEfaces framework to an existing Woodstock project, and begin to develop ICEfaces pages along side existing Woodstock pages.  To this end, ICEsoft has also assembled a Component Migration Matrix to aid in the mapping of Woodstock components to ICEfaces. 

In his blog, ICEsoft CTO Steve Maryka highlighted the runtime integration that ICEfaces has long offered for the Sun Glassfish server and emphasized this week’s announcement as a major integration milestone on the development front --

“… we have always strived to integrate with the Sun IDE of choice. Our efforts started with Java Studio Creator, and have continued with several releases of NetBeans, up to our current integration with NetBeans 6.5. Because Woodstock has been a primary consideration in the NetBeans JSF strategy, integrating ICEfaces into this model has been a major challenge, but we have succeeded in delivering both Visual JSF and Facelet support for ICEfaces in NetBeans.”

The latest release of ICEfaces is available here and includes:

  • NetBeans 6.5 project-level coexistence of Woodstock and ICEfaces. The ICEfaces NetBeans plug-in can be downloaded here
  • Automated addition of ICEfaces framework into existing Woodstock projects
  • Run-time framework integration supporting coexistence of Woodstock and ICEfaces pages in a single web application
  • Preliminary documentation including aWoodstock to ICEfaces Porting Guide , and the Component Migration Matrix
  •  User support through ICEsoft’s public Woodstock Forum

To learn more about developing Ajax applications with JSF, visit the DZone JSF & Ajax resource center. 
Published at DZone with permission of its author, Nitin Bharti.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Andy Gibson replied on Thu, 2008/12/18 - 1:40pm

My understanding of things, which may be quite out of date regarding JSF + Netbeans, is that the real problem is how Netbeans has approached the whole issue editing JSF pages. Despite JSF being a standard, the visual editor required the application, in particular the backing beans, to take a particular structure in order to work with the editor. If they had taken a more generic approach, i.e. one that followed the standards only, then developers could install any kind of jsf component framework and use the editor without any problems.

The only requirement the Netbeans JSF editor should impose is needing a plugin for the editor to be made aware of backing beans from different frameworks (i.e. Spring, Seam, Spring Web Flow) for code completion of El Expressions (like some kind of design time variable resolver). Beyond that the editor should be able to use any jsf components installed on pages that hookup to arbitrary backing beans that don't require specific hierarchy. The editor itself should be nothing more than a JSF editor that uses the plugins to determine El expressions for code completion. 

 I may be wrong, and that may be where netbeans is, I would be delighted to be wrong and find that Netbeans supports plain jsf editing with El auto completion for spring beans etc..However, I would prefer a more generic JSF editor which might not have so many complex functions built against one framework than one with deep integration that is very restrictive on what and how I can develop.

It seems this news means that the netbeans team have bound themselves (and their developers) to Icefaces this time instead of  Woodstock.


Stephen Maryka replied on Thu, 2008/12/18 - 6:14pm in response to: Andy Gibson

Yes, you are basically right about how NetBeans implements Visual JSF Design.  Essencially a renderable shell of a JSF application, including backing beans, is constructed as you drag and drop components onto the page.  To get ICEfaces to work with the NetBeans visual editor it was necessary to mimick the approach.  I agree that it has it's limitations.  The main advantage is you get close to WYSIWYG editing using this approach because the JSF components are actually rendering into the page.

 That being said, it is not necessary to use Visual Design in Netbeans to build applications.  You can use ICEfaces in a non-visual project that eliminates the dependencies.  You can also use the Facelet editor with ICEfaces, so you do have choices if visual design is not your preference.  We highly recommend the Facelet-based approach to build JSF and ICEfaces applications.


Edem Morny replied on Fri, 2008/12/19 - 12:06pm

I think the point that Andy is trying to drive at is that with Visual JSF, you can't eat your cake and have it. You get a WYSYWYG designer, but u get tied into Sun's "Rave" framework, or you hack it using the facelets plugin and have the independence to choose the framework to work with (Seam, Spring, Spring WebFlow, basic JSF etc). Replacing Woodstock with ICEFaces doesn't solve the problem, unless the ICEFaces support is detached from any particular framework.


It's so difficult to get a good tool to do visual design of JSF applications (based on Facelets i mean) without being tied to a particular framework (or forking huge money for it). ICEFaces should learn from the JBoss RichFaces VPE project, which provides JSF and RichFaces WYSYWIG without the tie-in. Although it's from JBoss and therefore supports seam better, I'm currently using it with Spring Web flow and I couldn't be happier.

Andy Gibson replied on Fri, 2008/12/19 - 10:06pm

Yes, thanks, that's what I was referring to. I'm mostly using Seam with JBoss Tools right now, and there is a great deal of difference between the JBoss Tools JSF stuff and the Netbeans JSF editor. I don't really see why there needs to be any kind of tie-in as it would seem to be more work to create a highly integrated jsf editor than one that could be used with any framework (Seam/Spring/pojo backing beans). I supposed they were going for the type feel with page events and automatically binding the components to the component references in the backing bean.

The JBoss Tools are a great example of how decoupled a JSF editor should be from a framework. Sure, it is tied to Seam, but not tightly. I would imagine that the only missing piece to get it working with Spring would be a design time variable resolver to offer suggestions for spring bean names and validators to check for errors.

I personally don't care too much about the WYSIWYG aspect, I use it as a rough guide to see if things are in place, but apart from that I'm more interested in writing by hand and using good code-completion to help with typing bean names and properies (helps reduce typos). 

 How are you finding JBoss Tools with Spring Web Flow? It's been a while since I used to two together, but I'm looking at starting a new project with it, so I'm curious if there are any good advances in Spring + Web Flow + JSF tools?


 Andy Gibson

Edem Morny replied on Mon, 2008/12/22 - 5:32am in response to: Andy Gibson


How are you finding JBoss Tools with Spring Web Flow? It's been a while since I used to two together, but I'm looking at starting a new project with it, so I'm curious if there are any good advances in Spring + Web Flow + JSF tools?



Just like you mentioned, the design time variable resolver for Spring is the only missing thing in JBoss Tools. But I think I could live with that. Most people starting a project with JSF are likely to either use Seam or Spring Web Flow. It is in the interest of JBoss Tools (and especially Richfaces) to provide Spring web flow support also out of the box. That will be the real bomb :-).

Rainer Eschen replied on Sat, 2009/01/31 - 8:20pm

The Excadel stuff that is part of the JBoss IDE now is pretty good in integration other JSF frameworks. But, today the most editors lack of a runtime rendering concept that allows to get a real preview. The combination of frameworks can be quite complex. So, only certain frameworks get a real support for this.

Netbeans still use the ideas of the Sun Java Studio Creator. When I used the Creator I thought "Hey, that's a little bit like in the old Delphi days", but the layer underneath was not acceptible. Bound to such complicated stuff was a no-go for our projects. We tried to adapt things, but it was too time-consuming to find a solution. 

 The AJAX to JSF bridging in Woodstock was really annoying and a maintenance hell right from the beginning. After developing a prototype we gave up the idea to implement with it. Some month later ICEfaces became Open Source. We're still quite happy using ICEfaces:

Icy Faces for more than a year

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.