Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of mfncooper@gmail.com
 designates 209.85.160.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=tQjy0b2zxtufP84rRpkwb6TDh7dY4TLIbvJY4KNiHPNmADtkGFWoS5y8G9LKfSpzmf
         RlUcBknhNtSPgi3OY+rFqCGHvD+zzlNZvh1FJ3kOPacQSlC3vyMLc8M/o7jEQ3mRKDdH
         8cQOZuCX3SJLDNdjQhovkFtYiXxB0y/sMAcj4=
MIME-Version: 1.0
Sender: mfncooper@gmail.com
In-Reply-To: <e34c19110912281137q29453d3ewbddd15b28e0020de@mail.gmail.com>
References: <16d6c6200912271025p74b4c2eeoeb87e20e60f3675b@mail.gmail.com>
	 <9f960bad0912271118h3b98e12crbd6131c9fc5e5edd@mail.gmail.com>
	 <b9e663070912271230t5d64f54dp21d721667cfbc462@mail.gmail.com>
	 <16d6c6200912271239n431c178ag93cf78d399d69637@mail.gmail.com>
	 <d8bdeb6f0912281016o20e032d3y766e0b764d06c732@mail.gmail.com>
	 <e34c19110912281029x78170114x11e5843996888137@mail.gmail.com>
	 <16d6c6200912281057l4e102f6g9401a0f12a202333@mail.gmail.com>
	 <4B3901C9.2050400@Newfield.org>
	 <b9e663070912281116x6c85b869r530cd91aa253cf7@mail.gmail.com>
	 <e34c19110912281137q29453d3ewbddd15b28e0020de@mail.gmail.com>
Date: Mon, 28 Dec 2009 12:10:16 -0800
Message-ID: <16d6c6200912281210i4edc6d5cwf55de42630cbff69@mail.gmail.com>
Subject: Re: XWork has landed!
From: Martin Cooper <martinc@apache.org>
To: Struts Developers List <dev@struts.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 28, 2009 at 11:37 AM, Wes Wannemacher <wesw@wantii.com> wrote:
> On Mon, Dec 28, 2009 at 2:16 PM, Paul Benedict <pbenedict@apache.org> wrote:
>> Having XWork as a separate module is actually preferred, but only
>> because it's a better design decision. It will create a clear
>> separation of concerns within the code base. Now with that said, XWork
>> should be a *child* module of Struts -- not a separate release.
>>
>> Paul
>
> When you (and Martin) are indicating a "child" of Struts, I assume you
> mean for it to be a child outside of Struts2. I am a team player and
> I'm willing to set it up, whatever the consensus, but I would really
> prefer for it to be a child of Struts2. I understand the implications
> of supporting it, etc. But, the biggest gripe (and *my* motivation for
> voting to move it over) is that we often wait to release Struts2
> because we need a release of XWork. Not to knock Rainer, but sometimes
> this process takes a while. If it is a part of the Struts2 umbrella,
> then the release process outlined in the wiki will still apply, but
> everything (including xwork artifacts) will go out at once. Plus, one
> of my tasks for Struts 2.2 is to take advantage of maven's
> dependencyManagement and pluginManagement. We could probably work that
> into the struts-master, but I hate to push changes to Struts 1, since
> I don't use it much.
>
> I would just like to balance making our lives easier against other
> factors. In the end, if we make managing this beast easier we can move
> on things faster. I know that "fast" isn't necessarily a goal, but I'd
> still like to try to get to KISS so that potential patch-makers aren't
> so intimidated by our code and build process.

Where XWork lands up in the Struts repo, and how it gets built, have
zero bearing on how it gets released (except if we see ourselves
releasing it independently, which I did not think was the case).

As I see it, we have a set of choices to make

1) (a) move, (b) copy, (c) create an 'external' reference for
2) (a) all of XWork, (b) just the XWork core, (c) some other subset of XWork
3) (a) to a peer of 'struts2', (b) to somewhere within 'struts2', (c)
to somewhere else

I believe 1c + 2a + 3a = what we have today except that it's one
checkout instead of two. With that option, nothing about the build or
the build documentation changes, AFAICT. Is that what we want? I don't
know, I'm just suggesting that it's a low-cost way of moving forward
now that the code is in our repo.

I don't have a particular bias in regard to how we go about this,
beyond some source control best practices. I just think we need to
make sure we're all on the same page about where we want to end up.

--
Martin Cooper


> -Wes
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org