XML is not a Verb

My So Called Blogging Life

I don't know if these postings are timely enough but since I received absolutely no feedback on my last one, I imagine nobody was pounding the refresh button on their RSS client waiting for this one. Actually, how bad a blogger do you have to be when you don't even show up on Google's Blog search? A co-worker of mine started a blog close to the same time and Google happily indexed his pearls of wisdom but, for some mysterious reason, my blog was passed over. Eventually it did show up but I had more than few "Why me?" moments. I plan to take a critical look at my blogging "career" because of this. ;-)

If You Build It, It Will Hurt

On a more technical note, I've been wrestling with several portlet related issues with ICEfaces, particulary trying to get it to run on different portal platforms. For obvious business reasons we want our framework to run on as many platforms as possible. But the larger matrix makes for the typical software challenges in supporting so many different configurations (building, testing, etc.).

Let's start with the builds. Our product runs on a large number of app servers and portal containers. We're currently using Ant as our build tool and have discussed the value of Maven. I have a love/hate relationship with both these tools and I'd really like to have more of a "friends with benefits" relationship. For me I think it boils down to a distaste for programming in XML. I don't mind XML for structured data but with builds I want to be able to *do* something and utilize my koding skillz. I recently went to a Groovy on Grails presentation at my local Java user group meeting and noted that that Groovy guys have done some integration with Ant. Quoting from their site:

"If ever you've been working with a build.xml file or some Jelly script and found yourself a little restricted by all those pointy brackets, or found it a bit wierd using XML as a scripting language and wanted something a little cleaner and more straight forward, then maybe Ant scripting with Groovy might be what you're after."

At this point I'm standing up in my office yelling "That's me!". Now I admit I haven't even looked at how well this works but I think it has the potential to be what I want. Groovy is a real scripting language which allows me to code (with all the pros and cons of a dynamic language) what I want the build to do rather than describe in a tree/node structure what I hope it will do. It's well integrated with Java so I'll be utilizing my existing skills and I can use the full set of Java libraries. I'll be putting it on my "technologies to learn later" to do list. Along with Lego MindStorms.

Beyond the build pain, I've run into a few interesting technical problems with some of the portal platforms themselves but I'm going to save a little something for the next post.

Of ICEfaces and Portals

I don't know how many times I've started a free blog account with the intention of joining the unwashed masses in carving out my own niche on the web. I usually just end up staring at the screen, unable to type because I figure the first blog entry needs to be internet-shatteringly funny/informative/glib/hip/smart. Then I realize I don't have a top 10 list or anything else to catch the attention of millions of people just waiting for the next big thing. So I log back off and go see if I can make my kids do something spectacular that I can write about. Never works.

But now I have some motivation. It's work related so I need to sprinkle some information about what I do, who I do it for, and so on. For those of you not interested in software development, specifically Ajax, JSF (JavaServer Faces), and ICEfaces, please proceed to the next tab on your browser where important galactic events await.

If you are interested in the technical wonders I've mentioned, then I'll provide some background. I'm a Senior Developer at ICEsoft, the company that directs the open-source ICEfaces project. ICEfaces is an extension to JSF (Java's component framework for building web application user interfaces). ICEfaces extends JSF by seamlessly adding support for Ajax. ICEfaces also comes with a swack of components that take advantage of this integration. The benefit to you, the developer (which I have to assume at this point is true since you're still reading) is that you get the Ajax stuff for free. You can develop normal JSF-based applications and the components take care of the Ajax for you - which is what polite components should do.

Now that's all the general stuff, but I work specifically on getting ICEfaces to run in Java portals. If this sounds glamorous and exciting, then this blog may make your day. Maybe not today but eventually. If not, then feel free to excuse yourself and check the next booth where they are showing the fastest and easiest way to change a tire.

I have a lot of potential material about my experience with adjusting ICEfaces to work in portals. Not all of it is good but then again, other people's pain can be entertaining. For now I will mention that we have ICEfaces running, more or less, with Liferay, JBoss Portal, WebLogic Portal, Pluto, and JetSpeed 2. Some of our customers have had some success with WebSphere Portal and perhaps others. If you are in that crowd, add a comment and tell me how it's going.

We're doing our best to support as broad a range of portal containers as possible but it's a challenge. One of the tough things about bringing portals into the Ajax Age is that the portlet specification is very "lowest common denominator". Portal vendors originally had their own proprietary offerings and the act of getting a standard specification together was more of a reverse-engineering exercise by the looks of it. That meant a lot of things weren't specified - which makes an interesting environment to wedge an Ajax framework into.

If you are interested in this stuff, get a conversation started in the comments. If there's sufficient interest, I'll do my best to keep the blogs hot and freshly baked.