Menu
▾
▴
springframework-developer
|
From: Larry M. <Lar...@pl...> - 2004-04-06 16:04:51
|
I tend to agree with Bradon on this. Look at the success of OS tools like linux, eclipse, and netbeans - the reason these are so powerful and widely used is not because the include everything, but because they CAN. When you get a linux distro, it comes with the ability to easily include any of several flavors of logging or cron, not just vixie-cron and metalog (unlike it's leading non-OS counterpart which comes as a 3000 pound gorilla). Why? Because the people developing and distributing linux understand that both ease of use *and* weight are important to their user base. I hope that the same can be said for the spring team. Larry |
|
From: <jue...@we...> - 2004-04-06 22:42:19
|
Brandon, all,=20 That's a tough issue: It is far from trivial to decide whether to keep = third-party integrations within the core framework. We currently focus = on a quite extensive main project whose packages are strictly decoupled = despite being in the same source directory. Our current strategy of = providing both a spring.jar and fine-grained individual jar files has = received very positive feedback. A completely different strategy can be seen at Jakarta: Everything's a = separate project there. Have a look at Commons: 28 individual components = with separate distributions, plus 20 more in the sandbox. Commons seems = to become a collection of largely unrelated utilities, some of them with = hard-to-see cross-dependencies. The quality of concepts and = implementations varies widely. I guess that Spring cannot really be compared with Jakarta Commons in = that respect: Its vision is much more focused, even if covering a broad = field and numerous third-party integrations. Most importantly, Spring's = implementation is pretty consistent: We try very hard to apply similar = patterns and reuse other parts of the framework wherever we can. This is = much easier within the same project, when the affected class versions = definitely match. I guess hardly anyone will argue that *all* third-party integrations = should be moved outside the Spring core. JTA, JDO, Hibernate, iBATIS SQL = Maps, JavaMail, JSTL, Velocity, Commons FileUpload, etc are all = well-placed in the main project, I assume. Tiles and FreeMarker = integrations are debatable but IMO still candidates for the main = project: Where to draw the line? Why include Velocity integration in the = main project but not FreeMarker? This is also related to the current Struts Spring integration = discussion. Where do such integration classes naturally fit: in Struts? = in Spring? in a separate project, like the Struts Spring Plugin? Each = separate project increases the number of jars to combine for typical = applications, with matching dependencies... Particularly if the = integration code is very small, there is a point in *not* making it a = separate project, IMO. Juergen=20 -----Original Message-----=20 From: spr...@li...=20 [mailto:spr...@li...]On Behalf=20 Of Brandon Goodin=20 Sent: Tuesday, April 06, 2004 5:18 PM=20 To: spr...@li...=20 Subject: [Springframework-developer] Keep Spring Focused WAS:=20 commons-validator adapter=20 Here is a summary of the previous threads that lead up to this = discussion.=20 Please read an comment.=20 --- Brandon Goodin Mon 4/6/2004 ---=20 Do what you like. But, these are the same kind of near sighted arguments = I've heard from the Struts group over the last 2 years. If you provide=20 integrated support for commons validator NOW people will grow to be used = to=20 it as "the Spring" solution. Then when you introduce the "real" Spring=20 declarative validation you will have competing products within the = framework=20 creating confusion. If commons validator is NOT going to be the = "official"=20 Spring declarative validation then keep it OUT of the core distro. I do = not=20 believe you are keeping focused in doing these type of things. You CAN=20 support things and help to keep them focused WITHOUT making it part of = the=20 core. Use a little collaboration for goodness sakes.=20 Brandon=20 --- Keith Donald Mon 4/6/2004 ---=20 Spring to me is about making it easier to build real applications = quicker.=20 Since most applications (mine included) demand syntax and semantic=20 validation of business objects, I would argue a good declarative = validation=20 framework managed by the Spring team is a good fit. Personally, I don't = think commons-validator is that answer for us long term. I think we can = offer better and do so in a "cleaner" (more true Spring) fashion, and = that's=20 the focus of the 1.1 declarative validation efforts. However, we = recognize=20 a substantial number of people out there already have an investment in=20 Struts/commons-validator--thus for us to provide a _thin_ adapter for = it=20 that facilitates integration with the rest of Spring helps those people. = And taking responsiblity for managing that piece helps ensure it stays=20 consistent with the rest of the framework in terms of quality (including = documentation and test coverage.)=20 So my point is when I see that the Spring team has taken responsibility = for=20 an area and put their name on it, that says something about its quality: = that is, that it is useful for one (it addresses a need, is documented, = is=20 tested), and that it will be managed and supported carefully over time. = Rod=20 and Juergen are not going to move something out of the sandbox into the = core=20 and into a release without first making sure it's ready and there is a = real=20 need for it, for example.=20 We wouldn't want the emergence of a ton of decentralized Spring sub = projects=20 to produce a sourceforge-like effect over time--that is, a lot of = projects=20 that are inconsistent in terms of support-level/documentation/activity, = etc=20 (and personally I prefer Spring as my one-stop-shop, reducing the = headache=20 generally associated with managing technology integration [even then = though,=20 it's still modular...]). Please note this is not to say subprojects = that=20 leverage Spring are a bad idea! Heck no, just look at the new Acegi=20 Security Framework, for example! There just needs to be a separation=20 between _what is_ Spring and what is a _separately managed_ project that = builds on Spring.=20 I agree we don't need a million validator options, and we should say = "no" to=20 things that aren't a good fit or don't address a clear, substantial user = need. So again the goal here is to allow those already with an = investment=20 in commons-validator or Struts a way to easily integrate it with Spring. = The adapter is to be quite thin and optional and there for people = wanting to=20 use Spring but also needing it. Long term, I'd like to see everyone = using=20 our own declarative validation stuff that we're working on now, because = we=20 feel we can offer something better and with some unique capabilities. = But=20 it's not ready yet (and even if it was people can't be expected to = migrate=20 everything on a dime, right?)=20 Keith=20 --- Brandon Goodin Mon 4/5/2004 ---=20 This is exactly what I mean. Thanks Karl. I hope developers of Spring = take=20 what Karl is saying to heart. To me this is vitally important in keeping = the=20 reality and perception of Spring light and focused. I would hate to see=20 Spring suffer from what Struts suffers from... "fascination with = gadgetry"=20 or BSOS (Bright Shiny Object Syndrome)...distraction from what is = important.=20 Any developers reading this?=20 Brandon=20 --- Karl Baum Mon 4/5/2004 ---=20 It's great that Spring offers a developer so many options, but after a = while=20 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=20 really about? I would tend to side towards IOC, AOP, and the = BeanFactory=20 before the commons validator plugin, but this does not mean a commons=20 validator plugin is not a great idea (I for one am trying to integrate = it=20 into my current project.). Each plugin that is integrated directly into = the=20 project is yet another responsibility for the community of Spring = developers=20 when it comes to documentation and maintenance. This documentation, = with=20 all of the add ons and plugins, will eventually become so bloated, the=20 average developer may become overwhelmed by it's size and complexity.=20 Why not farm these plugins out to smaller subprojects with teams of=20 developers focused on delivering a specific add on to the Spring = project.=20 This leaves everyone with all of the great Spring options, but in the = end=20 the Spring Framework never loses site of it's purpose This isn't just = about=20 the commons validator project. With each new popular open source = component,=20 we will need yet another package checked into the Spring project. We = can=20 start now with the spring-commons-validator subproject.=20 --- Brandon Goodin Mon 4/5/2004 ---=20 I understand that. I'm simply saying... leave the choices on other = websites=20 and focus on what spring is. Not on all the neat toys you can plug into = it.=20 So, where do you draw the line on what does and does not get included. = Why=20 not setup a directory of tools that can be used in spring instead of = feeling=20 compelled to include support for every permutation into the distro or in = the=20 spring cvs. Just cuz you can doesn't mean you should. I think moves like = this will cause confusion around spring not help it.=20 Brandon=20 --- Seth Ladd Mon 4/5/2004 ---=20 A nice aspect of Spring is that it attempts to give developers different = choices for a particular task. For validation, commons-validator is = just=20 one choice. Other choices include metadata validator or programmatic=20 validation. IMHO, the commons-validator fills a nice=20 niche: when you want to do declarative validation but can't mark up the=20 source code (if, for example, you're using generated source or 3rd party = classes).=20 With Spring, you get to Pick and Choose!=20 Seth.=20 -------------------------------------------------------=20 This SF.Net email is sponsored by: IBM Linux Tutorials=20 Free Linux tutorial presented by Daniel Robbins, President and CEO of=20 GenToo technologies. Learn everything from fundamentals to system=20 administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck=20 _______________________________________________=20 Springframework-developer mailing list=20 Spr...@li...=20 https://lists.sourceforge.net/lists/listinfo/springframework-developer=20 |
|
From: Rod J. <rod...@in...> - 2004-04-07 19:16:35
|
OK, I think we have 2 dangers: 1. Spring.jar gets to 2Mb, reference manual is 600 pages. Although the design remains clean (IoC container doesn't depend on integrations etc) users get confused and think Spring is complex and bloated. Even though t= his would arguably be a misconception, I don't want to spend my time arguing about it. 2. Component hell. Jakarta Commons is terrifying. In this dystopic vision= of the future, Spring ships as 27 Jar files. You need 7 to integrate with Quartz, 6 (3 of them different) to integrate with Struts. Personally I us= e spring.jar in almost all cases, and hate having to manage numerous Jar dependencies. I favour a fairly simple solution to plot a safe course between, based on the following approach. - No componentization of what's been released in Spring 1.0 so far. E.g. = I wouldn't favour making FreeMarker or Velocity extensions. After all we do offer different Jars already. - One or at most 2 "Spring add-ons" projects, covering a range of technologies, under the overall Spring Framework umbrella. org.springframework.plugin or something as root package. Each with its ow= n manual, which assumes knowledge of Spring fundamentals. - Minority interests should not be catered for in Spring. E.g. if someone wants to integrate with some weird technology or other that "two clowns a= nd a dog" use (to steal a phrase) that shouldn't go into Spring proper. Although we can link to it from a central page. Another interesting point is where there might be multiple implementation= s. Take security. From what I've seen, Ben's security stuff is great and has= an amazingly high level of documentation. So there's no question it meets Spring's quality criteria, and that it's of interest to many Spring users. But it's difficult to say that this should be "the security framework for Spring" because security is such a tricky area. J2EE tried that and it didn't work. So something like this being a sep product makes sense; a on= e size fits all solution is impossible. I think Brandon made a suggestion that we should include something along = the lines of a commitment to "no bloat" in the mission statement. I think thi= s is a good idea, although of course we need to come up with suitable phrasing. We _should_ guarantee to users that we won't be another EJB or Commons. Regards, Rod ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Tuesday, April 06, 2004 11:40 PM Subject: Re: [Springframework-developer] Keep Spring Focused Brandon, all, That's a tough issue: It is far from trivial to decide whether to keep third-party integrations within the core framework. We currently focus on= a quite extensive main project whose packages are strictly decoupled despit= e being in the same source directory. Our current strategy of providing bot= h a spring.jar and fine-grained individual jar files has received very positi= ve feedback. A completely different strategy can be seen at Jakarta: Everything's a separate project there. Have a look at Commons: 28 individual components with separate distributions, plus 20 more in the sandbox. Commons seems t= o become a collection of largely unrelated utilities, some of them with hard-to-see cross-dependencies. The quality of concepts and implementatio= ns varies widely. I guess that Spring cannot really be compared with Jakarta Commons in tha= t respect: Its vision is much more focused, even if covering a broad field = and numerous third-party integrations. Most importantly, Spring's implementat= ion is pretty consistent: We try very hard to apply similar patterns and reus= e other parts of the framework wherever we can. This is much easier within = the same project, when the affected class versions definitely match. I guess hardly anyone will argue that *all* third-party integrations shou= ld be moved outside the Spring core. JTA, JDO, Hibernate, iBATIS SQL Maps, JavaMail, JSTL, Velocity, Commons FileUpload, etc are all well-placed in = the main project, I assume. Tiles and FreeMarker integrations are debatable b= ut IMO still candidates for the main project: Where to draw the line? Why include Velocity integration in the main project but not FreeMarker? This is also related to the current Struts Spring integration discussion. Where do such integration classes naturally fit: in Struts? in Spring? in= a separate project, like the Struts Spring Plugin? Each separate project increases the number of jars to combine for typical applications, with matching dependencies... Particularly if the integration code is very sma= ll, there is a point in *not* making it a separate project, IMO. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Brandon Goodin Sent: Tuesday, April 06, 2004 5:18 PM To: spr...@li... Subject: [Springframework-developer] Keep Spring Focused WAS: commons-validator adapter Here is a summary of the previous threads that lead up to this discussion. Please read an comment. --- Brandon Goodin Mon 4/6/2004 --- Do what you like. But, these are the same kind of near sighted arguments I've heard from the Struts group over the last 2 years. If you provide integrated support for commons validator NOW people will grow to be used = to it as "the Spring" solution. Then when you introduce the "real" Spring declarative validation you will have competing products within the framew= ork creating confusion. If commons validator is NOT going to be the "official= " Spring declarative validation then keep it OUT of the core distro. I do n= ot believe you are keeping focused in doing these type of things. You CAN support things and help to keep them focused WITHOUT making it part of th= e core. Use a little collaboration for goodness sakes. Brandon --- Keith Donald Mon 4/6/2004 --- Spring to me is about making it easier to build real applications quicker. Since most applications (mine included) demand syntax and semantic validation of business objects, I would argue a good declarative validati= on framework managed by the Spring team is a good fit. Personally, I don't think commons-validator is that answer for us long term. I think we can offer better and do so in a "cleaner" (more true Spring) fashion, and tha= t's the focus of the 1.1 declarative validation efforts. However, we recogni= ze a substantial number of people out there already have an investment in Struts/commons-validator--thus for us to provide a _thin_ adapter for it that facilitates integration with the rest of Spring helps those people. And taking responsiblity for managing that piece helps ensure it stays consistent with the rest of the framework in terms of quality (including documentation and test coverage.) So my point is when I see that the Spring team has taken responsibility f= or an area and put their name on it, that says something about its quality: that is, that it is useful for one (it addresses a need, is documented, i= s tested), and that it will be managed and supported carefully over time. = Rod and Juergen are not going to move something out of the sandbox into the c= ore and into a release without first making sure it's ready and there is a re= al need for it, for example. We wouldn't want the emergence of a ton of decentralized Spring sub proje= cts to produce a sourceforge-like effect over time--that is, a lot of project= s that are inconsistent in terms of support-level/documentation/activity, e= tc (and personally I prefer Spring as my one-stop-shop, reducing the headach= e generally associated with managing technology integration [even then thou= gh, it's still modular...]). Please note this is not to say subprojects tha= t leverage Spring are a bad idea! Heck no, just look at the new Acegi Security Framework, for example! There just needs to be a separation between _what is_ Spring and what is a _separately managed_ project that builds on Spring. I agree we don't need a million validator options, and we should say "no"= to things that aren't a good fit or don't address a clear, substantial user need. So again the goal here is to allow those already with an investmen= t in commons-validator or Struts a way to easily integrate it with Spring. The adapter is to be quite thin and optional and there for people wanting= to use Spring but also needing it. Long term, I'd like to see everyone usin= g our own declarative validation stuff that we're working on now, because w= e feel we can offer something better and with some unique capabilities. Bu= t it's not ready yet (and even if it was people can't be expected to migrat= e everything on a dime, right?) Keith --- Brandon Goodin Mon 4/5/2004 --- This is exactly what I mean. Thanks Karl. I hope developers of Spring tak= e what Karl is saying to heart. To me this is vitally important in keeping = the reality and perception of Spring light and focused. I would hate to see Spring suffer from what Struts suffers from... "fascination with gadgetry= " or BSOS (Bright Shiny Object Syndrome)...distraction from what is importa= nt. Any developers reading this? Brandon --- Karl Baum Mon 4/5/2004 --- It's great that Spring offers a developer so many options, but after a wh= ile 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 develop= ers 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 ab= out the commons validator project. With each new popular open source compone= nt, we will need yet another package checked into the Spring project. We can start now with the spring-commons-validator subproject. --- Brandon Goodin Mon 4/5/2004 --- I understand that. I'm simply saying... leave the choices on other websit= es and focus on what spring is. Not on all the neat toys you can plug into i= t. So, where do you draw the line on what does and does not get included. Wh= y not setup a directory of tools that can be used in spring instead of feel= ing 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. Brandon --- Seth Ladd Mon 4/5/2004 --- 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=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ 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_id638&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Ben A. <ben...@ac...> - 2004-04-08 07:56:35
|
Hi all > Another interesting point is where there might be multiple > implementations. > Take security. From what I've seen, Ben's security stuff is > great and has an amazingly high level of documentation. So > there's no question it meets Spring's quality criteria, and > that it's of interest to many Spring users. > But it's difficult to say that this should be "the security > framework for Spring" because security is such a tricky area. > J2EE tried that and it didn't work. So something like this > being a sep product makes sense; a one size fits all solution > is impossible. It seems the consensus is to keep the core lean and I agree. The related issue is Spring's "marketability" if it lacks an approach to certain core capabilities. To illustrate, I've found there are four groups of user expectations towards Spring security: 1. Those who expect Spring core to provide security 2. Those who would like Spring core developers to review/endorse some external security component(s) 3. Those who just want a maintained, external, compatible security component (Acegi Security System today) 4. Those who don't need Spring security (maybe they're writing their own or just don't require security) The present Spring "component ecosystem" doesn't support the many users in groups one and two. Those in group three aren't particularly well catered for either, as there is no central resource where existing AND POTENTIAL users of Spring can discover related projects. Whilst there are the mailing lists, many evaluators won't spend the time wading through them - particular if another framework seems to obviously offer the desired capabilities. This is disappointing for Spring, as it misses out on potential users who would have fit into group three (ie not requiring any "official" component, just a viable one). I'd respectfully suggest the community develops some sort of review/endorsement program so that reasonably related components - including but not limited to security - can receive some form of "official" review. I respect this takes up the time of community members, but the time invested is far less than writing something from scratch. If a component is "up to Spring standard" - with unit test coverage reports, reference documentation, and JavaDocs - evaluation shouldn't demand copious amounts of time either. Review does not represent a guarantee, but simply an indication of reasonable treatment of a particular problem domain. If evaluation is too much, can we at least have a list of links on the Spring web site with a disclaimer indicating they have not been reviewed? At least this would help new users and those evaluating Spring. Best regards Ben |
|
From: <rod...@in...> - 2004-04-08 08:10:33
|
>I'd respectfully suggest the community develops some sort of review/endorsement program so that reasonably related components - including but not limited to security - can receive some form of "official" review. I respect this takes up the time of community members, but the time invested is far less than writing something from scratch. If a component is "up to Spring standard" - with unit test coverage reports, reference documentation, and JavaDocs - evaluation shouldn't demand copious amounts of time either. Review does not represent a guarantee, but simply an indication of reasonable treatment of a particular problem domain. Great idea. Spring is also partly a brand, rather than just a framework. |
