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.
Don
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 <[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
