Paul Benedict wrote:
Don, "compat" is much better. The problem, as I see it, is that you
will then have to be supporting the "compat" package as Struts 1.x
continues to be upgraded.
Heh, you must be new here :) Struts 1 is one of the most glacial
projects in the open source world. The Struts 1.3.5 release has been
basically done for the last two years, yet we couldn't get a GA release
out the door. Supporting a library that helps Struts 1 users migrate
will not be a problem.
Now I always thought Struts 1.x and 2.x could be running together, as
in 2 respective dispatching servlets -- but not through a supporting
2.x library. I never knew your solution was in the works. But now that
I see it, I do think it poses a problem because now you're duplicating
1.x functionality... but doesn't that assume 1.x stagnates? How can
you provide a "compat" module for a moving target?
Let's be honest - there isn't anything that Struts 1 does that Struts 2
doesn't do and doesn't do better. From a solely framework developer
standpoint, Struts 1 needs to be retired. However, in the real world,
there are thousands, if not more, apps running Struts 1. Most are fine
the way they are, and a team supporting Struts 1 is a great thing for
them. Heck, I have a few apps that fall into that category, and for
that reason, I'm personally dedicated to fixing occasional bugs and
security issues.
But there will be some teams that will want to migrate code and
developer knowledge to a more capable framework. For those folks, I
want to make that transition as easy as possible, and I think as a
Struts community, we owe it to our users to support that process 100%
and not just say, "We've moved on to the next shiny thing; good luck
with those old apps!"
I think it is great that you and I are committed to supporting Struts 1,
but with the amount of existing apps built on it, from a development
standpoint, it won't be going anywhere fast, anytime soon.
Don
Paul
Don Brown wrote:
No, no, no...not this again. Let's not go back to Struts as some
nebulous umbrella project with "different but good" frameworks. We
made a conscious decision to start Struts 2 and as the name implies,
it should viewed as the primary Struts framework once it goes GA.
That's great that folks are still interested in working on the Struts
1 codebase, just as the WebWork 1 and 2 projects continue to move
forward.
I'd might be willing to change the module to something like "compat",
but I think it is important as a project and PMC to not be sending
mixed messages that something as confusing as two frameworks with the
same name yet sequential versions are somehow equal. If the PMC
accepted the WebWork 2 codebase as Struts 2, the explicit successor
to Struts 1, then we should stick to it.
Don
Paul Benedict wrote:
I would like if it we, the struts team, refrain from using the term
"legacy" in packages or to talk about the Struts 1.x code base.
From a personal perspective, my focus is on 1.x and I do not think
that 2.x "supersedes" what we have in the 1.x line. It's a totally
different architecture and 2.x has better way of solving some
problems, but we're still solving the same problems.
But with regards to what the 1.x will become in the future, I have a
slew of enhancements I want to apply; this means 1.x may have some
good features 2.x does not, and vice-versa. I don't want these new
features to be viewed as "legacy"; I think that label carries a lot
of negative weight and biases developers against the work that goes
into it.
Paul
------------------------------------------------------------------------
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
