Site generation issue

[Niall Pemberton]

There seems to be a problem with the site generation and lists - maven
doesn't like the list of shale pmc members :-o

I just added the Shale announcment, but the  list seems to screw
up the following paragraphs. If you have one item in the list its all
OK, 2 and one of the paragraphs disappears, 3 and 2 paras disappear
etc etc.

Can't see anything that looks wrong and the same thing is happening
for the "Apache Struts to release Struts 1.3.0 as the Action
Framework" announcement (so obviously its not personal to the shale
pmc :-)

 http://struts.apache.org/announce-2005.html#a20051214.4

Any ideas? I bumped up from maven 2.0.2 to 2.0.4, but it didn't make a
difference.

Niall

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Rename Struts Action as Struts

[Ted Husted]

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 code alone or
reworking it for S2.

In my own experience, the rework is mild and mainly involves
substituting this for that or leaving something out altogether
(because it isn't needed any more).

I've set aside July to work on nothing but wrapping up a Struts 2.0.0
distribution and addressing migration issues. Migration is a key
concern to me, because, like everyone else, I've a lot of S1 knowhow
that I want to apply to S2.  Happily, I am finding that S1 experience
does translate directly to S2.

To help keep migration on the front-burner, in addition to the free
online resources, I'm also holding a live five-day migration workshop
in mid-August, and I put in for a two-day migration tutorial for
ApacheCon in October (if they accept it).)

In terms of aplication test-cases, aside from the usual suspects, a
friend of mine has a model-one scriptlet-based application that he
would like to make open source and migrate to S2.

* http://sectionxsports.com/

The problem domain is providing Sports information about youth sports
teams. Should make for an interesting "example" application. :)

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Thoughts on 1.3.x

[Joe Germuska]

At 5:34 PM -0700 6/28/06, Paul Benedict wrote:

I have two concerns on the 1.3.x line. What do you think?

1) Spring 2.0 has fabulous support for dependency injection for 
Struts. In particular, the great Autowiring(Tiles)RequestProcessor 
will automatically inject dependencies into the actions as they are 
created. This supports the "legacy" RequestProcessor and I have no 
personal plans to depart from its use. So my question today is: does 
the RP in 1.3 function just as it did in 1.2? If not, I may not want 
to upgrade to 1.3.x until it does.


You can use an AutowiringRequestProcessor in Struts 1.3, but you will 
not gain any behavior which has only been implemented in commands 
since Struts 1.2.  Specifically, any action mapping or forward 
mapping can specify a chain command which should be executed as part 
of processing.


As far as I can remember (but don't bet money), none of the other 
major functional changes in 1.3 are in the chain commands only.  You 
could probably go for a while using some other subclass of 
RequestProcessor instead of ComposableRequestProcessor, but I think 
everyone is on board in general with deprecating the original request 
processing functionality, so over time, this statement is likely to 
become less true.


Also, as Frank noted, it is pretty easy to write custom commands that 
get actions in a different way, and in fact, in general, the whole 
point of this is that it is much easier now to make changes to the 
request processing cycle without having to have an infinite 
combination of request processor classes which all have different 
lineages depending on whether you want or don't want Tiles 
processing, want or don't want X, want or don't want Y, etc.


Admittedly, if lots of people embrace casually changing the RP chain, 
we will have some work to do in making that a little more 
straightforward, but it's far from a huge burden now.


2) I learned the tough way that it is [a] impossible to write a 
stateless application in Struts and [b] use Struts' locality 
features at the same time. This is because Struts only stores the 
locale in the session, and there is no way (currently) to move that 
into a cookie, or into request scope. I found scattered code among 
RequestProcessor, RequestUtils and TaglibUtils which look only into 
the session for the current locale.


I propose (and I will write this) that we allow pluggable 
implementations into how to store the locale. It will be defaulted 
into the session, with other pluggable implementations provided. 
However (sorry fans of CoR) this implementation must be wrapped into 
a bean so that other libraries, like Tiles and Taglibs, can retrieve 
the locale and set it without knowing the pluggable strategy. So the 
solution itself cannot be limited to the RP chain, even though that 
is where it is initiated.


