On 5/31/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 5/31/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 5/31/06, Wendy Smoak <[EMAIL PROTECTED]> 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
