What was the breakdown of +1 vs. +0? Is there active support, or just apathy?

Just to follow up:

All the Struts committers seem to be on board now, either +1 or +0. We had an 11th hour addition to the code last week, but that is resolved now, and we might be able to roll 1.3.0 today, which I'd like to do before announcing this.

-Ted.

Everything looks good in those documents.

I signed up to Confluence - sorry about the confusion. My username is plightbo.
On 11/17/05, QT - Ted Husted <qtopic+33-KBfrHFUehSj@quicktopic.com> wrote: >
< replied-to message removed by QT >

So far, four other Struts committers have commented on the proposal (plus Don and myself), and all the comments have been positive. There are another five committers who are tracking Struts 1.3.x who haven't chimed in yet.

Some of the other committers are focussed on Shale right now, and might not feel a need to chime in on this.

Before we go any farther, we should confirm that there won't be any showstoppers with the paperwork.

Patrick and Jason should review the Apache software grant and confirm that it would be something you could execute in relation to the WebWork codebase.

* http://apache.org/licenses/software-grant.txt

With other projects joining the ASF, there have been discussions on a public list authorizing an individual to execute the grant on behalf of the group. When the time comes, it might be helpful if Roger Oberg were part of that online discussion.

Please also confirm that you both have had a chance to review the ASF How it Works pages and the Apache Struts Charter.

* http://apache.org/foundation/how-it-works.html
* http://struts.apache.org/bylaws.html

All ASF committers must have a Contributor's License Agreement on file. Sometimes, there are conflicts with corporate IP agreements, so please be sure to review the CLA to see if there would be any problems when we get to that stage.

* http://apache.org/licenses/icla.txt

Patrick, Have you signed up for an account at

* http://opensource2.atlassian.com/confluenc...isplay/STRUTS2/Home

I'd like to give you karma to access the space, but I don't see an account that looks like it's yours. Right now, the space is invisible unless you are "on the list".

-Ted.

Ok, I submitted a copy of the proposal to the Struts committers.

Welcome to interesting times :)

-Ted.

Yes, QuickTopic is a mini-mailing list, so that people like us can discuss things like this :)

If you register with the wiki, Patrick, I'll give you karma to see the area. Right now, it's only visible to the four of us. As other people join us, I can add them to the list for the area, until we are ready to go public.

* http://opensource2.atlassian.com/confluenc...isplay/STRUTS2/Home

-Ted.

Yeah, sorry I haven't been more involved. To be quite honest, this QuickTopic stuff totally derailed me. Is this just a mini-mailing list or something? What about the wiki? Then when I saw a wiki entry on QT, I really lost it :)

Let's get more people involved. Jason and I are good enough from the WW side, so let's heap on the Struts folks. Genereally, I'm fine with any plan to move forward and would probably get more involved one we talked about the details of implementing the merger.

On 11/15/05, QT - Sounds good <qtopic+33-KBfrHFUehSj@quicktopic.com> wrote: >
< replied-to message removed by QT >

I'm good with introducing the idea to more people...

So, if I don't hear from anyone by this evening, I'll assume that we have a lazy consensus to invite to our discussion the other Struts committers (and WebWork committers, as appropriate).

-Ted.

* For Struts 1.3, we're subdividing the project into subprojects. We have been referring to the controller subproject as "Core", but a new name "Action" has been proposed. So far, it looks like "Struts Action Framework" will be adopted for the name of the controller subproject.

* I expect that we will roll 1.3.0 next week.

This might be a good time to invite the other committers to review the proposal document at the wiki space.

* http://opensource2.atlassian.com/confluenc...isplay/STRUTS2/Home

Note that I made some updates to the proposal this evening to use the Struts Action moniker and to add the FAQ we discussed. I also added a section to track and prior and next steps.

-Ted.

>Not sure how this would work. Superficially,
> combining chain and xwork in some way would
> be a great win, especially if we could get
> shale to use xwork somehow, as it would help
> to unify Struts. Thinking about it, however,
> I'm not sure that would be possible or
> technically desirable.

