struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Date Fri, 17 Mar 2006 20:55:54 GMT
Joe Germuska wrote:
> If we're going to consolidate, why not go whole hog and have a single 
> artifact?

I still see value in the extensions having their own artifacts.  For one, it makes it easier
to grok for new folks, and 
in cases like taglib and el, they can't be merged.  I see it working similarly to how Spring
manages its components.


> I agree that past experience and the future of action2 suggest that 
> there's not going to be a lot of activity in various subprojects 
> independent of an individual release.
> Joe
> At 10:48 AM -0800 3/17/06, Don Brown wrote:
>> 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 <> 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:
>>>  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:
>>>  For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message