+1 to all of this. :-) One point about dependencies on 'core', though. It's seldom likely to be as clear cut as depending on core or not. For example, it's likely that, once we split out Tiles, there will still be some glue that depends on 'core', even if Tiles per se does not. Then the question arises of where the glue should live - here or as part of the glued-on project. ;-) (BTW, that's something I think we should develop a policy on, so that we're not seen as making arbitrary decisions in this area, but that's another topic entirely.)
-- Martin Cooper On Sun, 18 Jul 2004 08:59:38 -0400, Ted Husted <[EMAIL PROTECTED]> wrote: > On Sat, 17 Jul 2004 17:06:44 -0700, Martin Cooper wrote: > > kind of repackaging seems fairly drastic as part of a point > >ïrelease, since it will affect how people download and build their > >ïStruts apps. But if everyone else is OK with that, I won't object. > > If we want to call this Struts 2.x, that would be OK with me. Then, everything we > slated for 2.x moves up to 3.x. > > (Which underscores the evil of framing development roadmaps around version numbers. > The tail starts to wag the dog.) > > >ï2) Is this presuming a change of Servlet / JSP version > >ïdependencies? Otherwise I'm not sure how feasible it would be to > >ïmove 'upload' to 'addons', because of all the wrapping and > >ïunwrapping we have to do for Servlet 2.2 compatibility. > > If we want to move the minimum to Servlet 2.3 that would be OK with me too. > > Then we have Struts 1.x, 2.x, and 3.x, for the Servlet 2.2, 2.3, and 2.4 > respectively. > > >ï7) I think we need a better term than 'module', since that's > >ïalready taken in the context of Struts apps. ;-) > > I'd favor going back to referring these as "subprojects" and make subprojects > artifacts the units of release. > > The idea being we can make a new release of struts-core without making a new release > of struts-taglibs, and vice versa. > > >ï5) I'd like us to find some kind of plugin mechanism for the web > >ïsite, so that the non-core modules had add their piece to the main > >ïsite without a lot of dependencies. Not sure how that would work, > >ïoff the top of my head, but I think it would be a good goal. > > As subprojects, each of these would have their own documentation and Maven site. > Struts-site would need only link to each subproject (or module). > > While this starts to have the look-and-feel of an umbrella project like the Commons > it is NOT AN UMBRELLA project, since all the subprojects are dependant on the > struts-core distribution. > > The latter might even be a rule. If a subproject is not dependant on struts-core, > then it can be hosted elsewhere. > > So, for example, if we can spin-off Tiles so that it has no struts-core > dependencies, then it wouldn't belong here. It could live in the Jakarta or Apache > Commons, or SourceForge. > > -Ted. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