I don't see any problem with that.  Being a fan of the composable 
request processor isn't the same as being a zealot who wants the CRP 
to do everything!


I think this just raises one of the fundamental weaknesses of Struts 
1.x - the lack of a dependency injection management system leaves the 
process of setting up services for use by multiple components in a 
fragile and awkward state.  I have really soured on the idea that 
everything should just be thrown into the ServletContext to be found 
by whomever needs it.


That said, I don't think you should not do the work you describe, 
just because you may have to leave the Localizer (or whatever you 
call it) in the ServletContext under a well known key.  It's just 
that it feels so outdated!


Joe

--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com


"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
-- Robert Moog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposal for Struts 1.x: support for portlet-like components

[Michael Jouravlev]

On 6/28/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:

Michael Jouravlev wrote:
> Do you mean by building DispatchCommand or DialogCommand? And then
> slapping this command onto the chain... but I can replace Action as
> well. Oh I see, Action is not an interface, but Command is. Always
> keep forgetting this. I will think about it. Thanks!

Pretty much, yes (although I don't know the precise details of how you'd
implement your work in the chain, I just very much suspect it's almost
trivial).  It's less about a Command being an interface though and more
about the fact that there is an infrastructure that allows you to add
steps to the processing chain with ease.  You used to have to do this by
either subclassing the RP or Action, or maybe other things.  Now, you
just write a simple Command and modify the chain.  It's one of those
incredibly simple and obvious things that leads to great power :)


Anyway, whether Commands or Actions, I would also like to expose new
functionality in struts-config.xml file. This involves changes to DTD.
I want these features to be treated by users as an integral part of a
new release, not as a bold-on solution that uses either clumsy
"parameter" attribute or custom properties of action mapping. I want
to make events and components a core part of framework. Yes, there is
probably more marketing to it than real necessity. Yes, I can screw my
stuff together with current codebase, event with 1.2.9. But framework
will feel more integrated if new features will be treated as real core
features. Perception is a great thing. But it is not just perception,
the code is really cleaner and simpler if the features are pushed to
base Action. No plubming code in custom actions, no custom properties
in mapping.

As to having infinite possibilities with combining different Commands,
I believe that most developers do not need inifinite flexibility. They
need base use cases covered with maximum ease and simplicity. And if
they do need something different, then hey, MY PROPOSAL DOES NOT LIMIT
THEM MORE THAN THEY ARE LIMITED NOW. Sorry for shouting, seems that I
haven't stressed this enough :-)

I guess that many question not only the necessitiy of component
support in Struts1, but the very choice of it. Why my code, why not
somebody else's? Because it is here, it works, proven and I am willing
to support it, both the code and the docs.

I don't buy the idea that Struts1 should be just a bare controller in
chains, and everything else should be a bolt-on. This would not differ
much from customising standard servlets.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where's Waldo?

[Wendy Smoak]

On 6/23/06, Ted Husted <[EMAIL PROTECTED]> wrote:

I'll be heads-down for the rest of June finishing up a contract, but
I'll be back come July 5, ready to wrap up Struts Action 1.3.5 (if no
one beats me to it). I've the rest of July blocked out to work on SAF
2.0.0 documentation and remaining code issues.


Thanks, Ted.  I'm probably out until mid-July as far as releases.
I'll try to get to the little things that need to be done in advance
of 1.3.5, such as releasing an updated struts-parent pom and a new
struts-build jar with the Checkstyle changes.

Speaking of the Struts 2.0 documentation, would it be possible to get
Confluence to send plain text diffs to [EMAIL PROTECTED]  I feel like I'm
missing a lot of information by not seeing the changes go by.

--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Rename Struts Action as Struts

[Patrick Lightbody]

+1
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=35827&messageID=70400#70400


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OGNL - Getter and setter types must match

