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 10:16:53 UTC
Struts 1.3 release naming
I have a humble suggestion, as 1.3 release seems to be eminent.
I've worked with 1.3 dev since January this year, on large projects,
too, and I think that the new chains design is worth a lot more than a
minor point release. We are getting GREAT bang from the new flexibility
this *major new feature* offers.
I've also seen the great amount of work that goes into this release.
To me, 1.3 should be called 2.0.
Hell, if you are scared about that, call it at least 1.5, but consider
to give it the merit it deserves.
What do you think?
I think it really deserves it. I know Struts versioning has always been
conservative, but I am not advocating to call it Struts 5 (like Java 5),
which might look too much like marketing. Here we are talking about the
real value this new version will provide.
Everyone wonders if Struts is dying. I don't think it is. With 1.3/"1.5"
it gets a major push as far as extensibility is concerned (which should
be a key role of any <i>framework</i>. With tweaking the struts chains,
creating a "Struby" (Ruby on Struts) would probably be the work of a fun
long weekend. Talk about extending the life of Struts, here it is.
Humbly, I think same goes for the label "Struts Classic", which I
personally gives it the image of old, which certainly 1.3 (1.5) does not
deserve. I think the label Struts Classic should be dropped. Marketing
uses "Classic" when they want to discourage people using it, and rather
buy something new. Or they blundered on something new. Neither is the
case here.
Also, would anyone want to step forward and be vocal about what is new
with Struts 1.3 ("1.5") in discussions like
http://www.theserverside.com/news/thread.tss?thread_id=37365 ?
Kind regards,
Wolfgang Gehner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Communication...
Posted by Wolfgang Gehner <ne...@infonoia.com>.
Yup, the true beauty of chains architecture and chain.xml is that it's
soo easy to blend out stuff you don't need in a particular extension or
configuration (and swap in other stuff), so you don't give anything away
by having Core as Core "for everything".
Of course the Core code needs to be in some module in SVN. But if the
core "module" is not core for pretty much everything it shouldn't have
been called core anyway.
Wolfgang
Marky Goldstein wrote:
> Hi Wolfgang,
>
> Maybe you are right and Core should be Core, and
> the rest should be Extensions.
>
> But if I look at the wegsite...
> http://struts.apache.org/
>
> I see that Core is one of many Subprojects on the
> same level such as Shales, Tiles, etc.
>
> If I read the text, it says...
> "Apache Struts is a hotbed of activity. Struts Classic 1.3, Struts
> Shale, Struts Ti, Struts OverDrive. Why so many frameworks? How are
> they different? Why are they all called Struts? Which is the best
> choice for my next project? In this session, we step back and look at
> Struts through a wide-angle lens."
>
> Hmm, yes, maybe the Struts movement should really discuss how
> things get communicated...
>
> Best regards,
> Marky
>
>
> Wolfgang Gehner wrote:
>
>> That's the thing, Ti, Shale are subprojects like Tiles, and should be
>> understood as such, which means keeping the naming of Struts CORE
>> strong. Here, the core has really evolved to a new version. And it's
>> a very strong core. Just comes to my mind that CORE could be read as
>> "Chain Of REsponsibility" :-)
>> So my afterthought is: wouldn't it be cool if I could say "We're
>> using Struts CORE with the XXX extension"
>> With CORE in capital letters. Or CORe? Either way, it would stand
>> for: Robust yet up to speed. Established yet pushing the envelope.
>> Using patterns yet being open. Also reflects the motivations for
>> moving to the new architecture.
>>
>> XXX could be Ti, Shale, some DAO, AJAX, RoR, whatever.
>>
>> Should have read ... 1.3 seems to be *imminent*...
>>
>> Wolfgang
>>
>> Marky Goldstein wrote:
>>
>>> As an "outsider" the marketing of Struts currently tells me that
>>> there are many cells of people working on different editions
>>> of Struts... Ti, Shale, Classic, etc.
>>>
>>> Yes, I guess that is confusing, and yes, propably those groups
>>> should come together to discuss if they have commons.
>>>
>>> Do you think that one day we will have THAT FRAMEWORK
>>> or we still have to decide on many different frameworks? Hmm,
>>> I don't think that a web application framework should be decided
>>> on the requriements. I think there should be one good one for all
>>> requirements that occur in 99% of all web applications.
>>>
>>> Best regards,
>>> Marky
>>>
>>> Wolfgang Gehner wrote:
>>>
>>>> I have a humble suggestion, as 1.3 release seems to be eminent.
>>>>
>>>> I've worked with 1.3 dev since January this year, on large
>>>> projects, too, and I think that the new chains design is worth a
>>>> lot more than a minor point release. We are getting GREAT bang from
>>>> the new flexibility this *major new feature* offers.
>>>>
>>>> I've also seen the great amount of work that goes into this release.
>>>>
>>>> To me, 1.3 should be called 2.0.
>>>>
>>>> Hell, if you are scared about that, call it at least 1.5, but
>>>> consider to give it the merit it deserves.
>>>>
>>>> What do you think?
>>>>
>>>> I think it really deserves it. I know Struts versioning has always
>>>> been conservative, but I am not advocating to call it Struts 5
>>>> (like Java 5), which might look too much like marketing. Here we
>>>> are talking about the real value this new version will provide.
>>>>
>>>> Everyone wonders if Struts is dying. I don't think it is. With
>>>> 1.3/"1.5" it gets a major push as far as extensibility is concerned
>>>> (which should be a key role of any <i>framework</i>. With tweaking
>>>> the struts chains, creating a "Struby" (Ruby on Struts) would
>>>> probably be the work of a fun long weekend. Talk about extending
>>>> the life of Struts, here it is.
>>>>
>>>> Humbly, I think same goes for the label "Struts Classic", which I
>>>> personally gives it the image of old, which certainly 1.3 (1.5)
>>>> does not deserve. I think the label Struts Classic should be
>>>> dropped. Marketing uses "Classic" when they want to discourage
>>>> people using it, and rather buy something new. Or they blundered on
>>>> something new. Neither is the case here.
>>>>
>>>> Also, would anyone want to step forward and be vocal about what is
>>>> new with Struts 1.3 ("1.5") in discussions like
>>>> http://www.theserverside.com/news/thread.tss?thread_id=37365 ?
>>>>
>>>> Kind regards,
>>>>
>>>> Wolfgang Gehner
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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 Communication...
Posted by Ted Husted <te...@gmail.com>.
We do discuss everything, right here, right now :)
Having a separate menu block for Frameworks and Extensions makes
sense, so I updated the site home page.
Once Struts Classic is available as a discrete entity, we might have
another for "Distributions", since that's what Struts Classic is, a
distribution of a set of subprojects (like a Linux distribution).
-Ted.
On 11/1/05, Marky Goldstein <re...@rosa.com> wrote:
> Hi Wolfgang,
>
> Maybe you are right and Core should be Core, and
> the rest should be Extensions.
>
> But if I look at the wegsite...
> http://struts.apache.org/
>
> I see that Core is one of many Subprojects on the
> same level such as Shales, Tiles, etc.
>
> If I read the text, it says...
> "Apache Struts is a hotbed of activity. Struts Classic 1.3, Struts
> Shale, Struts Ti, Struts OverDrive. Why so many frameworks? How are they
> different? Why are they all called Struts? Which is the best choice for
> my next project? In this session, we step back and look at Struts
> through a wide-angle lens."
>
> Hmm, yes, maybe the Struts movement should really discuss how
> things get communicated...
>
> Best regards,
> Marky
>
>
> Wolfgang Gehner wrote:
>
> > That's the thing, Ti, Shale are subprojects like Tiles, and should be
> > understood as such, which means keeping the naming of Struts CORE
> > strong. Here, the core has really evolved to a new version. And it's a
> > very strong core. Just comes to my mind that CORE could be read as
> > "Chain Of REsponsibility" :-)
> > So my afterthought is: wouldn't it be cool if I could say "We're using
> > Struts CORE with the XXX extension"
> > With CORE in capital letters. Or CORe? Either way, it would stand for:
> > Robust yet up to speed. Established yet pushing the envelope. Using
> > patterns yet being open. Also reflects the motivations for moving to
> > the new architecture.
> >
> > XXX could be Ti, Shale, some DAO, AJAX, RoR, whatever.
> >
> > Should have read ... 1.3 seems to be *imminent*...
> >
> > Wolfgang
> >
> > Marky Goldstein wrote:
> >
> >> As an "outsider" the marketing of Struts currently tells me that
> >> there are many cells of people working on different editions
> >> of Struts... Ti, Shale, Classic, etc.
> >>
> >> Yes, I guess that is confusing, and yes, propably those groups
> >> should come together to discuss if they have commons.
> >>
> >> Do you think that one day we will have THAT FRAMEWORK
> >> or we still have to decide on many different frameworks? Hmm,
> >> I don't think that a web application framework should be decided
> >> on the requriements. I think there should be one good one for all
> >> requirements that occur in 99% of all web applications.
> >>
> >> Best regards,
> >> Marky
> >>
> >> Wolfgang Gehner wrote:
> >>
> >>> I have a humble suggestion, as 1.3 release seems to be eminent.
> >>>
> >>> I've worked with 1.3 dev since January this year, on large projects,
> >>> too, and I think that the new chains design is worth a lot more than
> >>> a minor point release. We are getting GREAT bang from the new
> >>> flexibility this *major new feature* offers.
> >>>
> >>> I've also seen the great amount of work that goes into this release.
> >>>
> >>> To me, 1.3 should be called 2.0.
> >>>
> >>> Hell, if you are scared about that, call it at least 1.5, but
> >>> consider to give it the merit it deserves.
> >>>
> >>> What do you think?
> >>>
> >>> I think it really deserves it. I know Struts versioning has always
> >>> been conservative, but I am not advocating to call it Struts 5 (like
> >>> Java 5), which might look too much like marketing. Here we are
> >>> talking about the real value this new version will provide.
> >>>
> >>> Everyone wonders if Struts is dying. I don't think it is. With
> >>> 1.3/"1.5" it gets a major push as far as extensibility is concerned
> >>> (which should be a key role of any <i>framework</i>. With tweaking
> >>> the struts chains, creating a "Struby" (Ruby on Struts) would
> >>> probably be the work of a fun long weekend. Talk about extending the
> >>> life of Struts, here it is.
> >>>
> >>> Humbly, I think same goes for the label "Struts Classic", which I
> >>> personally gives it the image of old, which certainly 1.3 (1.5) does
> >>> not deserve. I think the label Struts Classic should be dropped.
> >>> Marketing uses "Classic" when they want to discourage people using
> >>> it, and rather buy something new. Or they blundered on something
> >>> new. Neither is the case here.
> >>>
> >>> Also, would anyone want to step forward and be vocal about what is
> >>> new with Struts 1.3 ("1.5") in discussions like
> >>> http://www.theserverside.com/news/thread.tss?thread_id=37365 ?
> >>>
> >>> Kind regards,
> >>>
> >>> Wolfgang Gehner
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
>
>
--
HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Struts Communication...
Posted by Marky Goldstein <re...@rosa.com>.
Hi Wolfgang,
Maybe you are right and Core should be Core, and
the rest should be Extensions.
But if I look at the wegsite...
http://struts.apache.org/
I see that Core is one of many Subprojects on the
same level such as Shales, Tiles, etc.
If I read the text, it says...
"Apache Struts is a hotbed of activity. Struts Classic 1.3, Struts
Shale, Struts Ti, Struts OverDrive. Why so many frameworks? How are they
different? Why are they all called Struts? Which is the best choice for
my next project? In this session, we step back and look at Struts
through a wide-angle lens."
Hmm, yes, maybe the Struts movement should really discuss how
things get communicated...
Best regards,
Marky
Wolfgang Gehner wrote:
> That's the thing, Ti, Shale are subprojects like Tiles, and should be
> understood as such, which means keeping the naming of Struts CORE
> strong. Here, the core has really evolved to a new version. And it's a
> very strong core. Just comes to my mind that CORE could be read as
> "Chain Of REsponsibility" :-)
> So my afterthought is: wouldn't it be cool if I could say "We're using
> Struts CORE with the XXX extension"
> With CORE in capital letters. Or CORe? Either way, it would stand for:
> Robust yet up to speed. Established yet pushing the envelope. Using
> patterns yet being open. Also reflects the motivations for moving to
> the new architecture.
>
> XXX could be Ti, Shale, some DAO, AJAX, RoR, whatever.
>
> Should have read ... 1.3 seems to be *imminent*...
>
> Wolfgang
>
> Marky Goldstein wrote:
>
>> As an "outsider" the marketing of Struts currently tells me that
>> there are many cells of people working on different editions
>> of Struts... Ti, Shale, Classic, etc.
>>
>> Yes, I guess that is confusing, and yes, propably those groups
>> should come together to discuss if they have commons.
>>
>> Do you think that one day we will have THAT FRAMEWORK
>> or we still have to decide on many different frameworks? Hmm,
>> I don't think that a web application framework should be decided
>> on the requriements. I think there should be one good one for all
>> requirements that occur in 99% of all web applications.
>>
>> Best regards,
>> Marky
>>
>> Wolfgang Gehner wrote:
>>
>>> I have a humble suggestion, as 1.3 release seems to be eminent.
>>>
>>> I've worked with 1.3 dev since January this year, on large projects,
>>> too, and I think that the new chains design is worth a lot more than
>>> a minor point release. We are getting GREAT bang from the new
>>> flexibility this *major new feature* offers.
>>>
>>> I've also seen the great amount of work that goes into this release.
>>>
>>> To me, 1.3 should be called 2.0.
>>>
>>> Hell, if you are scared about that, call it at least 1.5, but
>>> consider to give it the merit it deserves.
>>>
>>> What do you think?
>>>
>>> I think it really deserves it. I know Struts versioning has always
>>> been conservative, but I am not advocating to call it Struts 5 (like
>>> Java 5), which might look too much like marketing. Here we are
>>> talking about the real value this new version will provide.
>>>
>>> Everyone wonders if Struts is dying. I don't think it is. With
>>> 1.3/"1.5" it gets a major push as far as extensibility is concerned
>>> (which should be a key role of any <i>framework</i>. With tweaking
>>> the struts chains, creating a "Struby" (Ruby on Struts) would
>>> probably be the work of a fun long weekend. Talk about extending the
>>> life of Struts, here it is.
>>>
>>> Humbly, I think same goes for the label "Struts Classic", which I
>>> personally gives it the image of old, which certainly 1.3 (1.5) does
>>> not deserve. I think the label Struts Classic should be dropped.
>>> Marketing uses "Classic" when they want to discourage people using
>>> it, and rather buy something new. Or they blundered on something
>>> new. Neither is the case here.
>>>
>>> Also, would anyone want to step forward and be vocal about what is
>>> new with Struts 1.3 ("1.5") in discussions like
>>> http://www.theserverside.com/news/thread.tss?thread_id=37365 ?
>>>
>>> Kind regards,
>>>
>>> Wolfgang Gehner
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Posted by Wolfgang Gehner <ne...@infonoia.com>.
That's the thing, Ti, Shale are subprojects like Tiles, and should be
understood as such, which means keeping the naming of Struts CORE
strong. Here, the core has really evolved to a new version. And it's a
very strong core. Just comes to my mind that CORE could be read as
"Chain Of REsponsibility" :-)
So my afterthought is: wouldn't it be cool if I could say "We're using
Struts CORE with the XXX extension"
With CORE in capital letters. Or CORe? Either way, it would stand for:
Robust yet up to speed. Established yet pushing the envelope. Using
patterns yet being open. Also reflects the motivations for moving to the
new architecture.
XXX could be Ti, Shale, some DAO, AJAX, RoR, whatever.
Should have read ... 1.3 seems to be *imminent*...
Wolfgang
Marky Goldstein wrote:
> As an "outsider" the marketing of Struts currently tells me that
> there are many cells of people working on different editions
> of Struts... Ti, Shale, Classic, etc.
>
> Yes, I guess that is confusing, and yes, propably those groups
> should come together to discuss if they have commons.
>
> Do you think that one day we will have THAT FRAMEWORK
> or we still have to decide on many different frameworks? Hmm,
> I don't think that a web application framework should be decided
> on the requriements. I think there should be one good one for all
> requirements that occur in 99% of all web applications.
>
> Best regards,
> Marky
>
> Wolfgang Gehner wrote:
>
>> I have a humble suggestion, as 1.3 release seems to be eminent.
>>
>> I've worked with 1.3 dev since January this year, on large projects,
>> too, and I think that the new chains design is worth a lot more than
>> a minor point release. We are getting GREAT bang from the new
>> flexibility this *major new feature* offers.
>>
>> I've also seen the great amount of work that goes into this release.
>>
>> To me, 1.3 should be called 2.0.
>>
>> Hell, if you are scared about that, call it at least 1.5, but
>> consider to give it the merit it deserves.
>>
>> What do you think?
>>
>> I think it really deserves it. I know Struts versioning has always
>> been conservative, but I am not advocating to call it Struts 5 (like
>> Java 5), which might look too much like marketing. Here we are
>> talking about the real value this new version will provide.
>>
>> Everyone wonders if Struts is dying. I don't think it is. With
>> 1.3/"1.5" it gets a major push as far as extensibility is concerned
>> (which should be a key role of any <i>framework</i>. With tweaking
>> the struts chains, creating a "Struby" (Ruby on Struts) would
>> probably be the work of a fun long weekend. Talk about extending the
>> life of Struts, here it is.
>>
>> Humbly, I think same goes for the label "Struts Classic", which I
>> personally gives it the image of old, which certainly 1.3 (1.5) does
>> not deserve. I think the label Struts Classic should be dropped.
>> Marketing uses "Classic" when they want to discourage people using
>> it, and rather buy something new. Or they blundered on something new.
>> Neither is the case here.
>>
>> Also, would anyone want to step forward and be vocal about what is
>> new with Struts 1.3 ("1.5") in discussions like
>> http://www.theserverside.com/news/thread.tss?thread_id=37365 ?
>>
>> Kind 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
Posted by Marky Goldstein <re...@rosa.com>.
As an "outsider" the marketing of Struts currently tells me that
there are many cells of people working on different editions
of Struts... Ti, Shale, Classic, etc.
Yes, I guess that is confusing, and yes, propably those groups
should come together to discuss if they have commons.
Do you think that one day we will have THAT FRAMEWORK
or we still have to decide on many different frameworks? Hmm,
I don't think that a web application framework should be decided
on the requriements. I think there should be one good one for all
requirements that occur in 99% of all web applications.
Best regards,
Marky
Wolfgang Gehner wrote:
> I have a humble suggestion, as 1.3 release seems to be eminent.
>
> I've worked with 1.3 dev since January this year, on large projects,
> too, and I think that the new chains design is worth a lot more than a
> minor point release. We are getting GREAT bang from the new
> flexibility this *major new feature* offers.
>
> I've also seen the great amount of work that goes into this release.
>
> To me, 1.3 should be called 2.0.
>
> Hell, if you are scared about that, call it at least 1.5, but consider
> to give it the merit it deserves.
>
> What do you think?
>
> I think it really deserves it. I know Struts versioning has always
> been conservative, but I am not advocating to call it Struts 5 (like
> Java 5), which might look too much like marketing. Here we are talking
> about the real value this new version will provide.
>
> Everyone wonders if Struts is dying. I don't think it is. With
> 1.3/"1.5" it gets a major push as far as extensibility is concerned
> (which should be a key role of any <i>framework</i>. With tweaking the
> struts chains, creating a "Struby" (Ruby on Struts) would probably be
> the work of a fun long weekend. Talk about extending the life of
> Struts, here it is.
>
> Humbly, I think same goes for the label "Struts Classic", which I
> personally gives it the image of old, which certainly 1.3 (1.5) does
> not deserve. I think the label Struts Classic should be dropped.
> Marketing uses "Classic" when they want to discourage people using it,
> and rather buy something new. Or they blundered on something new.
> Neither is the case here.
>
> Also, would anyone want to step forward and be vocal about what is new
> with Struts 1.3 ("1.5") in discussions like
> http://www.theserverside.com/news/thread.tss?thread_id=37365 ?
>
> Kind regards,
>
> Wolfgang Gehner
>
>
> ---------------------------------------------------------------------
> 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 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 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 "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 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
Re: Struts 1.3 release naming - Struts CORE
Posted by Wolfgang Gehner <ne...@infonoia.com>.
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
Posted by Ted Husted <te...@gmail.com>.
On 11/1/05, Wolfgang Gehner <ne...@infonoia.com> wrote:
> To me, 1.3 should be called 2.0.
The thinking has been that so long as each release is backwardly
compatible with the last, then there is no reason to increment the
major version number.
A couple of things that might trigger incrementing the version number
would be rewriting the code base to the latest JVM (rather than the
one most people use). A "Struts Tiger" using Java 1.5 would be likely
candidate for Struts 2.x.
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.
But, as cool as 1.3 may be, it seems to be 100% backwardly compatible
with 1.2 (once deprecations are removed). The change to the request
processor is dramatic, but if you look back at what we did for 1.1 and
1.2, it's also evolutionary.
> Everyone wonders if Struts is dying. I don't think it is. With 1.3/"1.5"
> it gets a major push as far as extensibility is concerned (which should
> be a key role of any <i>framework</i>. With tweaking the struts chains,
> creating a "Struby" (Ruby on Struts) would probably be the work of a fun
> long weekend. Talk about extending the life of Struts, here it is.
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. :)
If someone is concerned with Struts longevity, the most helpful thing
might be to help us crank up the news and resources sections again.
Once upon a time, we were *the* source for all things Struts. Every
extension that came out, every article that was published, we
announced them all here. But, when Struts peaked, it just became too
much work to keep up with all the new announcements.
We have a few things liisted in the resource directory, but the wiki
pages we have now come no where close to exposing the extent of the
Struts industry.
* http://wiki.apache.org/struts/StrutsResources
I wish I could work on this myself, but there's still much to do with
the Struts 1.3 documentation, and I also want to get started on a
Struts Use Case project.
* http://opensource2.atlassian.com/confluence/oss/display/STRUTS/Struts+Classic
> Marketing uses "Classic" when they want to discourage people using it,
> and rather buy something new.
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.
I don't think anyone is married to the term "Classic", it's just that
no one's suggested another.
> Also, would anyone want to step forward and be vocal about what is new
> with Struts 1.3 ("1.5") in discussions like
> http://www.theserverside.com/news/thread.tss?thread_id=37365 ?
I tend to stay away from the ServerSide chats, but I did post a
comment to write in a +1 for Struts to the (somewhat silly) About.com
survey.
* http://forums.about.com/n/pfx/forum.aspx?nav=messages&tsn=1&tid=1584&webtag=ab-java
-- HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
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
Posted by Martin Cooper <ma...@apache.org>.
On 11/1/05, Wolfgang Gehner <ne...@infonoia.com> wrote:
>
> I have a humble suggestion, as 1.3 release seems to be eminent.
>
> I've worked with 1.3 dev since January this year, on large projects,
> too, and I think that the new chains design is worth a lot more than a
> minor point release. We are getting GREAT bang from the new flexibility
> this *major new feature* offers.
Much of the chain-based code is also available in 1.2.7 by using the
struts-chain component from the sandbox. What we did for 1.3 is bring that
into the core distribution (and a bunch of other stuff, of course). So
people (including myself) have been building chain-based apps for a while
now, without having to wait for 1.3.
What I'm getting at is that I don't see bringing a contrib package into the
mainstream, and expanding on it, as a major version increase, particularly
given that it doesn't make any noticeable difference to those who choose to
build their apps the "traditional" way.
--
Martin Cooper
I've also seen the great amount of work that goes into this release.
>
> To me, 1.3 should be called 2.0.
>
> Hell, if you are scared about that, call it at least 1.5, but consider
> to give it the merit it deserves.
>
> What do you think?
>
> I think it really deserves it. I know Struts versioning has always been
> conservative, but I am not advocating to call it Struts 5 (like Java 5),
> which might look too much like marketing. Here we are talking about the
> real value this new version will provide.
>
> Everyone wonders if Struts is dying. I don't think it is. With 1.3/"1.5"
> it gets a major push as far as extensibility is concerned (which should
> be a key role of any <i>framework</i>. With tweaking the struts chains,
> creating a "Struby" (Ruby on Struts) would probably be the work of a fun
> long weekend. Talk about extending the life of Struts, here it is.
>
> Humbly, I think same goes for the label "Struts Classic", which I
> personally gives it the image of old, which certainly 1.3 (1.5) does not
> deserve. I think the label Struts Classic should be dropped. Marketing
> uses "Classic" when they want to discourage people using it, and rather
> buy something new. Or they blundered on something new. Neither is the
> case here.
>
> Also, would anyone want to step forward and be vocal about what is new
> with Struts 1.3 ("1.5") in discussions like
> http://www.theserverside.com/news/thread.tss?thread_id=37365 ?
>
> Kind regards,
>
> Wolfgang Gehner
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>