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]