[Peter Pilgrim]

Laurie Harper wrote:
The restriction comes from the Java relection API semantics, not OGNL. A 
property can only have one type, so it makes sense that the getter and 
setter for a JavaBean property must agree on that type. Changing this 
would break compatibility with the JavaBean specification, at the least...


L.


The other thing that you can get in to trouble for with OGNL I discovered months 
ago way that you cannot perform reference setting. I was at the time 
retrofitting an old Hibernate example with WebWork for testing.


Consider this class

class A {
private int f;
private double b;

public A setF( int f ) {
this.f  = f; return this;
}
public A setG( int g ) {
this.g  = g; return this;
}
}

The reference setters are not strict JavaBean setters because those do not 
return any type (e.g void). Therefore OGNL fails with class A.


====

--
Peter Pilgrim  ( Windows XP / Thunderbird 1.5 )

_ ___  + Expert Java
__  /_ ___   ___ ____  /__  /  + Enterprise
___ _  /_  __ `/_ | / /  __ `/__  __/  __  __/ + Design
/ /_/ / / /_/ /__ |/ // /_/ / _  /___  _  /___ + Architecture
\/  \__,_/ _/ \__,_/  /_/  /_/ + Web New Age

On Line Resume
   ||
   \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Rename Struts Action as Struts

[Jason Carreira]

> +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.opensymphony.com/thread.jspa?threadID=35827&messageID=70436#70436


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Struts problem on reload...

[Andy Lewis]

The team I work with has encountered an apparent problem with Struts 
when the servlet is reloaded by the container. We are using Weblogic 
9.1, but the problem appear to happen on other versions, and possibly 
other containers. The spec does not appear to be clear regarding the 
ServletContext behavior across servlet instances, and in the case of 
Weblogic 9.1, it appears to fully preserve the ServletContext. The 
problem we are having is that the RequestProcessor instances stored in 
the ServletContext are destroyed when the ActionServlet is destroyed, 
but they are not removed from the ServletContext. As a result, when a 
new servlet is created with the same context, it finds the 
RequestProcessors already existing, but they have a null reference to 
the servlet (since their respective destroy method was called). As a 
result any attempt to get to the Servlet resources, such as the 
ServletContext, results in a NullPointerException in the RequestProcessor.


Even the latest version appears to do this. Google searches on the 
problem reveal other users have had the problem, and even a patch/hack 
that resets the servlet variable in the RequestProcessor every time it 
is accessed. There is also an existing open issue () on JRun that may be 
the same problem.


A simple one line addition to the Servlet destroy code to remove the 
destroyed RequestProcessor from the ServletContext fixes the problem.


Is anyone familiar with this issue and can valid or correct my 
understanding? And If I am correct in my understanding, is this 
something I should submit the one line patch for? I've not had the 
opportunity to contribute to struts before, and little to any project as 
much as I'd like to.


Any comments, feedback, corrections, validations, etc, would be appreciated.


Thanks!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where's Waldo?

[Ted Husted]

On 6/29/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:

Thanks, Ted.  I'm probably out until mid-July as far as releases.
I'll try to get to the little things that need to be done in advance
of 1.3.5, such as releasing an updated struts-parent pom and a new
struts-build jar with the Checkstyle changes.


That would be great!


Speaking of the Struts 2.0 documentation, would it be possible to get
Confluence to send plain text diffs to [EMAIL PROTECTED]  I feel like I'm
missing a lot of information by not seeing the changes go by.


The blow-by-blow Confluence emails are noisy, and no where near as
concise as what Subversion logs. If I edit twenty pages, then it's
twenty *individual* alerts, and they don't really tell you want
changed unless you click thru to the site.

One idea would be to check in the HTML into the repository when we
post it to the website, so that it all comes from Subversion.

We could also setup a "list" user that is subscribed for the daily
summary, and have that sent to the list, so there is a timely (but not
obnoxious) alert as well.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where's Waldo?

[Frank W. Zammetti]

