I might as well make this its own proposal: I propose we consolidate the 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action' subproject. We would keep the extensions as separate, but include them in the 'action' subproject meaning they will continue to share the same version number and release cycle.
The reason I propose this is while the original feeling was these extensions would develop lives of their own and not hold up releases, the opposite has proven true, especially now with Action 2 coming down the pipeline. The same people that update tablibs, for example, are the same people that work on Action 1, and there just hasn't been a clamoring need to release a new version of tabligs without a new version of Action. By consolidating, we stave off user confusion and simply the work of the Struts developer. The new subversion repository would look like this: action/trunk/apps action/trunk/core action/trunk/el action/trunk/extras action/trunk/faces action/trunk/taglib The new test for the existence of subprojects should be if: a) The subproject has its own distinct community that requires a new release cycle b) The subproject is relevant to more than one framework (optional, but encouraged) I'd imagine this organization would allow the build for these action-related extensions to try to build each other, leaving the other subprojects to use snapshots instead. If every subproject had its own release cycle, I wouldn't think we'd need/want a build that built each from trunk, since each subproject would require different minimum versions of each other subproject. For example, Scripting might require only Struts 1.1, so it wouldn't make since for its build to try to build Action 1 from trunk. On the other hand, building 'extras' would force a 'core' build. As far as impact, I'd like to hear from the build folks (Wendy) if this would seriously impact the build. If so, we could hold off, but I really think this is the direction we need to move. I know it seems like we are going backwards, but I see it as simplying our project and better aligning it with the current energies and direction of its developers. Don On 3/17/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > We need to decide on a Maven groupId for Struts Action. Currently, > we're using 'struts' but we've been asked to conform to the Maven 2 > repository structure and place our artifacts under org/apache/struts. > > My plan is to use org.apache.struts.action as the groupId. > > As you can see with Shale, that will create a sub-group in the repository: > http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ > > This doesn't have to change the svn repository at all, but something > I've been wondering about is how we're going to 'make room' for Action > 2. Right now Action 1 is spread across the top level of the svn repo. > > Any thoughts on grouping the Action 1 related modules together in some > way? > > And where do you see the WW/Action 2 code being added, when it comes > out of the incubator? (Does 1.3 become a branch, or is action2 a > separate trunk?) > > Thanks, > Wendy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
