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 <[EMAIL PROTECTED]> 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 an > 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, with > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
