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.
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?
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]
