|
From: Tim C. <tc...@ta...> - 2004-04-06 21:57:33
|
I know that I'm new to the Spring world but just to make another note on this subject. Anyone that is on the Struts dev list can tell you that the latest release of Commons Validator has been a huge sticking point in the release of a new Struts version. I don't want to see the same thing happen to Spring as to XDoclet neither as though on THAT list can tell you. XDoclet has 10million dependencies (ok.. I exaggerate.. 999,999 dependencies) and most of them are broken which results in a XDoclet2 that does not build out of CVS. VERY VERY aggrevating. Can I make a suggestion and vote to take a page from Maven's book? Let's create a Spring-Plugin project of these "add-ons" they never have to get mixed with the main code and the main code will NEVER have to break due to breakages in the plugin's dependencies. Even with this course the developers should still be careful what goes into the core of course. XDoclet 2 came up with that same architecture but unfortunately it's own core was tied too closely with other *currently* broken packages. -Tim Rod Johnson wrote: >Guys > >We are aware of the dangers here. We do not want Spring to become bloated, >and it won't. > >So far we have the following strategies: > >- ** Keep the core separate from the add-ons ** E.g. the IoC container >doesn't >even depend on AOP, let alone Commons Validator/whatever. This means that >it's possibly to use say the BeanFactory or JDBC without extensive >dependencies: indeed, the whole of Spring (except integration) without >extensive dependencies. >- Keep the focus of the core developers on the core. >- Set the bar high in terms of the quality of what we accept. This is one >argument for keeping commonly-used add-ins in the Spring project. >Let's suppose we don't address integration with a popular product such as >Quartz. Several Spring/Quartz libraries then emerge, all but one of them >bad. Now users are confused and it reflects poorly on Spring. >- Ensure that the correct message gets out. Marketing is important. We must >ensure that people know that the core doesn't depend on the extensions. > >However, I think this thread does show that we need to be careful in >accepting too many add-ons into the core. Perhaps we could have an add-ons >project for the second tier of integration: e.g. Hibernate is obviously >core, Commons Validator could be shipped along with a Spring addons >distribution, but which is still under the Spring Framework umbrella. Such >integrations likely to be used commonly are definitely in a separate >category from integration with highly specialized products, that are >unlikely to see wide use. And we can always promote code into Spring proper. > >Perhaps all integrations could start off in the add-ons project, and only be >promoted if there's user demand. > >Regarding documentation, good point, we should separate out the core from >the add ons. Maybe 2 volumes of the reference manual. Also perhaps we should >provide a section on the web site helping users to understand what they need >to understand. This could be geared to real user situations, like "web >development with Hibernate", "looking for a replacement for SLSBs", "looking >for quicker/easier JDBC". > >Regards, >Rod > >----- Original Message ----- >From: "Baum, Karl" <Kar...@Ta...> >To: <spr...@li...> >Sent: Tuesday, April 06, 2004 4:33 AM >Subject: Re: [Springframework-developer] RE: commons-validator adapter > > > > >>It's great that Spring offers a developer so many options, but after a >> >> >while > > >>it may be difficult to separate core Spring from the convenient add ons. >>What must a developer read up on before he or she understands what spring >> >> >is > > >>really about? I would tend to side towards IOC, AOP, and the BeanFactory >>before the commons validator plugin, but this does not mean a commons >>validator plugin is not a great idea (I for one am trying to integrate it >>into my current project.). Each plugin that is integrated directly into >> >> >the > > >>project is yet another responsibility for the community of Spring >> >> >developers > > >>when it comes to documentation and maintenance. This documentation, with >>all of the add ons and plugins, will eventually become so bloated, the >>average developer may become overwhelmed by it's size and complexity. >> >>Why not farm these plugins out to smaller subprojects with teams of >>developers focused on delivering a specific add on to the Spring project. >>This leaves everyone with all of the great Spring options, but in the end >>the Spring Framework never loses site of it's purpose This isn't just >> >> >about > > >>the commons validator project. With each new popular open source >> >> >component, > > >>we will need yet another package checked into the Spring project. We can >>start now with the spring-commons-validator subproject. >> >>----- Original Message ----- >>From: "Brandon Goodin" <ma...@ph...> >>To: <spr...@li...> >>Sent: Monday, April 05, 2004 10:08 PM >>Subject: RE: [Springframework-developer] RE: commons-validator adapter >> >> >> >> >>>I understand that. I'm simply saying... leave the choices on other >>> >>> >>websites >> >> >>>and focus on what spring is. Not on all the neat toys you can plug into >>> >>> >>it. >> >> >>>So, where do you draw the line on what does and does not get included. >>> >>> >Why > > >>>not setup a directory of tools that can be used in spring instead of >>> >>> >>feeling >> >> >>>compelled to include support for every permutation into the distro or in >>> >>> >>the >> >> >>>spring cvs. Just cuz you can doesn't mean you should. I think moves like >>>this will cause confusion around spring not help it. >>> >>>B >>> >>>-----Original Message----- >>>From: spr...@li... >>>[mailto:spr...@li...] On Behalf >>> >>> >>Of >> >> >>>Seth Ladd >>>Sent: Monday, April 05, 2004 5:29 PM >>>To: spr...@li... >>>Subject: Re: [Springframework-developer] RE: commons-validator adapter >>> >>>Brandon Goodin wrote: >>> >>> >>>>commons validator? gack! Don't pollute spring with all of this crap. I >>>>don't want to see spring turn into the 8000 pound gorilla that struts >>>>has. Please consider making this stuff peripheral. >>>> >>>> >>>A nice aspect of Spring is that it attempts to give developers different >>>choices for a particular task. For validation, commons-validator is >>>just one choice. Other choices include metadata validator or >>>programmatic validation. IMHO, the commons-validator fills a nice >>>niche: when you want to do declarative validation but can't mark up the >>>source code (if, for example, you're using generated source or 3rd party >>>classes). >>> >>>With Spring, you get to Pick and Choose! >>>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 >>> >>> >>> >>> >>> >>>------------------------------------------------------- >>>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 >>> >>> >>------------------------------------------------------- >>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 >> >> >> > > > > >------------------------------------------------------- >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 > > > |