On Apr 20, 2011, at 2:09 AM, VANKEISBELCK Remi wrote: > > If those are included then, regardless of original intent, users will think > > that these are "first class" citizens of Stripes, and that the > > there is some obligation for the maintainer of Stripes core to maintain > > these as well." > > Well, everything is subjective, but clearly some of the "extensions" will be > first class citizens. Think about what's already in the core and will be > moved (e.g. Spring integration). Now, I've never said that ALL extensions > should be included to the main repo and built along with the framework. I > think every extension, once it gets popular, stable etc., turns into a good > candidate for integration into the "offficial" extensions of the framework. > > > There's also the issue of code segregation, IP rights, and commit access. > > Yep, but on the other hand it ensures that all parts are consistent when new > versions are released, that they have the same license, and that they are > managed by the same group of developers. Last, it could drag new coders into > the framework. And again, it doesn't mean that evey extension has to be > there, just the ones that have been approved by the community. You can still > write your separate, third party extension if you want, and distribute it the > way you want.
My only concern is that the "community" can decide whatever it wants, but most of the time its Ben who gets to do the work. And voting to get more puppies for Ben to take care of isn't really fair to him. That's why I resist the inclusion of some of the existing external pieces in to the responsibility of the current maintainer. > In short, think about how life would be if Spring's codebase contained only > core container, and everything else (JDBC, JMS, ...) was scattered around the > web... Different builds, different policies of maven sync, different > websites... admin drag you said ? > :P It's admin drag on the end users/developers, but not the Stripes dev "team". Does it make Stripes harder to use? Perhaps, marginally, but also because there's still really few things to "add on". As you mentioned if there is some core mechanism (either in the runtime or in the build) that makes integration of 3rd party modules easier and more consistent, AND those changes are straightforward and suitable for a 1.x release, then that may well be a good plan. That makes Stripes more puppy friendly but without the need to actually take them home. > Not sure you talk about the modularization of the build here. > If you do, c'mon... the build already exists, there's nothing to do. I'd say > half a day work, not a class file touched, only a few moves... > >From the ground up ??? The maven build is one thing, I've already advocated for that, mostly because you were willing to lend your expertise and time to engineer and see it through to completion, and to train Ben and others how to maintain it. But others are talking a more extensive module system and a project move to Github. Those are more fundamental IMHO than what we're talking about here. Regards, Will Hartung ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