Ted Husted wrote:

On 6/29/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:

Thanks, Ted.  I'm probably out until mid-July as far as releases.
I'll try to get to the little things that need to be done in advance
of 1.3.5, such as releasing an updated struts-parent pom and a new
struts-build jar with the Checkstyle changes.


That would be great!


FYI, the first batch of Checkstyle changes should be posted in JIRA in 
the next few days (maybe even tonight)... I did the simple stuff first, 
I'll tackle the more time-consuming and labor-intensive stuff after 
these are applied.


Frank

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts problem on reload...

[Paul Benedict]

Andy:

Use this as your action servlet instead:
http://struts.apache.org/struts-doc-1.2.9/api/org/apache/struts/actions/RedeployableActionServlet.html

Paul

Andy Lewis <[EMAIL PROTECTED]> wrote: The team I work with has encountered an 
apparent problem with Struts 
when the servlet is reloaded by the container. We are using Weblogic 
9.1, but the problem appear to happen on other versions, and possibly 
other containers. The spec does not appear to be clear regarding the 
ServletContext behavior across servlet instances, and in the case of 
Weblogic 9.1, it appears to fully preserve the ServletContext. The 
problem we are having is that the RequestProcessor instances stored in 
the ServletContext are destroyed when the ActionServlet is destroyed, 
but they are not removed from the ServletContext. As a result, when a 
new servlet is created with the same context, it finds the 
RequestProcessors already existing, but they have a null reference to 
the servlet (since their respective destroy method was called). As a 
result any attempt to get to the Servlet resources, such as the 
ServletContext, results in a NullPointerException in the RequestProcessor.

Even the latest version appears to do this. Google searches on the 
problem reveal other users have had the problem, and even a patch/hack 
that resets the servlet variable in the RequestProcessor every time it 
is accessed. There is also an existing open issue () on JRun that may be 
the same problem.

A simple one line addition to the Servlet destroy code to remove the 
destroyed RequestProcessor from the ServletContext fixes the problem.

Is anyone familiar with this issue and can valid or correct my 
understanding? And If I am correct in my understanding, is this 
something I should submit the one line patch for? I've not had the 
opportunity to contribute to struts before, and little to any project as 
much as I'd like to.

Any comments, feedback, corrections, validations, etc, would be appreciated.


Thanks!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Want to be your own boss? Learn how on  Yahoo! Small Business. 

[shale] Genericizing Cargo-Based Integration Tests

[Craig McClanahan]

