struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [shale] Maven 2 build -- Help Wanted
Date Wed, 31 May 2006 21:46:46 GMT
On 5/31/06, Wendy Smoak <wsmoak@gmail.com> wrote:
>
> On 5/31/06, Craig McClanahan <craigmcc@apache.org> wrote:
> > On 5/31/06, Wendy Smoak <wsmoak@gmail.com> wrote:
>
> > > Do you forsee us needing to release them separately?  I think the
> > > single distribution with one version number is less confusing for
> > > users.  Separate releases are less work individually for release
> > > managers (easier to verify, etc.,) but you end up doing more of them.
> >
> > But we're going to do the separation thing anyway, right, even if we
> don't
> > release separately?
> >
> > I can certainly see a case for something like the test framework being
> > releasable separately.
>
> Separate jars, yes.  Now we're discussing the difference between:
>    shale/trunk/core
>    shale/trunk/test-framework
> and
>    shale/core/trunk
>    shale/test-framework/trunk


Ah ... now I see where you're going.  But even if we went the first way,
couldn't you still fork from

    shale/trunk/test-framework

to

    shale/branches/test-framework/1.2.3

if version 1.2.3 was actually released separately?

The former implies that all the jars are versioned and released
> together.  The latter is what Sean is suggesting, a separate trunk for
> each module.
>
> I can see a reason to have Clay and Test Framework on separate trunks,
> but I'm not so sure that spring and tiles really need a separate
> release cycle from core.
>
> The test framework is reorganized and building with just the Servlet
> API and HtmlUnit as provided and optional dependencies, respectively.
>
> http://svn.apache.org/repos/test/struts/struts-shale/trunk/test-framework/pom.xml
>
> I'm going to move designtime back out to shale/designtime.


That makes sense as well ... it would not likely every be released
separately.

Sean, I removed the MyFaces dependency from core-library.  For now,
> enable a profile with either -Pmyfaces or -Pjsfri depending on what
> you want to build with.  We need to make the MyFaces profile active by
> default, while also being able to deactivate it to build with the RI.


Sounds good.

--
> Wendy


Craig

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message