|
From: Rob H. <rob...@in...> - 2005-04-13 21:41:00
|
Thomas, If you are willing to work on it, I am happy for you to move it to Spring Modules now. I don't see any harm in including what is there in a 0.1 release if you are happy with it. Rob On 13 Apr 2005, at 20:52, tho...@tr... wrote: > Rob, > > I'm currently working on a project where I will use Commons Validator > outside of > a Web MVC environment. I still would like to be able to wire it up > using Spring > and I have been playing around with what's in the sandbox. I have > already > changed the package names, so let me know when/if it is a good time to > move > this to springmodules CVS. > > I moved most of it to org.springmodules.validation.commons package > except for > the tag library which I put in > org.springmodules.web.servlet.tags.validation.commons. I guess it > makes sense > to keep the package structure in org.springmodules the same as > org.springframework so it's easier to move code between the projects. > > Thomas > > > Quoting Rob Harrop <rob...@in...>: > >> Well, I'll spend some time going through the sandbox and see what I >> think is >> a candidate for Spring Modules. I'll post the suggestions here and if >> everyone is happy I'll do the move. We have about 6 active developers >> on SM >> who are not core Spring devs, plus there is me so we may be able to >> breath >> some live back into the stuff in the sandbox. >> >> Rob >> >> -- >> Rob Harrop >> Interface21 - Spring Services from the Source >> http://www.springframework.com >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...] On >> Behalf Of >> Juergen Hoeller >> Sent: 12 April 2005 22:17 >> To: spr...@li... >> Subject: Re: [Springframework-developer] Where does webflow live? >> >> Ah, our favorite topic once again ;-) >> >> I'm not entirely sure whether Web Flow will get its own module; could >> be too >> fine-granular. The binding framework quite certainly shouldn't, which >> would >> already cause a problem with Web Flow's current status if we had >> modules. >> >> To give some numbers: If we want to have the binding framework, JCA >> support, >> Hibernate support, Web Flow, etc as separate modules (which would be >> necessary to get your desired effect of not putting any early-access >> stuff >> in the sandbox), we would end up with at least 35 modules (that's our >> top-level packages plus some subpackages of relevant size). Frankly, I >> consider that a horror scenario in terms of management and would >> strongly >> vote against it. >> >> I guess what I'm saying is that modules only *look* convincingly >> easy, but >> won't be a general solution for the early access problem in practice. >> Keith, >> please try to imagine this in detail and don't just consider it as >> solution >> upfront. This is absolutely non-trivial when looking at the details. >> >> Before we continue to spread the word on modules, I'd like to see >> concrete >> suggestions for module separation, respecting the interdependencies >> outlined >> in section 3 of our readme. I have already tried multiple times to >> nail down >> some options, and have always failed to find a convincing separation. >> >> The current jar files (12) might be a starting point, but I'm not >> sure that >> they can serve as module granularity too... Some packages are joined >> together there rather arbitrarily (from a source module perspective), >> for >> example the ones in spring-support.jar, or the separation between >> spring-orm.jar (which includes the entire ORM support except for >> Hibernate) >> and spring-hibernate.jar. Those jar files cannot be mapped 1-to-1 to >> source >> modules. >> >> So in total, it's unclear to me how a concrete module separation >> could look >> like (the more I look at it, the harder it seems). I doubt that we can >> resolve this within the 1.3 timeframe, given that we have such an >> aggressive >> schedule there, with just two months for multiple major new features. >> >> Anyway, the real problem here is the sandbox, IMO. There's too much >> stuff in >> there, both dead and somewhat alive. Noone should have to rely on >> spring-sandbox.jar!! Everything that's of some use in there should >> move, >> either to the core or to Spring Modules. >> >> Juergen >> >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...]On >> Behalf >> Of Keith Donald >> Sent: Tuesday, April 12, 2005 9:24 PM >> To: spr...@li... >> Subject: RE: [Springframework-developer] Where does webflow live? >> >> >> Aye, this is exactly why we need a modular CVS structure and a smarter >> build, which Colin is leading up in the post 1.2 timeframe. >> >> Web flow is currently maintained in the sandbox, yes. This means it >> is also >> included in spring-sandbox.jar when the 'sandboxjar' target is run. >> >> Independent of that fact, the webflow.release target ships >> spring-webflow.jar and spring-webflow-support.jar, pulling in _just_ >> the >> required code from the sandbox needed to run spring webflow. >> >> So, I guess you can say we've taken the stance that people aren't >> developing >> apps with spring-sandbox.jar in their classpath. Hmm... >> >> In any case, in the future spring-webflow will be in its own module >> with its >> own distributable, along side other well-defined core modules, and the >> sandbox will die the death it deserves (or be only used for true >> 'scratch' >> stuff) >> >> Keith >> >> >> >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...] On >> Behalf Of >> Matt Raible >> Sent: Tuesday, April 12, 2005 3:04 PM >> To: spr...@li... >> Subject: [Springframework-developer] Where does webflow live? >> >> I ran into some issues last night with spring-sandbox.jar from Spring >> 1.2 RC1 and Spring Web Flow PR2. The problem turned out to be that >> many of the flow classes where already in my spring-sandbox.jar. Once >> I deleted them from spring-sandbox.jar, everything worked fine. How >> do >> I eliminate this duplication in the future? Is the web flow stuff in >> spring-sandbox.jar? The main reason I'm using the sandbox JAR is for >> Commons Validator. >> >> Thanks, >> >> Matt >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > -- Rob Harrop Interface21 - Spring Services from the Source http://www.springframework.com Lead Developer - AOP & JMX, Spring Framework: http://www.springframework.org Author, "Pro Spring" (February 2005, with Jan Machacek). http://www.amazon.com/exec/obidos/ASIN/1590594614/ Author, "Pro Jakarta Velocity" (August 2004). http://www.amazon.com/exec/obidos/ASIN/159059410X/ Author, "Pro Jakarta Struts" (March 2004, with John Carnell). http://www.amazon.com/exec/obidos/ASIN/159059228X/ ____________________________________________________ Interface21 Limited Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY Registered in England and Wales No. 5187766 ____________________________________________________ |