The CargoTestSetup class that you added to the test framework (was this
Wendy's first commit of Java code?  :-) nicely leverages the fact that Cargo
will figure out which container to use based on system properties
(specifically "cargo.container.id").  However, the way that this class is
being used in Tomcat5xWelcomeTestCase in the shale-blank application is
definitely not container-agnostic, because it presumes to use Tomcat 5.x.
I'd like to write our tests so that they dynamically adapt to whatever Cargo
Container the user has selected in their ~/.m2/settings.xml file.

So, the question is, does the following strategy make sense?

* Set up default cargo properties in the POM for a particular application
(defauting to "tomcat5x" makes sense).

* Allow the user to override these by setting up their favorite container in
~/.m2/settings.xml (presumes
 that user settings override POM settings)

* Change the shale-blank tests to not bother trying to pass through any
Tomcat specific properties --
 instead, they should assume that all the required "cargo.*" propertes have
been set up by the
 surrounding environment already.

If this works out, it will make sense to replicate this model in the other
apps that have integration tests, as well as into the archetype(s) for new
applications.

Craig

DO NOT REPLY [Bug 18032] - [taglib] tag appending session doesn't work with apache setup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=18032





--- Additional Comments From [EMAIL PROTECTED]  2006-06-30 03:37 ---
I think this attribute is absolutely justified. There are plenty of users who 
have faced this problem and were forced to modify the source code by 
themselves or to use mod_rewrite in case of Apache. Myself I switched to the 
general  html tag instead of  which isn't a pretty solution 
either.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Site generation issue

[Wendy Smoak]

On 6/29/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:


There seems to be a problem with the site generation and lists - maven
doesn't like the list of shale pmc members :-o

I just added the Shale announcment, but the  list seems to screw
up the following paragraphs. If you have one item in the list its all
OK, 2 and one of the paragraphs disappears, 3 and 2 paras disappear
etc etc.


(Thanks for posting the announcement!)  Interesting.  The text is
there, it's just missing the  tags.  This is likely to be in
maven-site-plugin, not Maven itself, but I did 'mvn site -U' and still
see it, so it's there in the latest version.

I went ahead and published the site, (will take about an hour to
sync.)  It's probably worth opening an issue against the site plugin
with a pointer to the xdoc and resulting html page.
* http://jira.codehaus.org/browse/MSITE

--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Site generation issue

[Niall Pemberton]

On 6/30/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:

On 6/29/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:

> There seems to be a problem with the site generation and lists - maven
> doesn't like the list of shale pmc members :-o
>
> I just added the Shale announcment, but the  list seems to screw
> up the following paragraphs. If you have one item in the list its all
> OK, 2 and one of the paragraphs disappears, 3 and 2 paras disappear
> etc etc.

(Thanks for posting the announcement!)  Interesting.  The text is
there, it's just missing the  tags.  This is likely to be in
maven-site-plugin, not Maven itself, but I did 'mvn site -U' and still
see it, so it's there in the latest version.

I went ahead and published the site, (will take about an hour to
sync.)  It's probably worth opening an issue against the site plugin
with a pointer to the xdoc and resulting html page.
 * http://jira.codehaus.org/browse/MSITE


Great, thanks for this - I went to the maven site but couldn't find
where to post an issue - I have a really simple test page which shows
exactly whats going wrong - so I'll upload that to a Jira issue.

In the meantime I found that putting a load (1 for each entry in list)
of empy  statements after the list sorts it out - I could do
this temporarily to make it look nice, but then again theres at least
one other place in the site that does this and I bet theres a whole
lot more - so maybe waiting to see what happens with raising a Jira
issue is best thing for now.

Niall



--
Wendy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Rename Struts Action as Struts

[Dakota Jack]

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 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 simple enough.

Don

Ted Husted wrote:
> 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.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: [PROPOSAL] Rename Struts Action as Struts

[Dakota Jack]

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 project names (Are we?)
Do we treat Struts2 as the next version, or do we treat Struts and
Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ?
(Obviously I prefer the latter)
How version numbers correspond to project names?
Can Struts 2 subproject have version number higher than 2.x? (I think yes)
Can Struts [implied: 1] have version numbers higher than 1.x?
(theoretically yes, but that would be bizzare)

On 6/28/06, Bob Lee <[EMAIL PROTECTED]> wrote:
> +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 project
and
> > so
> > I'm adjusting my original Struts 2.0 proposal to simply rename Struts
> > Action as
> > Struts.
> >
> > The ramifications of such a renaming up for discussion:
> >   1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0becomes
> > Struts 2.0
> >   2. We rename the
https://svn.apache.org/repos/asf/struts/actionsubversion
> > directory as https://svn.apache.org/repos/asf/struts/framework, keep
the
> > other
> > top level directories the same
> >   3. The org.apache.struts.action2 package becomes org.apache.struts2
> >   4. action.* and struts-action.* configuration files become struts.*
> >   5. The SAF acronym in the documentation would return to Struts
> >
> > Given all the product naming changes in the last few years (much of
which
> > was my
> > fault, I admit), I'd like to have these changes decided on soon, so we
can
> > move
> > on to getting Struts 2.0 out the door.
> >
> > Don
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: [PROPOSAL] Rename Struts Action as Struts

[Dakota Jack]

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

Ted Husted <[EMAIL PROTECTED]> wrote: On 6/28/06, Michael
Jouravlev  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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
countries) for 2¢/min or less.





