Looks like I've been biled again. Unlike the last time, this time Hani doesn't offer any specifics, he merely says that my OSS efforts don't do anything other than the "very very basics".
Java, specifically, goes a long way towards ramming down a set of design principles. Said principles are followed fairly blindly by most practitioners. The OSS world is awash with examples of people who have read the right books, but have absolutely no skill or talent at conceptualising or grokking the underlying principles behind the books. To them, the design pattern is an end goal, not a tool. To pick one example (out of thousands), look at Matt Raible's OSS efforts. It has inheritance! It uses PATTERNS! It is LIGHTWEIGHT! Yet, I'd argue that it's very badly designed (if you don't believe me, just try getting it to do anything other than the very very basics.)
I'm assuming that Hani is speaking about AppFuse and Equinox, because my other efforts in OSS are minimal (Roller, Display Tag, XDoclet and Struts Menu). The reason I'm writing this post is because I'm curious to know what Hani tried to do that didn't work? Was it AppFuse/Equinox that failed? Or was it the underlying framework? Did he try to do indexed properties with WebWork or modify build.xml to deploy to Orion? Is the feature he's looking for something we can fix?
As a defense of my use of patterns, lightweight containers, etc. - it's not so much my doing that these happen to exist - they're more of a reflection on what user's want. It's a problem with Java developers in general - if you're not using patterns - users want to know why. Furthermore, most of the J2EE patterns in AppFuse are from the underlying frameworks, not from anything that I did.
As far as the design of AppFuse, I agree it could use some work. There's a lot of stuff in AppFuse that I don't use - so when I start a project with it - I usually rip out about 20-30% percent of it's features b/c I won't use them. Unfortunately, it's not that easy for others to do this b/c they don't know what they'll break if they remove a bunch of stuff. I'd like to move to a more modular, plug-in type architecture - but I have a feeling that that's the path to over-engineering. Even so, it would be pretty cool if it was possible to turn on/off features (even the use of a particular web framework) by changing a properties file.
What is it about WebWork that makes it so hard to write books about? I remember talking to Kris Thompson (a.k.a. the guy that quit blogging) last summer about WebWork in Action. At that time, it was "almost done". Over a year later and it's still "due out next month" (or is it done?). Almost as bad is Matthew Porter's WebWork Live, which was started late last year. I remember Matthew saying he expected to finish the initial version in March - and there's still not an ERP almost 10 months later.
Here's my guess: the Manning book has been done for months, but the publishing process takes months. As for Porter, my guess is he's too busy providing outstanding support at Contegix to work on the book. Any good conspiracy theories out there? Maybe WebWork has too many patterns that need to be documented? 
