|
From: Keith D. <ke...@in...> - 2005-04-13 15:22:34
|
I don't see why Web Flow should not be its own module. It's 135K as is, probably around 115 classes. I also think data binding could nicely be its own module as well, upon which web flow would depend. A smart build system would make things manageable. Look at how the eclipse project does it -- they have lots of different modules for the different parts of Eclipse, and they're successful at it. I'm not saying Hibernate and OJB and iBatis should each be their own, for example, that's probably a bit xtreme -- but ORM might well be. We probably shouldn't get distracted by this now given 1.2. Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Juergen Hoeller Sent: Tuesday, April 12, 2005 5:17 PM 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 |