Ted,
Another trigger might be a revolutionary change to the feature set. If
we did everything that's already on the 1.3 to 1.5 roadmap, I could
see going to 2.x then.
To me chains.xml, decompose and adapt the request processor and ability
to use Commands instead of Actions is a revolution.
On 11/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
I haven't been a fan of the naming convention being introduced, and I've
said so in the past. But, as Ted points out in another post, no one,
including me, offered any better suggestions either, so it was just
pointless whining. Let me
On Tue, November 1, 2005 11:02 am, Ted Husted said:
To summarize,
* Instead of having a Struts Classic distribution, we could have a
struts-core-library distribution instead, that could also include
other Core compatiblity extensions, like Struts Flow and Struts
Scripting. If we did, then
On Tue, November 1, 2005 11:13 am, Michael Jouravlev said:
Struts Core sounds like a kernel for all Struts subprojects, while
AFAIK Shale and Ti do not depend on it. So, in a way this name is
misleading. Not that I can suggest something better ;-)
I think that's a fair point, although I think
So I guess Struts Core is not Core after all. If that's the case, too
bad for all the good work in the request processor.
Shale won't use it, and probably TI neither? Or is Shale the odd one
out? If it is, I guess you could say Shale is weakening the stature of
Struts.
I understand, but I
On 11/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
On Tue, November 1, 2005 11:13 am, Michael Jouravlev said:
Struts Core sounds like a kernel for all Struts subprojects, while
AFAIK Shale and Ti do not depend on it. So, in a way this name is
misleading. Not that I can suggest
On 11/1/05, Wolfgang Gehner [EMAIL PROTECTED] wrote:
I maintain that the new RequestProcessor and COR is not classic, but
new. And that COR should be highlighted as such, new.
I wouldn't agree with this, if you look at Struts evolution
* In Struts 1.0 all the request processing was in
On Tue, November 1, 2005 12:36 pm, Martin Cooper said:
At some point, we may need to distinguish more clearly between Struts, the
ASF project, and Struts, the framework, and I think that's essentially
what
we're starting to see a need for in these threads. It's not really all
that
different
On 11/1/05, Wolfgang Gehner [EMAIL PROTECTED] wrote:
[snip]
Shale won't use it, and probably TI neither? Or is Shale the odd one
out? If it is, I guess you could say Shale is weakening the stature of
Struts.
FWIW, Shale's application controller uses exactly the same technology that
the 1.3
On 11/1/05, Wolfgang Gehner [EMAIL PROTECTED] wrote:
Is Shale part part of the six original subprojects, and thus part of
Struts Original?
No, it is separate (but equal).
I maintain that the new RequestProcessor and COR is not classic, but
new. And that COR should be highlighted as such,
On 11/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
The first is simply the question of what is the name of the project at
large? Is it still Apache Struts? And then everything else falls
underneath it?
Yes. It's unlikely that the project name would change, since, as
Martin points out, it
Well, in a perfect world, Shale and TI they would depend on Core ;-) But
who wants to create dependencies for dependency sake?
You're correct, now of course we already have the struts-core
(requestprocessor) subproject living next to shale, without dependency.
So we don't really change much in
On Tue, November 1, 2005 1:21 pm, Ted Husted said:
That still allows you to have true sub-projects like Struts Ti, Struts
I wasn't aware of the points you made about Validator Ted... are you
saying that the Commons Validator has been altered in such a way that it
can no longer be separated
13 matches
Mail list logo
