Yep. To have Struts take that long to become "legacy" is actually a compliment to how well it addresses the need area it went after. To have it become the underlying knowledge base of the experts building the "standardized" version of the technology is a compliment to the original developers being pretty much on the right track.
Yet, the problem that John addresses here (also known as "The Innovator's Dilemna") is very real. You're told to go build something, and put it up on the web yesterday. It's going to be a mission critical for your company, and will itself have a fairly long shelf life, so you want to make sure that the technologies you base your app on are also going to be around. You look at the available standards-based technologies, and don't see what you need. So, what do you do?
Open source developers (at least the good ones) tend to be pretty innovative, and that was certainly the case with Struts folks (yes, that includes me, and I'm very proud of what my little brainchild has grown into :-). It is not unusual to find that there is an open source package out there. But, is that package going to be around for the lifetime of my own app?
Or, to put it another way, how many open source projects are hosted at SourceForge? How many of them have more than a couple of developers playing around in their spare time? How many of them have been downloaded even 100 times (Struts gets ~75,000 downloads per month nowdays)?
I would submit that the supporting ecology around the technologies you choose (be they open source or not) is likely to be more critical to your success than the particular technical features of the package. It was certainly critical to some pretty large scale companies, and conservative industries, that have adopted Struts quite widely.
Yet, it takes a while for that ecology to grow. And, there's no guarantees that it will *ever* happen. And, while the ecology is growing, the technology at the base can't evolve quite as quickly as it could before (ask all the guys who wrote books on the "moving target" that was Struts 1.1 :-).
It's an interesting balancing act.
The direction of Struts-2 with Commons Chain proves that it can survive the test of time through innovation and specialize in what it does best. Struts committers have that clear vision and focus. I have no doubt that we can continue to enjoy the fruits of Struts community efforts.
JSF scratches many of the same itches as struts, only better, and given that:-)
Craig is spec lead for JSF thats hardly a coincidence. Perhaps we could
consider struts the practice run? ;-)
Craig & co. say that there will be a future for struts in the JSFKeep in mind that the existing struts-faces integration library isn't finished yet (since JavaServer Faces isn't finished yet). But it will be.
generation, but Im not sure I fully grok what that future is yet (havent had
a chance to play with the jsf struts integrated stuff yet) but at the least
it should involve an upgrade path for existing struts stuff?
To the broader question, I would definitely say there is a future for Struts. Here's a quick summary of some things on my mind:
* Part of the ecology of a successful open source project is staying up with the times, offerring new things to your existing customers. After all, there are many thousands of Struts based applications aready in existence -- and nobody is going to rewrite them all in the next couple of days, or even the next couple of years. Therefore, Struts needs to continue to support its existing features and functions, and add new ones.
* Particular areas of future growth I'm interested in (other developers have their own thoughts as well):
- Enable existing Struts-based applications to utilize new view technologies (like JavaServer Faces) with zero changes to their back-end business logic (isn't that one of the things we all like about MVC type designs? :-).
- Make Struts equally useful in both a servlet and portlet (JSR-168) environment.
- Refactor the insides of Struts so that the basic principles of "separation of concerns" can be used for "scripting" your back end business logic, interacting with XML data sources and outputs, and so on.
These are some key features to make Struts survive the test of time.
BaTien DBGROUPS
If we were just going to stay where we are, I'd be worried about the future of Struts (although, even if all development stopped tomorrow, there's too many people using it today for such a vacuum to exist for very long -- someone else would take up the gauntlet).
Sadly, I don't have time at the moment to comment further ... maybe later, after putting in some "day job" hours :-).
Craig
I
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
