On Jan 10, 2005, at 12:54 PM, Richard Hightower wrote:
Regarding Erik's opinions: As far as Spring vs. HiveMind, Pico container,
Avalon, etc.
HiveMind is nascent and not nearly as mature.
Quite true, however it is "mature" in that it has evolved from Howard's mulling over the Tapestry architecture for years. Tapestry is a micro-container internally, and HiveMind has evolved from it. Tapestry has been out long before Spring came onto the scene. But, your point is taken (even with a grain of salt on this one :).
Pico is not much more than an IoC container from what I can tell.
Which may be all someone needs. Again, none of these are "the" solution, and I know you agree with that.
Avalon is dead. Discontinued. Gone. Poof!
It lives on in the various ways it has spun off:
http://avalon.apache.org/closed.html
So its underpinnings are still quite viable.
Spring is an IoC container, and an AOP framework. It goes well beyond that
and creates a mass array of utilities to simplify developing with JDBC, JMS,
JMX, Hibernate, EJB (yes you heard me... I said it helps with EJB), etc.
At this point in time, Spring wins out in maturity and features.
But, we must choose our tools based on the problem we're solving, the skill-set we have at hand, and a number of other considerations. Spring is not necessarily the winner based on all the criteria. That being said, I've got no problem with Spring at all. I just like playing devil's advocate - someone has to take up for the underdogs.
(This does not mean that I am advocating only Spring. I would be happy to
work on a HiveMind only project. I have no problems with trying new things.
Right on.... and this is the main point I think Randy and I were also making. Be pragmatic first and foremost.
Spring is a pneumatic pump with attachments for screw driving, bolt cutting,
hammering, etc.
Given that it is all of that, I think this is where some of the risk comes in. It may be too big for some situation. If you only need IoC, it's a lot to bite off. If you only need AOP, what's wrong with AspectJ? And a 13MB download for a little ol' IoC container? Good grief!!!! And that is for the version *without* dependencies.
I like the word "complexity" over the word "risk". Is it more complex for me to add Spring into a small application rather than simply implement an abstract factory myself keying off a properties file for configuration information? In a larger application where this configuration file will be enormous, the needle swings back the other direction with the complexity of the application itself outweighing the complexity of the configuration.
In other words - be pragmatic. Period.
If you are developing web apps, I feel it very wise to look into Spring for
the backend to augment your investment in J2EE.
And to be play both sides of the discussion - I concur with this statement.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