--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: [PROPOSAL] Rename Struts Action as Struts

[Dakota Jack]

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 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 include
... "

and then:

"Struts team releases Struts 1.4, the next version of popular Struts
framework. New features include ... "

Things have not got simpler after divorce :)

I suppose that having Struts 2 as the next version works for you. But
I afraid that it does not work well for those who think about
releasing new versions of 1.x codebase.

So, maybe Win9x vs. WinNT is not that bad idea after all? And look at
them now, united. Now not only former NT users wait for Vista, but
former 9x users too :-))

On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
> 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 releases, and
perhaps
> some day, Struts 3.x releases.
>
> Don
>
> Michael Jouravlev 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 project names (Are we?)
> > Do we treat Struts2 as the next version, or do we treat Struts and
> > Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ?
> > (Obviously I prefer the latter)
> > How version numbers correspond to project names?
> > Can Struts 2 subproject have version number higher than 2.x? (I think
yes)
> > Can Struts [implied: 1] have version numbers higher than 1.x?
> > (theoretically yes, but that would be bizzare)
> >
> > On 6/28/06, Bob Lee <[EMAIL PROTECTED]> wrote:
> >> +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
> >> project and
> >> > so
> >> > I'm adjusting my original Struts 2.0 proposal to simply rename
Struts
> >> > Action as
> >> > Struts.
> >> >
> >> > The ramifications of such a renaming up for discussion:
> >> >   1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0becomes
> >> > Struts 2.0
> >> >   2. We rename the
> >> https://svn.apache.org/repos/asf/struts/actionsubversion
> >> > directory as https://svn.apache.org/repos/asf/struts/framework,
keep
> >> the
> >> > other
> >> > top level directories the same
> >> >   3. The org.apache.struts.action2 package becomes
org.apache.struts2
> >> >   4. action.* and struts-action.* configuration files become
struts.*
> >> >   5. The SAF acronym in the documentation would return to Struts
> >> >
> >> > Given all the product naming changes in the last few years (much of
> >> which
> >> > was my
> >> > fault, I admit), I'd like to have these changes decided on soon, so
> >> we can
> >> > move
> >> > on to getting Struts 2.0 out the door.
> >> >
> >> > Don
> >> >
> >> >
-
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: [PROPOSAL] Rename Struts Action as Struts

[Dakota Jack]

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 <[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 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 include
... "

and then:

"Struts team releases Struts 1.4, the next version of popular Struts
framework. New features include ... "

Things have not got simpler after divorce :)

I suppose that having Struts 2 as the next version works for you. But
I afraid that it does not work well for those who think about
releasing new versions of 1.x codebase.

So, maybe Win9x vs. WinNT is not that bad idea after all? And look at
them now, united. Now not only former NT users wait for Vista, but
former 9x users too :-))

On 6/28/06, Don Brown  wrote:
> 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 releases, and
perhaps
> some day, Struts 3.x releases.
>
> Don
>
> Michael Jouravlev 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 project names (Are we?)
> > Do we treat Struts2 as the next version, or do we treat Struts and
> > Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ?
> > (Obviously I prefer the latter)
> > How version numbers correspond to project names?
> > Can Struts 2 subproject have version number higher than 2.x? (I think
yes)
> > Can Struts [implied: 1] have version numbers higher than 1.x?
> > (theoretically yes, but that would be bizzare)
> >
> > On 6/28/06, Bob Lee  wrote:
> >> +1 for Struts 2.0
> >>
> >> Bob
> >>
> >> On 6/28/06, 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 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 rename
Struts
> >> > Action as
> >> > Struts.
> >> >
> >> > The ramifications of such a renaming up for discussion:
> >> >   1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0becomes
> >> > Struts 2.0
> >> >   2. We rename the
> >> https://svn.apache.org/repos/asf/struts/actionsubversion
> >> > directory as https://svn.apache.org/repos/asf/struts/framework,
keep
> >> the
> >> > other
> >> > top level directories the same
> >> >   3. The org.apache.struts.action2 package becomes
org.apache.struts2
> >> >   4. action.* and struts-action.* configuration files become
struts.*
> >> >   5. The SAF acronym in the documentation would return to Struts
> >> >
> >> > Given all the product naming changes in the last few years (much of
> >> which
> >> > was my
> >> > fault, I admit), I'd like to have these changes decided on soon, so
> >> we can
> >> > move
> >> > on to getting Struts 2.0 out the door.
> >> >
> >> > Don
> >> >
> >> >
-
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Yahoo! Music Unlimited - Access over 1 million songs.Try it free.





