See
* http://issues.apache.org/struts/browse/STR-2898
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+ 1 as well for Struts 1.x and 2.x
>> +1
>
> +1 to which? ;-)
>
> I'm for just calling them Struts 1.x and Struts 2.x, not the Struts2
> version 2.1 idea. We went through that for a while with WebWork, and it
> was confusing.
> -
>
I think everyone knows by now that this brevity is bad programming?
On 6/30/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
> Ted Husted wrote:
> > Though, there's no reason why we couldn't use
> >
> >> repos/asf/struts/struts1
> >> repos/asf/stru
Michael Jouravlev wrote:
Mua-ha-ha :-))
+1 on renaming back.
how about renaming back become WebWork :) hue hue...
so, we, the Webwork user dont have to refactor our job.
keep the WW 2.x become WW, and the WW 3.x become Struts 2.0
rather thatn right now, all of you make me wasting my time
u
I only have an inclination against s1/s2. Otherwise, struts/struts2 or
struts1/struts2 or action1/action2 is fine by me.
Ted Husted <[EMAIL PROTECTED]> wrote: On 6/30/06, Brett Porter
wrote:
> (from the peanut gallery)
>
> How about:
> repos/asf/struts/branches/struts-1.3/...
> repos/asf/struts
On 6/29/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
I am guessing the winner is going to be struts1/struts2
So if struts1 is:
org.apache.struts
If struts2:
org.apache.struts2
?
Yes, the other piece of surgery would be moving
http://svn.apache.org/viewvc/struts/action2/trunk/core/src/main/j
Greg Reddin sagely replied:
> On Jun 30, 2006, at 9:58 AM, Ted Husted wrote:
>
> > Now, in place of "Tapestry4" and "Tapestry5". we now have
> > "struts-action" and "struts-action2"
> >
> > * http://svn.apache.org/viewvc/struts/
> >
> > which we could just rename to "struts1" and "struts2".
>
>
On Jun 30, 2006, at 9:58 AM, Ted Husted wrote:
Now, in place of "Tapestry4" and "Tapestry5". we now have
"struts-action" and "struts-action2"
* http://svn.apache.org/viewvc/struts/
which we could just rename to "struts1" and "struts2".
That sounds good to me.
I was just asking if we want
On 6/30/06, Brett Porter <[EMAIL PROTECTED]> wrote:
(from the peanut gallery)
How about:
repos/asf/struts/branches/struts-1.3/...
repos/asf/struts/trunk (2.0, 2.1, 3.0 goes here)
Yep, and different teams have tried different approaches :)
Maven has maven-1 under the root
* http://svn.apache
If we do not have different package names, we cannot run both Struts 1 and
Struts 2 in the same web application. So it's very important to encode the
version into the pacakge structure. Otherwise, the migration path to Struts 2
is all or none. This is not a unique idea; this has been espoused by
(from the peanut gallery)
How about:
repos/asf/struts/branches/struts-1.3/...
repos/asf/struts/trunk (2.0, 2.1, 3.0 goes here)
It's not like you're the first project here to have had a 1.3 v 2.0 issue :)
http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/
Cheers,
Brett
On 30/06/06, T
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
Ted Husted wrote:
> Though, there's no reason why we couldn't use
>
>> repos/asf/struts/struts1
>> repos/asf/struts/struts2
>
> Or
>
>> repos/asf/struts/framework
>> repos/asf/struts/framework2
I like struts1/struts2.
Or, in the interest
Give it up! Lord! What nonsense. Do you hate versioning, Paul?
On 6/28/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
I am guessing the winner is going to be struts1/struts2
So if struts1 is:
org.apache.struts
If struts2:
org.apache.struts2
?
Niall Pemberton <[EMAIL PROTECTED]> wrote: On 6
Yah, engineers will understand this. In fact, the only people in the world
that seem to have trouble with it are Struts committers. The fact that
people can seriously debate the efficacy of standard versioning is amazing.
On 6/28/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
That's a good
Heh, yah, almost like real versioning, eh?
On 6/28/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
My two cents: I am okay with 1.x and 2.x numbering. It doesn't bother me.
I look at them in terms of generations; different people who can live
together in one family (webapp).
Michael Jouravlev <[E
Things will never be simple with MJ on the team. This is typical. Learn to
live with it.
On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
In this case we are returning to a half-year old situation, that is,
Struts 2 is a new crown holder of a single unified project. Consider
the annou
Heh, what about Struts? That might work? And, then, like the rest of the
world, you could have versions like 1.* and 2.*, and 3.*. Oh, that was the
proposal which the newly knighted can't seem to stomach. Too rational.
On 6/28/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
I am very much agai
Heh, you voted him in. He is all yours.
On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts
2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version
4.0
:-)
2.0 is a version number, while we are choosing
God yes, Don. Please don't let them go nuts again. Here you are in the
reach of sanity. Stay the course!
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
I'm against "official" code names. We have had enough confusion in Struts
with
different names meaning different things, and we shouldn't
> +1
+1 to which? ;-)
I'm for just calling them Struts 1.x and Struts 2.x, not the Struts2 version
2.1 idea. We went through that for a while with WebWork, and it was confusing.
-
Posted via Jive Forums
http://forums.opensymphon
+1
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=35827&messageID=70400#70400
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
On 6/28/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
The key I think is making it clear that 2.x really is something new
Yes, if you look at the Migration Guide
* http://struts.apache.org/struts-action2/docs/Migration%20Guide.html
three of the four strategies involve either leaving S1 cod
I am guessing the winner is going to be struts1/struts2
So if struts1 is:
org.apache.struts
If struts2:
org.apache.struts2
?
Niall Pemberton <[EMAIL PROTECTED]> wrote: On 6/29/06, Don Brown wrote:
>
> I like struts1/struts2.
+1
Niall
> Don
-
On 6/29/06, Don Brown <[EMAIL PROTECTED]> wrote:
I like struts1/struts2.
+1
Niall
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 6/28/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
> Ted Husted wrote:
> > Though, there's no reason why we couldn't use
> >
> >> repos/asf/struts/struts1
> >> repos/asf/struts/struts2
> >
> > Or
> >
> >> repos/asf/struts/framework
> >>
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
Ted Husted wrote:
> Though, there's no reason why we couldn't use
>
>> repos/asf/struts/struts1
>> repos/asf/struts/struts2
>
> Or
>
>> repos/asf/struts/framework
>> repos/asf/struts/framework2
I like struts1/struts2.
Yep, I do too. It
On 6/28/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
Why does having the departure of Shale instigate nomenclature madness? :-)
Struts Action Framework is actually a very professional title and I prefer we
keep it as is.
When Shale arrived, we tried various ways to differentiate the
original
That's a good point Michael. My answer to it would be that it's just
something we have to live with.
Paul used the term "generation" to differentiate Struts 1.x from 2.x...
to me though, "generation" has the same connotation as does "classic".
I don't think there's any real contradiction tho
My two cents: I am okay with 1.x and 2.x numbering. It doesn't bother me. I
look at them in terms of generations; different people who can live together in
one family (webapp).
Michael Jouravlev <[EMAIL PROTECTED]> wrote: In this case we are returning to a
half-year old situation, that is,
Stru
In this case we are returning to a half-year old situation, that is,
Struts 2 is a new crown holder of a single unified project. Consider
the announcements like this:
"Struts team is proud to announce immediate availability of Struts 2.0
as a next version of popular Struts framework. New features
I am very much against naming 1.x "Classic" . I think it's a horrible name. I
think of classical music, classic cars, and anything that smells of belonging
in a museum (stationary, old, idle, doesn't move, better looked at than used).
Why do we need it? I am totally fond of action and action2. W
I propose code names Velvet and Rubert. Any objections?
Michael Jouravlev <[EMAIL PROTECTED]> wrote: Mua-ha-ha :-))
+1 on renaming back.
Also, hoping not to hijaack this thread I would suggest coming up with
codenames for 1.x and 2.x codebases. This had been suggested and
discussed long ago but
Did I miss something? :-) Perhaps the deliberations went on in private, because
it's news to me!!! Congrats on Shale blossoming into its own project.
Don Brown <[EMAIL PROTECTED]> wrote: With the departure of Struts Shale, I
think it is time we return to the idea of
Struts as a single, unified
I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1,
etc... The whole point of this proposal is to unify Struts as a single project,
getting away from this concept of separately versioned "subprojects". There
will be Struts 1.x releases, and there will be Struts 2.x rele
You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts
2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version
4.0
:-)
2.0 is a version number, while we are choosing project names (Are we?)
Do we treat Struts2 as the next version, or do we treat Struts and
Struts2 as
Ted Husted wrote:
Though, there's no reason why we couldn't use
repos/asf/struts/struts1
repos/asf/struts/struts2
Or
repos/asf/struts/framework
repos/asf/struts/framework2
I like struts1/struts2.
Don
-Ted.
-
Big +1. I just wish we could have done it months ago when I (and
others) said exactly the same thing. Oh well, better late then never.
Frank
Don Brown wrote:
With the departure of Struts Shale, I think it is time we return to the
idea of Struts as a single, unified framework. While I had ho
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
> What do you think of...
>
> repos/asf/struts/struts
> repos/asf/struts/struts2
Very true, I forgot that we have different directories for SAF1 and SAF2. The
struts/struts is redundant, but I could live with that.
But ViewVC might not :)
+1 for Struts 2.0
Bob
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
With the departure of Struts Shale, I think it is time we return to the
idea of
Struts as a single, unified framework. While I had hoped we could do this
by
including Shale, everyone involved felt Shale deserved its own pr
I'm against "official" code names. We have had enough confusion in Struts with
different names meaning different things, and we shouldn't pile on more names.
If folks want to off-hand use code names, that's fine, but to have them used in
code or documentation is too far. Version 1 and 2 are si
On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
Also, hoping not to hijaack this thread I would suggest coming up with
codenames for 1.x and 2.x codebases.
If we were to do that, the obvious choices would be Classic for 1.x
and Action for 2.x.
-Ted.
--
Wendy Smoak wrote:
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
2. We rename the https://svn.apache.org/repos/asf/struts/action
subversion
directory as https://svn.apache.org/repos/asf/struts/framework, keep
the other
top level directories the same
What do you think of...
repos/asf
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
2. We rename the https://svn.apache.org/repos/asf/struts/action subversion
directory as https://svn.apache.org/repos/asf/struts/framework, keep the other
top level directories the same
What do you think of...
repos/asf/struts/struts
repos
Mua-ha-ha :-))
+1 on renaming back.
Also, hoping not to hijaack this thread I would suggest coming up with
codenames for 1.x and 2.x codebases. This had been suggested and
discussed long ago but was rejected.
Why codenames make sense:
* Job search. SAF1 and SAF2... oh... I mean, Struts 1.x and
With the departure of Struts Shale, I think it is time we return to the idea of
Struts as a single, unified framework. While I had hoped we could do this by
including Shale, everyone involved felt Shale deserved its own project and so
I'm adjusting my original Struts 2.0 proposal to simply rena
45 matches
Mail list logo