Interceptor does represent an interesting pattern. In OverDrive/Nexus [1], we do something similar in two places and implement the pattern differently both times.

In one place, we create a "request processor" using "pre-opt" and "post-opt" chains defined in the application's configuration. At runtime, a new Chain instance is created, and we append together the pre-opt Chain, target Command (action), and post-opt Chain, and then execute the dynamic Chain normally.

In another place, we have a "Processor" class with two main entry points, "ConvertInput" and "FormatOutput". One method is invoked by a Command in the "pre-opt" Chain, and the other by a Command in the "post-op" Chain. We do this since we find converting and formatting attributes tend to be tightly coupled.

Of course, both of these implementations differ from the WebWork Interceptors in that the "before" and "after" instances cannot not share private state within the execute method. All shared state is being passed through the Context.

An interesting aside is that in OverDrive/Nexus, we can wrap "actions" with optional services without additional components. Our "actions" are another instance of Command (or Chain). Of course, by using a Command for an "action", it is easy to inject optional services before or after the "action" Command, or combine "actions" together, with or without the optional services.

I do like the idea of Inceptors; I just wonder if there is way to achieve the same benefits with fewer parts.

-Ted.

QT - Ted Husted wrote:

> h2. Will development work on Struts 1.x and WebWork 1.x
> continue?

Both WebWork 2.x and WebWork 1.x are actively developed currently.
> h2. Will any API changes be made to the base WebWork codebase,
> such as to remove WebWork 1 legacy features?
>
> {{ Yes? }}

Perhaps, but on the guidance of Patrick and Jason. They might have some stuff they'd like to cleanup and this would be a good opportunity to do so.
> h2. Will Struts Ti utilize Inteceptors or Commons Chain?
>
> We may try to combine the two so that Interceptors are an
> extension of Commons Chain. Interceptors are great when you are
> trying to "wrap" another process. Chain is great when you are
> just trying to create fine-grained processes and combine them in
> different ways.
>
> {{ Thoughts on this? }}

Not sure how this would work. Superficially, combining chain and xwork in some way would be a great win, especially if we could get shale to use xwork somehow, as it would help to unify Struts. Thinking about it, however, I'm not sure that would be possible or technically desirable.

> h2. Will the WebWork tags be a separate subproject? What about
> Webwork IoC?

I think we should leave the tags. They aren't tied to a particular rendering technology and are very flexible. Our problem with the Struts tags is none of the developers used them, but I don't think that will be the case with these.
Also, WebWork IoC, I believe, has officially been deprecated in favor of Spring, so we could just remove that altogether.

Don

>
>
>
> h2. Will Spring be used as an enabling technology?
>
> Yes.
>
> h2. Will Struts Ti be compatible with Spring MVC? Other
> frameworks?
>
> Our primary target is Struts 1.3 and WebWork 2.2, but we'd like
> to support great ideas from other frameworks too.
>
> ####
> _________________________________________________________________
> To unsubscribe: http://www.quicktopic.com/33/X/KBfrHFUehSj
> Start your own topic in 20 seconds: http://www.quicktopic.com |QT

My first whack:

----

h2. Why not do this through Open Symphony rather than Apache and make this WW3?

Benefits of doing this as an Apache project include

* The Apache Software Foundation is a not-for-profit corporation that insulates the volunteers from liablitity.

* The Foundation provides an assurance to the user community that the software will remain available under the business-friendly Apache License.

* Many teams are already authorized to use Apache Struts. Obtaining authorization to use another product can be a lengthy process.

h2. Will related OpenSymphony projects, like SiteMesh and XWork, merge with Struts too?

Probably not. Apache Struts already uses other products internally, and we can use SiteMesh and XWork too.

h2. Is this a proposal for "Struts 2.x"?

