This is my impression of Avalon and Fortress. I would be hard pressed to back it up in fact at this point in time. Take it with a grain of salt.
(last comment for me.... I am having too much fun. I gotta get back to work! This time for real. I am working from home. ) -----Original Message----- From: Richard Hightower [mailto:[EMAIL PROTECTED] Sent: Monday, January 10, 2005 12:46 PM To: jug-discussion@tucson-jug.org Subject: RE: [jug-discussion] Spring FUD is confounded RE: It lives on in the various ways it has spun off: http://avalon.apache.org/closed.html So its underpinnings are still quite viable. Good luck pitching a project with such a ringing recommendation as it live on in many forms... It would be quite hard to convince a decision maker of such a thing as Avalon, given the perception of its recent history. Yes bias sucks. But it exists. Pico, Avalon, and more live on in that they have influenced Spring. Given Springs track record and that of Pico and Avalon, it would be a bit silly to pick them for a new project in my opinion over Spring. Unless they evolve quickly. HiveMind is a given if you are using Tapestry (at some level). You can use tapestry, Spring and Hivemind on the same project. JSF comes with its own IoC container. You have to use it at some level. You can use JSF, and Spring on the same project. (last comment for me.... I am having too much fun. I gotta get back to work!) -----Original Message----- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Monday, January 10, 2005 12:22 PM To: jug-discussion@tucson-jug.org Subject: Re: [jug-discussion] Spring FUD is confounded 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