--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: [PROPOSAL] Rename Struts Action as Struts

[Dakota Jack]

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 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 though... you use the Win9x
  vs. WinNT comparison, and I think that's apt... they are both Windows
in the end, just like both "generations", or whatever, would still be
"Struts".  Microsoft sometimes does back-port features... I don't think
there's any difference between that and continuing to evolve 1.x and 2.x
at the same time.

The key I think is making it clear that 2.x really is something new, and
I personally suspect largely incompatible in terms of migrating existing
apps to it... if that winds up being true, then people are going to be
very happy that 1.x continues to evolve, and I doubt it will be
confusing if it's explained well.

Frank

Michael Jouravlev 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 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 include
> ... "
>
> and then:
>
> "Struts team releases Struts 1.4, the next version of popular Struts
> framework. New features include ... "
>
> Things have not got simpler after divorce :)
>
> I suppose that having Struts 2 as the next version works for you. But
> I afraid that it does not work well for those who think about
> releasing new versions of 1.x codebase.
>
> So, maybe Win9x vs. WinNT is not that bad idea after all? And look at
> them now, united. Now not only former NT users wait for Vista, but
> former 9x users too :-))
>
> On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
>> 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 releases,
>> and perhaps
>> some day, Struts 3.x releases.
>>
>> Don
>>
>> Michael Jouravlev 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 project names (Are
we?)
>> > Do we treat Struts2 as the next version, or do we treat Struts and
>> > Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ?
>> > (Obviously I prefer the latter)
>> > How version numbers correspond to project names?
>> > Can Struts 2 subproject have version number higher than 2.x? (I
>> think yes)
>> > Can Struts [implied: 1] have version numbers higher than 1.x?
>> > (theoretically yes, but that would be bizzare)
>> >
>> > On 6/28/06, Bob Lee <[EMAIL PROTECTED]> wrote:
>> >> +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
>> >> project and
>> >> > so
>> >> > I'm adjusting my original Struts 2.0 proposal to simply rename
>> Struts
>> >> > Action as
>> >> > Struts.
>> >> >
>> >> > The ramifications of such a renaming up for discussion:
>> >> >   1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0
>> becomes
>> >> > Struts 2.0
>> >> >   2. We rename the
>> >> https://svn.apache.org/repos/asf/struts/actionsubversion
>> >> > directory as https://svn.apache.org/repos/asf/struts/framework,
keep
>> >> the
>> >> > other
>> >> > top level directories the same
>> >> >   3. The org.apache.struts.action2 package becomes
>> org.apache.struts2
>> >> >   4. action.* and struts-action.* configuration files become
>> struts.*
>> >> >   5. The SAF acronym in the documentation would return to Struts
>> >> >
>> >> > Given all the product naming changes in the last few years (much
of
>> >> which
>> >> > was my
>> >> > fault, I admit), I'd like to have these changes decided on soon,
so
>> >> we can
>> >> > move
>> >> > on to getting Struts 2.0 out the door.
>> >> >
>> >> > Don
>> >> >
>> >> >
>> -
>> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >> >
>> >> >
>> >>
>> >>
>> >
>> 

Re: [PROPOSAL] Rename Struts Action as Struts

[Dakota Jack]

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/29/06, Don
Brown  wrote:
>
> I like struts1/struts2.

+1

Niall

> Don

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Do you Yahoo!?
Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.





--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~