|
From: Brandon G. <Bra...@pl...> - 2004-04-06 18:59:18
|
Let me be very clear. I have no problem with people writing plugins. I'm not saying we should limit options. That is silly. What I am saying is that keeping the choices more cleanly separated is of greater importance. As the Spring community grows and compelling and useful products become available are we going to include them all into spring? Wouldn't it be better to separate them out beyond the spring-*.jar files and allow for developers to assemble their needs. I don't see how what I am suggesting contradicts or compromises any of what you guys are saying. I think the linux model is very compelling. Make the Spring core it's own product, make the MVC it's own product, make the ibatis support it's own product, etc... This is not a difficult concept and it is being used quite successfully. I think this would be a better move towards the scalability of the Spring community. What is the philosophy that draws the line with what is and is not part of Spring? In my opinion that line needs to be drawn a little further back than it currently is. Take a look at the pear.php.net project or the gentoo.org linux distro or eclipse.org. All of these focus on a core and provide extensions/plugins to the core. All are wildly successful. So, what is the compelling argument to do otherwise? So far everyone one has simply been restating shared goals not really explaining why they prefer the all in one approach of distribution. Brandon Goodin >>> se...@eh... 4/6/2004 12:15:48 PM >>> Peter den Haan wrote: > The Spring core supports JDBC, iBatis, JDO and Hibernate data access > technology. It supports Hessian, Burlap, JAX-RPC and RMI remoting. I don't > think any of this has proved to be a problem. It supports JSP, Freemarker > and Velocity, and I can't remember anyone asking which was the "official" > spring view technology. Aren't we fighting windmills here? > > I must admit that I find the Apache Commons validator an infuriating product > because it is pretty good in some ways and absolutely horrible in others, > and I would look forward to a clean, flexible and pluggable native Spring > solution. Until then it seems to me that a validator adapter fits entirely > into the Spring philosophy as it stands. Just wanted to put my support behind this statement. To me, Spring's advantage is that it's engineered so well that many different implementations can plug into it. It gives the developer (me) a choice. Everything's behind a nice set of interfaces, and I have never felt that a technology is integrated poorly. As long as a particular implementation doesn't impose its whim on the core Spring design, I will always welcome the amazing integration and choices offered by Spring. Seth ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |