You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wolfgang Gehner <ne...@infonoia.com> on 2005/11/01 13:31:27 UTC
Re: Struts 1.3 release naming - Struts CORE
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. Great credit to who
came up with this. Changes are not just in Java methods but also in the
abilities to use XML such as chains.xml.
I thought that calling it 2.0 would be scary to some, though I don't
think you are obliged to break the code when going from 1.x to 2.0
I was aware of the roadmap, I just think in retrospect the changes from
1.2 (and benefits) are so big that just calling it 1.3 doesn't give full
merit. Maybe the roadmap could be changed to move stuff in 1.4 and 1.5
to 1.6 and 1.7?
>If a Ruby on Struts is something that you want to use in your own
>work, then you should do it, and share the result with others. That's
>what we are doing here. :)
>
>
Sure, it was just meant as an example, but if I had a long weekend I
would give a go at it...
>Ah, well, we're not marketers and we're not selling anything. We're a group of engineers working together to create and maintain the framework that we want to use in our own applications.
>
>
Well, a bit of marketing can't hurt if it corresponds to the truth, and,
most importantly, it supports the developers who have adopted it, so
they will have less explaining to do later why why they chose this
"historic, dusty" framework that noone talks about any longer.
Communicating the good is something that is in some way owed to the
adopters, as well as the handworking Struts contributors, of course.
>I don't think anyone is married to the term "Classic", it's just that
>no one's suggested another.
>
>
So let me formally propose that Struts point releases as of 1.3
including be called Struts CORE.
(core in capitals), see my other post "Struts Communication" on the
reasoning (sort of stands for ChainOfREsponsibility and at the same time
signifies the revolution in the request processor, as well as the new
modular/subproject structure). I think that would be quite sexy.
That would mean the "Classic" label is kept for releases prior to 1.3,
which I think is fairer in reflecting what is "old and established".
Maybe that would be some middle ground without disturbing the set ways
of release management.
Kindest regards,
Wolfgang Gehner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by Marky Goldstein <re...@rosa.com>.
+1
Wolfgang Gehner wrote:
> +1
>
> Wolfgang Gehner
>
> Ted Husted wrote:
>
>> On 11/1/05, Frank W. Zammetti <fz...@omnytex.com> 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 try and change to something more
>>> constructive...
>>>
>>
>>
>> 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 "Struts Classic" would be relegated to a
>> codename we used to get the "seven dwarfs" ready to ship.
>>
>> * Yes, in addition to a "struts-core-library", we could also have an
>> "apache-struts-all" distribution that included all the subprojects in
>> one bundle. In other words, it would be the GA version of the nightly
>> build. (But first, we need GAs to bundle!)
>>
>> * Our "Struts Validator" is based on the "Apache Jakarta Commons
>> Validator", which could become a top-level Apache project whenever the
>> people working on the Validator wanted to go through the application
>> process. (Ditto for Struts Tiles.) We don't see a way to break "Struts
>> Validator" out from Struts Core, since the reusable functionality is
>> already in the Commons package.
>>
>> As the rest: Yes, that sounds like what we are doing. :)
>>
>> -Ted.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>
--
R.Ø.S.A.
Identity: Marky Goldstein
E-Mail: ready@rosa.com
Task: Managing Director, Product & Strategy
R.Ø.S.A. Creation. Technology. Intelligence. AG
Seefeldstrasse 231, 8008 Zurich, Switzerland
Phone: +41 1 389 63 33
Fax: +41 1 389 63 30
URL: http://www.rosa.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by Wolfgang Gehner <ne...@infonoia.com>.
+1
Wolfgang Gehner
Ted Husted wrote:
>On 11/1/05, Frank W. Zammetti <fz...@omnytex.com> 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 try and change to something more
>>constructive...
>>
>>
>
>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 "Struts Classic" would be relegated to a
>codename we used to get the "seven dwarfs" ready to ship.
>
>* Yes, in addition to a "struts-core-library", we could also have an
>"apache-struts-all" distribution that included all the subprojects in
>one bundle. In other words, it would be the GA version of the nightly
>build. (But first, we need GAs to bundle!)
>
>* Our "Struts Validator" is based on the "Apache Jakarta Commons
>Validator", which could become a top-level Apache project whenever the
>people working on the Validator wanted to go through the application
>process. (Ditto for Struts Tiles.) We don't see a way to break "Struts
>Validator" out from Struts Core, since the reusable functionality is
>already in the Commons package.
>
>As the rest: Yes, that sounds like what we are doing. :)
>
>-Ted.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
Re: Struts 1.3 release naming - Struts CORE
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 from Spring, which started out as just Spring, the IoC
> framework,
> and is now so many other things as well.
I may not agree with what lead to this conclusion, but I do agree with the
conclusion itself :)
I do think the structure of the Struts project is moving in the right
direction, even if I might do some of the details differently, the overall
direction seems to me the right path to be on.
If I could convince anyone to NOT use the Struts Classic moniker though,
that would certainly address my biggest concern. As such, I like the
suggestions Ted made earlier and hope they will be adopted.
> --
> Martin Cooper
Frank
>
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by Martin Cooper <ma...@apache.org>.
On 11/1/05, Frank W. Zammetti <fz...@omnytex.com> 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 something better ;-)
>
> I think that's a fair point, although I think it's something everyone
> could probably live with.
>
> What about this suggestion... what about if there was a Struts
> Experimentation sub-project, or something like that, which itself included
> sub-projects like Shale, Ti, etc.? I think that would more clearly
> describe what Ti and Shale and the like are and how they relate to what we
> know as Struts today.
No, not really.
Organisationally with respect to the ASF, Struts is the project. That is
what we have a PMC for, as well as all the organisational infrastructure.
Within that project, we are free (within limits) to structure as we will. We
have chosen to structure as a set of sub-projects, along with an area for
experimentation which we have named the sandbox. This structure is reflected
in the SVN repo, where there is a top level directory for each sub-project,
and one for the sandbox. Sub-projects are created as a result of a vote,
while experiments can pretty much "just show up" in the sandbox.
I point all this out to clarify that Shale is a sub-project that we have
voted on, whereas Ti is, at this point, still an experiment in the sandbox.
Thus Shale has the same status within the project as other sub-projects such
as Core, Taglibs and Flow.
It's also worth pointing out that while Shale is currently the only
sub-project that does not depend on Core, that will not continue to be the
case. We are in the process of moving Tiles towards a standalone component
specifically so that it does not depend on Core, and at some point the new
Tiles will become a sub-project. (It may go on to a life as a full-blown ASF
project of its own, but that's another story.) And then there are other
components in the sandbox, such as Overdrive and Ti, that may become
sub-projects when they are ready.
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 from Spring, which started out as just Spring, the IoC framework,
and is now so many other things as well.
--
Martin Cooper
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Struts 1.3 release naming - Struts CORE
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 it's something everyone
could probably live with.
What about this suggestion... what about if there was a Struts
Experimentation sub-project, or something like that, which itself included
sub-projects like Shale, Ti, etc.? I think that would more clearly
describe what Ti and Shale and the like are and how they relate to what we
know as Struts today.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by Wolfgang Gehner <ne...@infonoia.com>.
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 that respect.
One reason why I personally like CORE is because it contains COR, of
course, so it's easy to explain and remember with that pattern. "I use
Struts CORE with XXX" just has a nice modern ring to it. But I repeat
myself...
Wolfgang Gehner
Michael Jouravlev wrote:
>On 11/1/05, Ted Husted <te...@gmail.com> wrote:
>
>
>>* 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 "Struts Classic" would be relegated to a
>>codename we used to get the "seven dwarfs" ready to ship.
>>
>>
>
>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 ;-)
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
Re: Struts 1.3 release naming - Struts CORE
Posted by Michael Jouravlev <jm...@gmail.com>.
On 11/1/05, Ted Husted <te...@gmail.com> wrote:
> * 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 "Struts Classic" would be relegated to a
> codename we used to get the "seven dwarfs" ready to ship.
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 ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 from Struts? Or did I not understand your
>> comments?
>
> The Commons Validator *is* separate from Apache Struts, and having a
> separate "Struts Validator" subproject seems neither feasible nor
> desirable.
That's what I thought was the case, but what you wrote before confused me
(it doesn't take much, especially today). No argument here... it's
already it's own project outside Struts, I certainly see no need for a
"Struts Validator" either.
> As it stands, we're trying to turn Tiles into something
> like the Commons Validator: a component that people can easily use in
> other products and frameworks.
Right, I was aware of that and definitely think it's a good idea.
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by Ted Husted <te...@gmail.com>.
On 11/1/05, Frank W. Zammetti <fz...@omnytex.com> 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 is reflected in our infrastructure, and in fact
created by a corporate resolution of the ASF.
> 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 from Struts? Or did I not understand your
> comments?
The Commons Validator *is* separate from Apache Struts, and having a
separate "Struts Validator" subproject seems neither feasible nor
desirable. As it stands, we're trying to turn Tiles into something
like the Commons Validator: a component that people can easily use in
other products and frameworks.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 "Struts Classic" would be relegated to a
> codename we used to get the "seven dwarfs" ready to ship.
>
> * Yes, in addition to a "struts-core-library", we could also have an
> "apache-struts-all" distribution that included all the subprojects in
> one bundle. In other words, it would be the GA version of the nightly
> build. (But first, we need GAs to bundle!)
>
> * Our "Struts Validator" is based on the "Apache Jakarta Commons
> Validator", which could become a top-level Apache project whenever the
> people working on the Validator wanted to go through the application
> process. (Ditto for Struts Tiles.) We don't see a way to break "Struts
> Validator" out from Struts Core, since the reusable functionality is
> already in the Commons package.
>
> As the rest: Yes, that sounds like what we are doing. :)
Yeah, what I wrote wasn't exactly revolutionary :)
I like what you say here Ted, but in my mind I think there are really two
different issues, although they are clearly intermingled, that should be
talked about...
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? I ask this because I was confused whether that was the
case, or whether Struts Classic was actually the new name or just the new
name of the one combined distribution. This is the kind of confusion I
would hope to avoid, and maybe it was just me in any case :)
The other part of it is what you call the released artifacts. In that
regard, I didn't like Struts Classic because of the connotations that go
along with it. What you suggest above I think avoids that very nicely and
still gives a solid description of what the artifacts really are.
That still allows you to have true sub-projects like Struts Ti, Struts
Shale, etc. But then they are pretty clearly demarcated from the "main
line", so to speak... It wouldn't confuse anyone about what Struts is, and
also serves to show what Struts could become later.
And at some point, when that major revolution comes around, then the
Struts Classic moniker for what we now call Struts makes good sense.
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 from Struts? Or did I not understand your
comments?
> -Ted.
Frank
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by Ted Husted <te...@gmail.com>.
On 11/1/05, Frank W. Zammetti <fz...@omnytex.com> 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 try and change to something more
> constructive...
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 "Struts Classic" would be relegated to a
codename we used to get the "seven dwarfs" ready to ship.
* Yes, in addition to a "struts-core-library", we could also have an
"apache-struts-all" distribution that included all the subprojects in
one bundle. In other words, it would be the GA version of the nightly
build. (But first, we need GAs to bundle!)
* Our "Struts Validator" is based on the "Apache Jakarta Commons
Validator", which could become a top-level Apache project whenever the
people working on the Validator wanted to go through the application
process. (Ditto for Struts Tiles.) We don't see a way to break "Struts
Validator" out from Struts Core, since the reusable functionality is
already in the Commons package.
As the rest: Yes, that sounds like what we are doing. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 try and change to something more
constructive...
Why not take a cue from Microsoft (G-d forbid!) as well as countless other
companies? There is Windows. Then there is Windows Workstation. Then
there is Windows Server. And so on. There is Ford. Then there is a Ford
Taurus. Then there is a Ford Windstar. And so on.
Point: you have a basic brand name with some tacked on word that describes
a brand extension, or sub-type.
There should, IMO, always be something called Struts because it has market
awareness and there's no point in willingly giving that up. What should
that something be? I would say at this point that the project itseld
should be called Struts, kind of a meta term to describe everything (more
akin to Ford than Windows in that case). I don't think anyone has
suggested not doing this, but wanted to state it anyway.
The one convenience download that includes all the subcomponents should
also simply be called Struts. Why confuse people who already have an
understand of what Struts is?
>From that point on, you have all the sub-projects being named Struts
XXXX... unless they are actually moved out of Struts, then they should be
subprojects not of Struts but of Jakarta or Apache, and I think this is
what should be happening... should Validator be Struts Validator? No, it
should be Apache Validator, or something like that, because it isn't tied
to Struts any more.
Likewise, when you have the version that integrates JSF, you call it
Struts JSF. You might also get Struts Shale, and of course Struts Ti,
etc. This indicates to people that this is clearly a subproject of the
larger Struts project they already know about, perhaps the next evolution
of Struts even.
I agree with the sentiment that Struts Classic is not the best choice. It
carries certain connotations that one would hope are not trying to be
conveyed. I think it also just confuses matters because until there is
something that supplants the current Struts in a linear fashion, it
doesn't make sense... I mean, Microsoft isn't going to go name Windows XP
with service pack 3 Windows Classic. They might be able to get away with
that when Vista is release though (arguably at least). So, when Struts
2.0 is ready, in whatever form that takes, and it is obvious that it's a
big enough change that it warrants being 2.0, then calling the 1.x line
Classic makes sense. I don't believe that is the case going from 1.2.7 to
1.3. As Ted pointed out, it's arguable whether 1.3 is revolutionary or
evolutionary (I'd vote for the later, but a very good evolution).
So, in short:
Struts
|
=---- Struts Core *
|
=---- Struts Taglibs *
|
=---- Struts Shale
|
=---- Struts Ti
Some other top-level thing, maybe Apache?
|
=---- Tiles *
|
=---- Validator *
* These all combined are simply called Struts, so that when someone goes
to download Struts, that's what they get, unless they choose to download
the individual subcomponents separately.
Frank
On Tue, November 1, 2005 8:07 am, Ted Husted said:
> On 11/1/05, Wolfgang Gehner <ne...@infonoia.com> wrote:
>> So let me formally propose that Struts point releases as of 1.3
>> including be called Struts CORE.
>
> I think the point that people are missing is that Struts Classic is
> not a product, it's a distribution of products. Struts Core is one
> product, Struts Taglibs is another. Each has it's own release cycle
> and can be distributed separately.
>
> As a convenience, we plan to bundle the GA releases for the six
> original subprojects into a single distribution, for downloading
> convenience.
>
> :) Which begs another moniker. Instead of Struts Classic, we could
> also call the distribution Struts Original. :)
>
> As it stands, we don't want there to be one Struts, since one Struts
> can't serve everyone's needs right now. Some of us want to rewrite our
> applications for new technologies like JSF. Others want to continue to
> evolve the applications we already have and avoid drastic change.
> Since we have volunteers who want to do both, we do both.
>
> Sure, if this was about capturing marketshare, we'd pick a horse and
> label it Struts 2.x. But it's not about marketshare, it's about
> working together to create and maintain the framework we want to use
> to ship our own applications. Since no one's come up with a way to
> create one framework that will serve everyone's needs right now, the
> only option left is multiple frameworks.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by Niall Pemberton <ni...@gmail.com>.
On 11/1/05, Wolfgang Gehner <ro...@infonoia.com> 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 methods in ActionServlet.
* Struts 1.1 introduced the "RequestProcessor" with logic be
refactored out of ActionServlet.
* Struts 1.3 introduces the CoR flavour "RequestProcessor" with
RequestProcessor logic being refactored out into Commands
...although these changes were new/important/good at the end of the
day they all support the same "request processing" logic with the new
refactorings allowing the "classic" struts processing to be more
easily pluggable/configurable. IMO they are all Struts classic.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by Craig McClanahan <cr...@apache.org>.
On 11/1/05, Wolfgang Gehner <ro...@infonoia.com> 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 request processor uses ... Commons Chain.
:-)
Craig
Re: Struts 1.3 release naming - Struts CORE
Posted by Ted Husted <te...@gmail.com>.
On 11/1/05, Wolfgang Gehner <ro...@infonoia.com> 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, new.
As Niall points out, the Request Processor has undergone a steady
evolution since Struts 0.5. The latest version may be revolutionary on
the inside, but it's evolutionary on the outside. :)
>
> Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 release naming - Struts CORE
Posted by Wolfgang Gehner <ro...@infonoia.com>.
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 see why people could be confused.
Is Shale part part of the six original subprojects, and thus part of
Struts Original?
I maintain that the new RequestProcessor and COR is not classic, but
new. And that COR should be highlighted as such, new.
Wolfgang
Ted Husted wrote:
>On 11/1/05, Wolfgang Gehner <ne...@infonoia.com> wrote:
>
>
>>So let me formally propose that Struts point releases as of 1.3
>>including be called Struts CORE.
>>
>>
>
>I think the point that people are missing is that Struts Classic is
>not a product, it's a distribution of products. Struts Core is one
>product, Struts Taglibs is another. Each has it's own release cycle
>and can be distributed separately.
>
>As a convenience, we plan to bundle the GA releases for the six
>original subprojects into a single distribution, for downloading
>convenience.
>
>:) Which begs another moniker. Instead of Struts Classic, we could
>also call the distribution Struts Original. :)
>
>As it stands, we don't want there to be one Struts, since one Struts
>can't serve everyone's needs right now. Some of us want to rewrite our
>applications for new technologies like JSF. Others want to continue to
>evolve the applications we already have and avoid drastic change.
>Since we have volunteers who want to do both, we do both.
>
>Sure, if this was about capturing marketshare, we'd pick a horse and
>label it Struts 2.x. But it's not about marketshare, it's about
>working together to create and maintain the framework we want to use
>to ship our own applications. Since no one's come up with a way to
>create one framework that will serve everyone's needs right now, the
>only option left is multiple frameworks.
>
>-Ted.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
Re: Struts 1.3 release naming - Struts CORE
Posted by Ted Husted <te...@gmail.com>.
On 11/1/05, Wolfgang Gehner <ne...@infonoia.com> wrote:
> So let me formally propose that Struts point releases as of 1.3
> including be called Struts CORE.
I think the point that people are missing is that Struts Classic is
not a product, it's a distribution of products. Struts Core is one
product, Struts Taglibs is another. Each has it's own release cycle
and can be distributed separately.
As a convenience, we plan to bundle the GA releases for the six
original subprojects into a single distribution, for downloading
convenience.
:) Which begs another moniker. Instead of Struts Classic, we could
also call the distribution Struts Original. :)
As it stands, we don't want there to be one Struts, since one Struts
can't serve everyone's needs right now. Some of us want to rewrite our
applications for new technologies like JSF. Others want to continue to
evolve the applications we already have and avoid drastic change.
Since we have volunteers who want to do both, we do both.
Sure, if this was about capturing marketshare, we'd pick a horse and
label it Struts 2.x. But it's not about marketshare, it's about
working together to create and maintain the framework we want to use
to ship our own applications. Since no one's come up with a way to
create one framework that will serve everyone's needs right now, the
only option left is multiple frameworks.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org