Not yet. If there is a clear and simple migration path from Struts 1.x to Struts Ti, then the Struts PMC may want to consider calling the product Struts Core 2.x, but it's too soon to say.

h2. Will development work on Struts 1.x and WebWork 1.x continue?

Yes, we expect that it will. The Struts and WebWork committers are also Struits and WebWork users, and we would want to keep both products up to date. It's also possible that we may help teams migrate to Ti step-by-step through a series of changes to the existing codebases.

h2. Will any API changes be made to the base WebWork codebase, such as to remove WebWork 1 legacy features?

{{ Yes? }}

h2. Will Struts Ti utilize Inteceptors or Commons Chain?

We may try to combine the two so that Interceptors are an extension of Commons Chain. Interceptors are great when you are trying to "wrap" another process. Chain is great when you are just trying to create fine-grained processes and combine them in different ways.

{{ Thoughts on this? }}

h2. Will Struts Ti be compatible with Struts 1.3? WebWork 2.2?

Yes, we hope to run most existing applications out of the box, and provide a clear migration path that any existing application could follow.

h2. Will the WebWork tags be a separate subproject? What about Webwork IoC?

<< Yes? Are we going to include WebWork IoC? >>

h2. Will Spring be used as an enabling technology?

Yes.

h2. Will Struts Ti be compatible with Spring MVC? Other frameworks?

Our primary target is Struts 1.3 and WebWork 2.2, but we'd like to support great ideas from other frameworks too.

####

On 11/6/05, Patrick Lightbody <plightbo@gmail.com> wrote:
> Sorry about the delay guys - i'm on the QuickTopic list now.
> What's next? :)

Here's my suggestion:

Next Steps

|-1 | Subscribe to the QuickTopic. |
| 0 | Create an account on the [Confluence site|<http://opensource.atlassian.com/confluence/oss/x/kQY]. |
| 1 | Finalize the "WebWork Agenda" proposal. |
| 2 | Invite the rest of the Struts, WebWork, and Beehive (?) committers to the table. |
| 3 | Update the initial proposal(s) as needed. |
| 4 | Draft an Incubator proposal to manage donation of the WW2 codebase. |
| 5 | Launch. |


Extensions

||1a ||Consider drafting a "mirror" proposal targeted for the WebWork development community. |


||1b ||Add a FAQ to the proposal(s). |
|| ||The proposal should include a FAQ so that we have ready answers to the obvious questions (talking points). |
| .1 | Draft some likely questions. |

* Why not do this through Open Symphony rather than Apache and make this WW3?

* Will related OpenSymphony projects, like SiteMesh and XWork, merge with Struts too?

* Is this a proposal for "Struts 2.x"?

* Will development work on Struts 1.x and WebWork 1.x continue?

* Will any API changes be made to the base WebWork codebase, such as to remove WebWork 1 legacy features?

* Will Struts Ti utilize Inteceptors or Commons Chain?

* Will Struts Ti be compatible with Struts 1.3? WebWork 2.2?

* Will the WebWork tags be a separate subproject? What about Webwork IoC?

* Will Spring be used as an enabling technology?

* Will Struts Ti be compatible with Spring MVC? Other frameworks?

| .2 |Post our answers to the questions on the QuickTopic and combine our responses on the wiki. |


||3a ||Add RoadMap to the proposal. |
| .1 | Once we have a consensus with the core community, we should draw up a clear roadmap of what we expect to do with "Ti

Phase 1", and make the roadmap part of the proposal.|


||3b ||Consider writing system Use Cases for Struts Classic, WebWork 2.x, and Ti to support the roadmap. |

####

I've brought it up with him privately already, since he and I worked together a lot on Ti. He is very enthusiastic, and wants to present it to Beehive as soon he can. I'll ask him to subscribe to the topic.
Don

QT - Ted Husted wrote:
< replied-to message removed by QT >

Since, we mention Rich Feit in the proposal, do you think we should invite him to review the draft proposal, and get his feedback on our roadmap?

-T.