struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: Action 2
Date Thu, 23 Mar 2006 03:43:22 GMT
At this point, XWork will stay where it is, as the proposal only covers 
WebWork 2.  There is no IP problem, as Apache code depends on external 
libraries all the time.  We may decide later to bring over xwork, but 
for now, I believe it is staying.  If we do decide to bring it in, it 
will have to go through the same IP clearance procedures as WebWork 2 is 
subjected to now.


Paul Benedict wrote:
> How is Action 2 going to deal with XWork intellectual property?
> I ask this because WebWork is just an extension of XWork,
> which AFAIK, XWork is not becoming Struts too.
> -- Paul
> --- Don Brown <> wrote:
>> Whether we do this now or not is debatable, in my mind, but the more I think about
it, the more
>> I think we'll need to do 
>> it, and just from a project management perspective, let alone a end user confusion
one.  Shale
>> has components, Action 2 
>> will have components, and certainly Action 1 has components.  If the components need
their own
>> release cycle, then the 
>> alternative is to have a three-tier organization, but I think Apache wants to avoid
that after
>> Jakarta.
>> I've been starting to work more on Action 2 (WebWork 2.2.2 has been delayed a day
so the release
>> and Apache import 
>> should happen tomorrow), and I'm seeing that Action 2 will have at least the following
>> components:
>>   - Core (WebWork 2)
>>   - Apps
>>   - Legacy
>> And probably more if we split up WebWork 2 further.  WebWork 2 currently handles
this by setting
>> up Ivy 
>> "configurations", but leaving the code in one tree.  You do have the problem where
>> infrequently, non-core part of 
>> your project holds up releases, but again, unless we could do a three-tiered (Struts
-> Action 2
>> -> Core, each having 
>> their own releases), that's what we'll have to do.  Giving Apps its own subproject,
>> branches for Action 1, Action 
>> 2, and Shale is too complicated, I think.
>> I'm fine staying the course for now to ensure Action 1.3 gets a GA release soon,
but we should
>> resolve this before 
>> Action 2 gets out of Incubator.
>> Don
>> Ted Husted wrote:
>>> On 3/21/06, Wendy Smoak <> wrote:
>>>> And I didn't mean to discourage you -- in fact I offered to help. :)
>>>> My comment was qualified with 'from a release manager perspective'.
>>>> Obviously, it's easier to package and verify a release for a single
>>>> jar than several of them plus example apps.
>>>> If anyone really wanted to keep the separate sub-projects, I think
>>>> they would have spoken up by now.  Somehow I don't think you're going
>>>> to get any opposition, and now that the proposal is on the table, I'd
>>>> like to see a decision made one way or the other.
>>> I think the important thing is that we not halt any forward progress.
>>> If someone wants to move forward with another build of one or more of
>>> the Action 1 subprojects, then I would suggest staying the course and
>>> rolling the build.
>>> If no one is eager to start moving things about, I'd suggest an
>>> optimum time to recombine the subprojects would be after each had a GA
>>> release. At least then we would have something out the door, where
>>> more teams could use it. A GA release orf each would also demonstrate
>>> an ongoing need to move things about.
>>> But, again, AFAIC, whoever is ready to do the work is welcome to make
>>> the decision.
>>> -Ted.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message