You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2004/09/03 13:11:48 UTC
Roadmap was (Re: [VOTE] Move minimum to 2.3 ..)
OK, to sum up what people seem to be saying here:
[Struts 1.2.x]
* The minimums for 1.2.3 will remain Servlet 2.2
* We create a branch at the 1.2.3 tag, in case we need to make critical fixes to 1.2.x later.
[Struts HEAD]
* For now, Struts HEAD can remain in evolutionary mode, but we will bump the minimum to Servlet 2.3. At this point in time, this seems like a minor change, and so for the purposes of the Roadmap, we could assume the next release will be 1.3.0. But the final decision is up to the PMC when there's something to ready to release. (
* If anyone on the PMC feels strongly about the versioning, we can change all the markers on the Roadmap, so features slotted for 1.3.x ascribe to 2.0.x, and so forth, but that seems like a lot of churn for little benefit
* Some of the reasons we are moving to Servlet 2.3 are:
* It is preferred platform of active Struts developers.
* It is needed for certain enhancements, including some to file upload.
* It simplifies distribution and integration of JavaServer Faces components which are dependant on Servlet 2.3.
* If at any time, we decide to move the HEAD to revolutionary mode, so as to stretch or break backward-compatibility, we can branch again, and assume that the HEAD will become 2.0.0 at the next release. But, we don't have to make that decision until a revolutionary commit is pending :)
* So far, items like Struts Chain count as evolutionary, since it seems we will be extending the API to support other "Action" signatures (e.g. for Portlets), but not removing the old ones. (As we did when we changed the signature for Exception handling.)
[Struts NEXT]
* Any time anyone is ready to plunk down some code (or even just branch), several people sound eager to work on a Servlet 2.4 implementation of Struts. (Whether we need to also specify JSP 2.0 is yet to be determined, since it might be irrelevant.)
* How compatible a revolutionary codebase is with Struts will be up to the people implementing it. (This can be you!)
* The mechanism by which a codebase is labeled a Struts release is a majority vote of the Struts PMC. Just because a committer starts a revolution in an Struts repository, doesn't mean the PMC has to sanction it later. Every release decision has to be based on the quality of the codebase itself. There can be no guarantees.
* Any revolutionary implementations should start work under a label, not a version number. Once there is something to release, the PMC can decide whether it gets released and what's is version number will be. Tomcat's "Catalina" is one example of the labeling practice. The Struts "Jericho" whiteboard is another.
* Some advantages of basing a framework on Servlet 2.4 include:
* HttpServletRequest.setCharacterEncoding() allows applications to
resolve nearly all the ambiguities of parsing request parameters in
the right encoding (which is a smaller number of problems than it used
to be in 2.4 generally, because the rules have been tightened, and
because of the next feature).
* You can define (in web.xml) your own mapping table from locale
to character encoding, rather than relying on the container's
undocumented (and likely non-portable) defaults.
* Filters can be declared to run on RequestDispatcher.forward() calls
as well as on the original request. Without this, it's basically impossible
to write use-case-specific Filters in an MVC framework that uses
RD.forward() the way Struts does today.
* ServletRequestListener fleshes out the lifecycle model, so you can do things
like adding some resource to the request attributes, and knowing that it will
get cleaned up (after the response has been rendered by the JSP page or
whatever) by your listener.
* ServletRequestAttributeListener can listen to changes on your request
attributes, similar to how HttpSessionAttributeListener and
ServletContextAttributeListener work in 2.3.
* On an HttpSessionBindingListener, the listener is invoked when you actually
expect it to be at session end (*before* the session is invalidated,
rather than after).
* "Welcome Files" can now be servlets, so you can use "index.do" instead
of having an "index.jsp" that forwards to an action that does your setup.
* Deployment descriptors (web.xml) that conform to the 2.4 schema can
have their elements listed in any order, instead of the pretty arbitrary
sequence required by 2.3.
Of course, I'll update the roadmap.xml file accordingly, along with any clarifications made to this thread.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Roadmap
Posted by Ted Husted <hu...@apache.org>.
On Tue, 12 Oct 2004 13:29:40 -0700, Martin Cooper wrote:
>�* The request may not have come from a form or a link; it may have
>�been submitted using an XMLHttpRequest object. In such cases, forms
>�as we talk about them are not relevant. Instead, we may want to
>�provide the request input in the form of a DOM. We may also want to
>�think about how to handle input validation in a consistent way
>�across different types of requests.
+1
Conceptually, the FormContext is a type of DOM, and it would also express input validation in a consistent way, within the same model. It's the skeleton requirements of the form, without any of the markup chrome. An object that tells the view what is needs to know, without dictating how the view will render the information. (I did mention a default control attribute, but that would be a platform-independent descriptor, like the ones used by Faces. And, of course, the View could always ignore the "control" advice.)
We already have to all the form information at hand, but today it's scattered about. Some specifications are on the page, some are in this Java object, and others are in this XML document or that XML document.
I use the word "Form" because it is familiar and concise. But the same context could also be used to create a non-visual response, like a SOAP message to another application. The point is that the response rendering entity would have whatever it needs to know "at its fingertips".
>�* The response may not be HTML, even when it's headed for the
>�browser. It might be XML or even JavaScript code, serialised from a
>�data structure, and to be interpreted / evaluated in the browser.
+1
The response may even be a unit test report. :)
I'm just saying that the primary "response" from the framework should be a ViewContext that encapsulates the Struts API. This can then be passed to whatever rendering agent is needed. If the response is going out to a HTML page, then it can be passed in the HTTP response. If it is going somewhere else, the same ViewContext can be passed in a different way, but present a consistent interface.
>�* Many - perhaps even most - requests are not page-replacement
>�requests. That is, the response is not a complete HTML page or
>�frame to replace the one the request was submitted form.
>
>�* The response may not correspond to a page or a frame. Instead, it
>�might be destined for a particular piece of the page (e.g. a div
>�element). This allows for partial page updates in interactive
>�applications.
+1
A very good way to empower these type of response rendering agents is to expose Struts as a coherent view context.
Of course, the actual view rendering (if any) is outside the scope of the Controller framework. Our job is to provide the View the data it needs to render itself.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Roadmap
Posted by Martin Cooper <mf...@gmail.com>.
While I don't disagree with any of Ted's points, I do think that we
need to expand our horizons with Struts Next, rather than just provide
more of the same. We need to move beyond the traditional web app and
embrace the next generation of web apps that have some rather
different characteristics. For example:
* Many - perhaps even most - requests are not page-replacement
requests. That is, the response is not a complete HTML page or frame
to replace the one the request was submitted form.
* The request may not have come from a form or a link; it may have
been submitted using an XMLHttpRequest object. In such cases, forms as
we talk about them are not relevant. Instead, we may want to provide
the request input in the form of a DOM. We may also want to think
about how to handle input validation in a consistent way across
different types of requests.
* The response may not correspond to a page or a frame. Instead, it
might be destined for a particular piece of the page (e.g. a div
element). This allows for partial page updates in interactive
applications.
* The response may not be HTML, even when it's headed for the browser.
It might be XML or even JavaScript code, serialised from a data
structure, and to be interpreted / evaluated in the browser.
Not all of these will have a direct impact on the Struts Next core, of
course. However, I do want to make sure we are thinking about next
generation apps as we build our next generation framework. ;-)
Of course, this is my own itch speaking, since I live in the world of
highly interactive browser-based applications these days...
--
Martin Cooper
On Sun, 10 Oct 2004 15:42:10 -0400, Ted Husted <hu...@apache.org> wrote:
> To follow up some other threads about the "architectural vision" for Struts Next, I'd like to offer the following:
>
> ----
>
> Most of us are torn whether to create Struts Next by evolution or revolution. I think what most of us revolutionaries really want to to create Struts Next by mutation. We're not displeased with Struts 1.x. It's just that we are still carrying around an appendix or two that muddle our "clear vision" of the Struts 1.x architecture.
>
> For Struts Next, whether we get there by evolution or mutation, I would envision three pillar components:
>
> * Request Processor
> * Action/View Context
> * Form Context
>
> --Request Processor--
>
> The core of the Struts core is now, and has always been, the Request Processor. In Struts 1.0, it was buried amongst other methods in the ActionServlet, but you could see that it was there. In Struts 1.1.x, we pulled it out for all to see. In Struts 1.3.x, we're installing a revolutionary Request Processor based on Commons Chain <http://jakarta.apache.org/commons/chain/>.
>
> For Struts Next, I'd imagine we'd continue using and refining the Struts Chain Request Processor. The (ironically-named) Chain gives us the flexibility to make Struts less like a framework and more like a toolkit for building frameworks. For example, in Struts 1.3, we already plan to offer an alternate Command Catalog that supports portlets.
>
> --Action/View Context--
>
> The hand maiden of a Chain of Responsibility is a Context. We've been batting around the idea of an ActionContext for some time. Joe brought it up again the other day. The basic idea is simple. Instead of passing around several members in a signature, we put them all in a JavaBean and Context, and pass this around instead.
>
> The idea of a ViewContext is similar, except that it is designed to expose everything a View would want to know about Struts as a single, coherent JavaBean or Context.
>
> There was an experimental implementation, called the ConfigHelper, in February 2002
>
> <http://tinyurl.com/3t3m9>
>
> which was used as the basis of the ActionConfig of December 2002
>
> <http://tinyurl.com/3jwpj>
>
> In Struts Next, I would imagine that an ActionContext is used internally by the RequestProcessor and a ViewContext is exposed to the page or dialog. The difference being that the ViewContext would free of web semantics, so it could be used without change on any platform.
>
> --Form Context--
>
> We have a love/hate relationship with ActionForms. One of the big things Struts Chain buys will be the ability to easily change how automatic population takes place. If you don't like that link in the chain, you can change it just by changing the default XML catalog descriptor.
>
> The ActionForm filled a lot of roles in Struts 1.x, and I think some people will want to keep it. I've also used WebWork type frameworks. They are simpler than the Struts Action/ActionForm combo, and in some ways better, but there are still pieces missing.
>
> IMHO, what we need is a complete metadescription of the UI controls and forms (collections of controls) an application is using. If we combine the DynaActionForm with the ValidatorForm, we already have 80% of what we need. But, I believe, we should also be able to define a default control, a UI label, a UI "hint", and a default conversion/transformation method. (The latter is already implied by the validation.)
>
> The end game should be that if we pass this description to a smart control, it should be able to render a basic input or output form.
>
> Of course, basic is never good enough, so we would also want to be able to pass it to individual controls who would render part of the form. But, the proof of concept should be:
>
> <struts:form readonly="false"/>
>
> and have a complete input form, with labels and hints, dropdown lists, and or
>
> <struts:form readonly="true"/>
>
> and get the non-input version.
>
> The conventional Struts paradigm would remaint the same. But instead of controls looking to the request, session, or application contexts for a JavaBean/ActionForm, they would look to the ViewContext for a FormContext (or collection of FormContexts). But the FormContext would not only carry the value of the control, but its label, hint, and other attributes.
>
> Another important role for a FormContext is to serve as a JavaBean factory. What most of really want to do is to say to a *valid* FormContext: "It's great that the input is valid, now can I have those values in a business object, please".
>
> The idea being that if we specify in the XML descriptor what type we want each (string) attribute of the FormContext to create, and the context could then create the target type for each attribute and us them to populate a JavaBean, and return the populated instance, ready to hand off to your business logic. (Something like a JSF Managed Bean.)
>
> The FromProc tool in SourceForge does this sort of thing now <http://sourceforge.net/projects/formproc>. Instead of just validating the input, as we do with the Commons Validator, it validates the input and then converts it to a target object.
>
> --Testability--
>
> A fourth pillar has to be testability. The original Struts implementation was created just before the interest in JUnit began to peak. Struts Next has to be testable from square one, and we must avoid any designs which are difficult to test.
>
> --
>
> Personally, I believe the original Struts scenario is sound, which is why it has lasted so long.
>
> (0) Client submits request
> (1) System receives the incoming request
> (2) System transfers matching values to a form object
> (3) System validates the object
> (4) System branches to success or failure.
> (4a) On success, system executes/delegates the business logic.
> (4b) On failure, system returns the faulty input.
> (5) A view displays the nominal result or redisplays faulty input.
>
> We just need to identify what improvements we need to make at each step, and any additional steps we'd like to add.
>
> It might be interesting to expand this quick list into a formal set of use-case scenarios. If you have UML Distilled, Fowler mentions scenarios at the opening of Chapter 3.
>
> -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: Roadmap was (Re: [VOTE] Move minimum to 2.3 ..)
Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 3 Sep 2004 07:11:48 -0400, Ted Husted <hu...@apache.org> wrote:
> OK, to sum up what people seem to be saying here:
>
> [Struts 1.2.x]
>
> * The minimums for 1.2.3 will remain Servlet 2.2
>
> * We create a branch at the 1.2.3 tag, in case we need to make critical fixes to 1.2.x later.
As I mentioned, I would prefer to create the tag now (which I'll be
doing in a couple of minutes), and create a branch at that tag if /
when we need it. In other words, I'd suggest s/in case/when/. ;-)
--
Martin Cooper
>
> [Struts HEAD]
>
> * For now, Struts HEAD can remain in evolutionary mode, but we will bump the minimum to Servlet 2.3. At this point in time, this seems like a minor change, and so for the purposes of the Roadmap, we could assume the next release will be 1.3.0. But the final decision is up to the PMC when there's something to ready to release. (
>
> * If anyone on the PMC feels strongly about the versioning, we can change all the markers on the Roadmap, so features slotted for 1.3.x ascribe to 2.0.x, and so forth, but that seems like a lot of churn for little benefit
>
> * Some of the reasons we are moving to Servlet 2.3 are:
>
> * It is preferred platform of active Struts developers.
> * It is needed for certain enhancements, including some to file upload.
> * It simplifies distribution and integration of JavaServer Faces components which are dependant on Servlet 2.3.
>
> * If at any time, we decide to move the HEAD to revolutionary mode, so as to stretch or break backward-compatibility, we can branch again, and assume that the HEAD will become 2.0.0 at the next release. But, we don't have to make that decision until a revolutionary commit is pending :)
>
> * So far, items like Struts Chain count as evolutionary, since it seems we will be extending the API to support other "Action" signatures (e.g. for Portlets), but not removing the old ones. (As we did when we changed the signature for Exception handling.)
>
> [Struts NEXT]
>
> * Any time anyone is ready to plunk down some code (or even just branch), several people sound eager to work on a Servlet 2.4 implementation of Struts. (Whether we need to also specify JSP 2.0 is yet to be determined, since it might be irrelevant.)
>
> * How compatible a revolutionary codebase is with Struts will be up to the people implementing it. (This can be you!)
>
> * The mechanism by which a codebase is labeled a Struts release is a majority vote of the Struts PMC. Just because a committer starts a revolution in an Struts repository, doesn't mean the PMC has to sanction it later. Every release decision has to be based on the quality of the codebase itself. There can be no guarantees.
>
> * Any revolutionary implementations should start work under a label, not a version number. Once there is something to release, the PMC can decide whether it gets released and what's is version number will be. Tomcat's "Catalina" is one example of the labeling practice. The Struts "Jericho" whiteboard is another.
>
> * Some advantages of basing a framework on Servlet 2.4 include:
>
> * HttpServletRequest.setCharacterEncoding() allows applications to
> resolve nearly all the ambiguities of parsing request parameters in
> the right encoding (which is a smaller number of problems than it used
> to be in 2.4 generally, because the rules have been tightened, and
> because of the next feature).
>
> * You can define (in web.xml) your own mapping table from locale
> to character encoding, rather than relying on the container's
> undocumented (and likely non-portable) defaults.
>
> * Filters can be declared to run on RequestDispatcher.forward() calls
> as well as on the original request. Without this, it's basically impossible
> to write use-case-specific Filters in an MVC framework that uses
> RD.forward() the way Struts does today.
>
> * ServletRequestListener fleshes out the lifecycle model, so you can do things
> like adding some resource to the request attributes, and knowing that it will
> get cleaned up (after the response has been rendered by the JSP page or
> whatever) by your listener.
>
> * ServletRequestAttributeListener can listen to changes on your request
> attributes, similar to how HttpSessionAttributeListener and
> ServletContextAttributeListener work in 2.3.
>
> * On an HttpSessionBindingListener, the listener is invoked when you actually
> expect it to be at session end (*before* the session is invalidated,
> rather than after).
>
> * "Welcome Files" can now be servlets, so you can use "index.do" instead
> of having an "index.jsp" that forwards to an action that does your setup.
>
> * Deployment descriptors (web.xml) that conform to the 2.4 schema can
> have their elements listed in any order, instead of the pretty arbitrary
> sequence required by 2.3.
>
> Of course, I'll update the roadmap.xml file accordingly, along with any clarifications made to this thread.
>
> -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: Roadmap
Posted by Mike Stanley <ms...@mstanley.net>.
On Tue, 2004-10-12 at 11:27, Joe Germuska wrote:
> >>Note that, at least with ActionConfigs, there is an important
> >>difference between "type" and "className". "className" refers to
> >>the type of the ActionConfig itself, should you want to use a
> >>subclass (say, for custom properties) while "type" refers to the
> >>type of the Action which will be created to service the
> >>ActionConfig. This can be confusing, but they aren't synonymous.
> >>I'm not sure that I think that the other cases where you've named
> >>attributes shoudl all be standardized either, but maybe if it were
> >>laid out in front of me as a proposal, I'd think harder about it...
> >
> >Hmmm... I wasn't aware you could specify an ActionConfig class
> >(subclass). In fact, I wasn't aware you could specify the className
> >for Form, Controllers, or Actions at all :-). How does this
> >attribute work with digester rules, dtd validation, etc?
>
> There is a standard digester rule which interprets the XML
> <set-property property="foo" value="bar" /> which is valid in the DTD
> where appropriate -- so rather than adding arbitrary attributes
> (which wouldn't validate), you add a "set-property" element. (This
> is implemented with a series of consistent digester rules in
> o.a.s.config.ConfigRuleSet, not with a wild-card path match, but it
> is configured where it is appropriate.)
Yeah. I investigated after I posted the question, and now have a much
clearer picture of the current status of the Config package and how I'd
like to see it migrate in the future.
I did find an intermediate (and elegant) solution to something I was
trying to do -- more details to follow about this another day ;-)
> >I guess in this light, things are a bit different. I do still feel
> >there are some inconsistencies though. Some thoughts
> >- the use of "handler" in the exception element seems inconsistent.
> >IMO it would be more consistent to use "type" as the exception
> >handler class, and add an attribute "match" or "exceptionClass" for
> >the registered exception.
>
> Agreed. It would take a fair bit of effort to change this without
> breaking all the world's config files, but it is a noble goal. Since
> "type" already has a meaning, there's no easy way to do this
> gradually.
What I'm thinking should definitely be sloted for a 2.x release. IMO,
anything that breaks backwards compatibility with the config files
should be a major version change 2.x.
Now, that doesn't mean there shouldn't be change's that move towards a
better pattern.
> >- in datasource, form, controller, message-resources, form-property
> >and action: className refers to the Config class. But in plugin,
> >and action forward: className is the type to instantiate.
>
> plugin would be easy enough to fix, since it doesn't use 'type'
> Unfortunately, XML config files wouldn't trigger deprecation
> warnings, but perhaps some warn-level logging could help alert people
> that they are using something slated for removal.
>
> Which do you mean by "action forward"?
>
> >- "name" is something I always felt was inconsistent. action refers
> >to the associated form bean, but in form bean and action forward
> >elements name is the unique identifier.
>
> I've never liked the use of 'name' in ActionConfig -- I'd prefer
> "form" or "formName". I'm not sure if anyone else has a good reason
> why it is the way it is. "name" is used in many places in Struts as
> a "stand-in" for unique ID, so I'd go along with changing that in
> ActionConfig, which is doable in the same way that plugin could be
> changed.
I would guess "name" for form came in at the very beginning when there
was a 1-1 between form and action. But that's just a theory. I would
prefer to see "form" as well. I don't have a problem with "name" being
used as a unique ID. That's what I think about when I see that
attribute. Obviously, in the case of Action Mappings that is not the
case.
- Mike
>
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
> back; I'll know I'm in the wrong place."
> - Carlos Santana
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
Re: Roadmap
Posted by Joe Germuska <Jo...@Germuska.com>.
>>Note that, at least with ActionConfigs, there is an important
>>difference between "type" and "className". "className" refers to
>>the type of the ActionConfig itself, should you want to use a
>>subclass (say, for custom properties) while "type" refers to the
>>type of the Action which will be created to service the
>>ActionConfig. This can be confusing, but they aren't synonymous.
>>I'm not sure that I think that the other cases where you've named
>>attributes shoudl all be standardized either, but maybe if it were
>>laid out in front of me as a proposal, I'd think harder about it...
>
>Hmmm... I wasn't aware you could specify an ActionConfig class
>(subclass). In fact, I wasn't aware you could specify the className
>for Form, Controllers, or Actions at all :-). How does this
>attribute work with digester rules, dtd validation, etc?
There is a standard digester rule which interprets the XML
<set-property property="foo" value="bar" /> which is valid in the DTD
where appropriate -- so rather than adding arbitrary attributes
(which wouldn't validate), you add a "set-property" element. (This
is implemented with a series of consistent digester rules in
o.a.s.config.ConfigRuleSet, not with a wild-card path match, but it
is configured where it is appropriate.)
>I guess in this light, things are a bit different. I do still feel
>there are some inconsistencies though. Some thoughts
>- the use of "handler" in the exception element seems inconsistent.
>IMO it would be more consistent to use "type" as the exception
>handler class, and add an attribute "match" or "exceptionClass" for
>the registered exception.
Agreed. It would take a fair bit of effort to change this without
breaking all the world's config files, but it is a noble goal. Since
"type" already has a meaning, there's no easy way to do this
gradually.
>- in datasource, form, controller, message-resources, form-property
>and action: className refers to the Config class. But in plugin,
>and action forward: className is the type to instantiate.
plugin would be easy enough to fix, since it doesn't use 'type'
Unfortunately, XML config files wouldn't trigger deprecation
warnings, but perhaps some warn-level logging could help alert people
that they are using something slated for removal.
Which do you mean by "action forward"?
>- "name" is something I always felt was inconsistent. action refers
>to the associated form bean, but in form bean and action forward
>elements name is the unique identifier.
I've never liked the use of 'name' in ActionConfig -- I'd prefer
"form" or "formName". I'm not sure if anyone else has a good reason
why it is the way it is. "name" is used in many places in Struts as
a "stand-in" for unique ID, so I'd go along with changing that in
ActionConfig, which is doable in the same way that plugin could be
changed.
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN
Posted by Hubert Rabago <hr...@gmail.com>.
On Thu, 14 Oct 2004 06:57:14 -0400, Ted Husted <hu...@apache.org> wrote:
>
> There are a great number of teams that can't use the nightly build. If we don't cut regular releases, problems we fixed months and even a year ago, don't make it back to our users. What's the point of doing all this, if most people can't use what we do for so long?
>
Understood. I've been there, as far as the "only released versions"
restrictions go. I just suddenly pictured a release "just because" a
few weeks had passed even though there weren't any noticeable changes.
Today, of course, we have the errorStyle enhancements that Niall
added, and of course some bug fixes.
>
> > On the other hand, if an every-few-weeks release cycle becomes the
> > norm, I suggest we keep track of which version has which on the
> > Wiki, just to make it easier on the users. :)
>
> We already bundle a good set of notes with every release, and I can guarantee that won't change.
>
> http://struts.apache.org/userGuide/release-notes.html
>
> The problem is that after 18 months, the notes are so long, that people give up trying to read them. :)
>
> And, of course, as far as maintaining anything on the Wiki goes, we includes you. :)
>
> -Ted.
Yup, that's why I used "we" instead of "y'all". :)
- Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
+1
Hubert Rabago wrote:
>I also believe that Struts can release more often that every 18
>months, but I don't know if a new release every few weeks will help.
>In some cases, I think it might hurt Struts, because it can make
>things pretty confusing for users. I can see it now on the user list:
>User A: "I need help trying to make feature X work".
>User B: "What version are you using?"
>User A: "1.2.y"
>User B: "For 1.2.x, this is what you do."
>User C: "For 1.2.z, this is what you do."
>User A: "None of those work for me. Anybody else?"
>~ silence ~
>
>I know I don't contribute code (or at least the ones I do often don't
>get accepted), but I try to at least help out on the user list
>whenever I can, and it's easier when you only have three versions to
>deal with: the current release (1.2.4), the previous release (1.1),
>and the nightly build. (Hmm... when did I start thinking like the guy
>on the other end of a tech support line?)
>
>I think if there are compelling new features, then a release is
>merited. Perhaps there aren't a lot because the committers don't have
>a lot of itches to scratch, or patches they like to commit or work on.
> Some of the users/lurkers might have, and if the committers have
>enhancements they'd like to see patches for, maybe being more vocal
>about them would up the contrib rate. For instance, Craig has
>mentioned config inheritance, so it's more than likely now that
>someone could start on that, knowing that that patch would have a
>bigger chance of acceptance than some random enhancement request in
>bugzilla. It could increase participation, and in turn new features,
>and in turn the reasons for rolling another release.
>
>On the other hand, if an every-few-weeks release cycle becomes the
>norm, I suggest we keep track of which version has which on the Wiki,
>just to make it easier on the users. :)
>
>Hubert
>
>
>
>On Wed, 13 Oct 2004 09:37:39 -0400, James Mitchell <jm...@apache.org> wrote:
>
>
>>I'd like to roll a release after you are finished with that. I really,
>>REALLY want to keep these rolling (about 1 every few weeks) which has the
>>added benefit of (hopefully) breaking this bad habit we seem to be in (~18
>>month GA release cycle).
>>
>>--
>>James Mitchell
>>Software Engineer / Open Source Evangelist
>>EdgeTech, Inc.
>>678.910.8017
>>AIM: jmitchtx
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
>
Re: CVS -> SVN
Posted by Ted Husted <hu...@apache.org>.
On Wed, 13 Oct 2004 09:03:48 -0500, Hubert Rabago wrote:
>�I also believe that Struts can release more often that every 18
>�months, but I don't know if a new release every few weeks will
>�help. In some cases, I think it might hurt Struts, because it can
>�make things pretty confusing for users. �I can see it now on the
>�user list: User A: "I need help trying to make feature X work".
>�User B: "What version are you using?" User A: "1.2.y" User B: "For
>�1.2.x, this is what you do." User C: "For 1.2.z, this is what you
>�do." User A: "None of those work for me. �Anybody else?" ~ silence ~
The versions aren't going to drift that rapidly. What happens is that someone reports a problem and we fix it. But the fix is only available in the nightly build. The nightly builds are all "Alphas", and so, after submitting a fix, many people can't use it in their production applications. A product manager insists they use Struts out-of-the-box. (Sad but true.) But if version 1.2.y has the fix, then we are giving people opportunity to use the fix, rather than suffer in silence.
>�I know I don't contribute code (or at least the ones I do often
>�don't get accepted), but I try to at least help out on the user
>�list whenever I can, and it's easier when you only have three
>�versions to deal with: the current release (1.2.4), the previous
>�release (1.1), and the nightly build. �(Hmm... when did I start
>�thinking like the guy on the other end of a tech support line?)
>
>�I think if there are compelling new features, then a release is
>�merited. �Perhaps there aren't a lot because the committers don't
>�have a lot of itches to scratch, or patches they like to commit or
>�work on. Some of the users/lurkers might have, and if the
>�committers have enhancements they'd like to see patches for, maybe
>�being more vocal about them would up the contrib rate. �For
>�instance, Craig has mentioned config inheritance, so it's more than
>�likely now that someone could start on that, knowing that that
>�patch would have a bigger chance of acceptance than some random
>�enhancement request in bugzilla. �It could increase participation,
>�and in turn new features, and in turn the reasons for rolling
>�another release.
The "compelling new features" argument is what lead us to the 18 month release cycle. People kept wanting to get one more thing into the release. So the release gets pushed farther and farther out, encouraging people to try and get one more thing in, because the release cycle ha now become so long.
It's a viscous downward spiral, and it has to stop.
There are a great number of teams that can't use the nightly build. If we don't cut regular releases, problems we fixed months and even a year ago, don't make it back to our users. What's the point of doing all this, if most people can't use what we do for so long?
>�On the other hand, if an every-few-weeks release cycle becomes the
>�norm, I suggest we keep track of which version has which on the
>�Wiki, just to make it easier on the users. :)
We already bundle a good set of notes with every release, and I can guarantee that won't change.
http://struts.apache.org/userGuide/release-notes.html
The problem is that after 18 months, the notes are so long, that people give up trying to read them. :)
And, of course, as far as maintaining anything on the Wiki goes, we includes you. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN
Posted by Hubert Rabago <hr...@gmail.com>.
I also believe that Struts can release more often that every 18
months, but I don't know if a new release every few weeks will help.
In some cases, I think it might hurt Struts, because it can make
things pretty confusing for users. I can see it now on the user list:
User A: "I need help trying to make feature X work".
User B: "What version are you using?"
User A: "1.2.y"
User B: "For 1.2.x, this is what you do."
User C: "For 1.2.z, this is what you do."
User A: "None of those work for me. Anybody else?"
~ silence ~
I know I don't contribute code (or at least the ones I do often don't
get accepted), but I try to at least help out on the user list
whenever I can, and it's easier when you only have three versions to
deal with: the current release (1.2.4), the previous release (1.1),
and the nightly build. (Hmm... when did I start thinking like the guy
on the other end of a tech support line?)
I think if there are compelling new features, then a release is
merited. Perhaps there aren't a lot because the committers don't have
a lot of itches to scratch, or patches they like to commit or work on.
Some of the users/lurkers might have, and if the committers have
enhancements they'd like to see patches for, maybe being more vocal
about them would up the contrib rate. For instance, Craig has
mentioned config inheritance, so it's more than likely now that
someone could start on that, knowing that that patch would have a
bigger chance of acceptance than some random enhancement request in
bugzilla. It could increase participation, and in turn new features,
and in turn the reasons for rolling another release.
On the other hand, if an every-few-weeks release cycle becomes the
norm, I suggest we keep track of which version has which on the Wiki,
just to make it easier on the users. :)
Hubert
On Wed, 13 Oct 2004 09:37:39 -0400, James Mitchell <jm...@apache.org> wrote:
> I'd like to roll a release after you are finished with that. I really,
> REALLY want to keep these rolling (about 1 every few weeks) which has the
> added benefit of (hopefully) breaking this bad habit we seem to be in (~18
> month GA release cycle).
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN / Roadmap
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 14 Oct 2004 12:50:49 -0400, James Mitchell <jm...@apache.org> wrote:
> Ted, I will roll a release as soon as you say 'go'.
>
> If you and/or Martin (or anyone else that has time and patience to deal with
> me) could help with questions wrt label/branch/etc.
I should be around this weekend. You know where to find me on IM. ;-)
--
Martin Cooper
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
>
>
>
> ----- Original Message -----
> From: "Don Brown" <mr...@twdata.org>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Thursday, October 14, 2004 11:30 AM
> Subject: Re: CVS -> SVN / Roadmap
>
> > Ted Husted wrote:
> >
> > >+1
> > >
> > >Let's stick to the roadmap we laid out in July.
> > >
> > >http://struts.apache.org/roadmap.html
> > >
> > >I'll update the site to reflect the CVS/SVN changes this weekend and
> bring the roadmap page up to date.
> > >
> > >If James is up for rolling a 1.2.5 release, that's fine with me.
> > >
> > >Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x,
> and bring down that-there Struts Chain gizmo. :)
> > >
> > >
> > +1 I vote we (or perhaps I specifically) integrate struts-chain this
> > weekend. It is stable, and I've been using it in production for some
> > time without problems. Course that also means we (again, perhaps I
> > specifically) should release commons-chain 1.0. Ted, there are a few
> > Guinnesses in it if you help me with the documentation.... :)
> >
> > >And if Don wants to start setting up struts-flow and struts-scripting
> along the same lines as struts-faces, I'll buy him a Guiness (or three) at
> ApacheCon :)
> > >
> > >
> > Ah, Guinness - the ultimate currency. You got yourself a deal.
> >
> > Don
> >
> > >-Ted.
> > >
> > >On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
> > >
> > >
> > >> On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
> > >> <an...@steinlein.no> wrote:
> > >>
> > >>
> > >>> Forgive my possible ignorance, but what is the policy on new
> > >>> releases? I've understood that we can release whenever we want,
> > >>> that version numbers are cheap and that you vote whether to make
> > >>> a release alpha/beta/GA. But, what goes into a release? Does new
> > >>> features/enhancements go into a 1.2.x release, or is it strictly
> > >>> bug fixes?
> > >>>
> > >>>
> > >>>
> > >>>
> > >> What we've talked about before is along these lines:
> > >>
> > >> Within the 1.2.x series, it's fine to fix bugs and add new stuff,
> > >> but not fine to make any backwards-incompatible changes.
> > >>
> > >> For a 1.3.x series, we could be more liberal about adding new
> > >> stuff, and possibly have some deprecations in 1.2.x that get
> > >> removed -- but it shoujld in general be based on similar enough
> > >> architectural principles that there be a clear upgrade path.
> > >>
> > >> The challenge, of course, is when do you make that split for the
> > >> evolutionary path? I'd say that something as fundamental as using
> > >> Struts Chain instead of the monolithic RequestProcessor, and the
> > >> other changes we could make as a result of having that, would be
> > >> good grounds for a 1.3.x series. If that were to start in the
> > >> short term, then thinking of 1.2.x as being in maintenance mode
> > >> seems likely (although if there's willingness to port features back
> > >> and forth, it need not go that way immediately ... for example,
> > >> Tomcat 4.1.x continued to develop for a little while at the
> > >> beginning of 5.0.x, including some features ported back and forth,
> > >> but this pretty much stopped as soon as there was a solid 5.0.x
> > >> release for people to use).
> > >>
> > >> For a 2.x chain, we could have the freedom to be somewhat more
> > >> aggressive at rearchitecting ("if we'd known then what we know now,
> > >> what would Struts have looked like?"), and could in theory have a
> > >> series of alpha releases in parallel with stable releases on 1.2 or
> > >> 1.3. As others have pointed out, how much simultanaeity there is,
> > >> and how often releases happen, is more based on the directed energy
> > >> of the committers (and what they want to work on), and less on
> > >> whether there are parallel development efforts going on.
> > >>
> > >>
> > >>
> > >>> The reason I ask is because I would love releases much, much more
> > >>> often, but as have been pointed out, incompatibilities/quirks
> > >>> between minor versions could be a disaster.
> > >>>
> > >>>
> > >>>
> > >>>
> > >> Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
> > >> interoperability and upgrade, a bit on the edge of what most users
> > >> liked, while the 1.1 -> 1.2 transition was much easier to do. We
> > >> haven't actually gotten around to many x.y.z releases on 1.0 or
> > >> 1.1, so having them happen at all in 1.2 should be a refreshing
> > >> change :-). But I agree with you that compatibility is especially
> > >> important within an x.y release cycle.
> > >>
> > >>
> > >>
> > >>> \Anders
> > >>>
> > >>>
> > >>>
> > >> Craig
> > >>
> > >> --------------------------------------------------------------------
> > >> - 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
> >
> >
>
>
> ---------------------------------------------------------------------
>
>
> 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: CVS -> SVN / Roadmap
Posted by James Mitchell <jm...@apache.org>.
Ted, I will roll a release as soon as you say 'go'.
If you and/or Martin (or anyone else that has time and patience to deal with
me) could help with questions wrt label/branch/etc.
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Don Brown" <mr...@twdata.org>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Thursday, October 14, 2004 11:30 AM
Subject: Re: CVS -> SVN / Roadmap
> Ted Husted wrote:
>
> >+1
> >
> >Let's stick to the roadmap we laid out in July.
> >
> >http://struts.apache.org/roadmap.html
> >
> >I'll update the site to reflect the CVS/SVN changes this weekend and
bring the roadmap page up to date.
> >
> >If James is up for rolling a 1.2.5 release, that's fine with me.
> >
> >Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x,
and bring down that-there Struts Chain gizmo. :)
> >
> >
> +1 I vote we (or perhaps I specifically) integrate struts-chain this
> weekend. It is stable, and I've been using it in production for some
> time without problems. Course that also means we (again, perhaps I
> specifically) should release commons-chain 1.0. Ted, there are a few
> Guinnesses in it if you help me with the documentation.... :)
>
> >And if Don wants to start setting up struts-flow and struts-scripting
along the same lines as struts-faces, I'll buy him a Guiness (or three) at
ApacheCon :)
> >
> >
> Ah, Guinness - the ultimate currency. You got yourself a deal.
>
> Don
>
> >-Ted.
> >
> >On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
> >
> >
> >> On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
> >> <an...@steinlein.no> wrote:
> >>
> >>
> >>> Forgive my possible ignorance, but what is the policy on new
> >>> releases? I've understood that we can release whenever we want,
> >>> that version numbers are cheap and that you vote whether to make
> >>> a release alpha/beta/GA. But, what goes into a release? Does new
> >>> features/enhancements go into a 1.2.x release, or is it strictly
> >>> bug fixes?
> >>>
> >>>
> >>>
> >>>
> >> What we've talked about before is along these lines:
> >>
> >> Within the 1.2.x series, it's fine to fix bugs and add new stuff,
> >> but not fine to make any backwards-incompatible changes.
> >>
> >> For a 1.3.x series, we could be more liberal about adding new
> >> stuff, and possibly have some deprecations in 1.2.x that get
> >> removed -- but it shoujld in general be based on similar enough
> >> architectural principles that there be a clear upgrade path.
> >>
> >> The challenge, of course, is when do you make that split for the
> >> evolutionary path? I'd say that something as fundamental as using
> >> Struts Chain instead of the monolithic RequestProcessor, and the
> >> other changes we could make as a result of having that, would be
> >> good grounds for a 1.3.x series. If that were to start in the
> >> short term, then thinking of 1.2.x as being in maintenance mode
> >> seems likely (although if there's willingness to port features back
> >> and forth, it need not go that way immediately ... for example,
> >> Tomcat 4.1.x continued to develop for a little while at the
> >> beginning of 5.0.x, including some features ported back and forth,
> >> but this pretty much stopped as soon as there was a solid 5.0.x
> >> release for people to use).
> >>
> >> For a 2.x chain, we could have the freedom to be somewhat more
> >> aggressive at rearchitecting ("if we'd known then what we know now,
> >> what would Struts have looked like?"), and could in theory have a
> >> series of alpha releases in parallel with stable releases on 1.2 or
> >> 1.3. As others have pointed out, how much simultanaeity there is,
> >> and how often releases happen, is more based on the directed energy
> >> of the committers (and what they want to work on), and less on
> >> whether there are parallel development efforts going on.
> >>
> >>
> >>
> >>> The reason I ask is because I would love releases much, much more
> >>> often, but as have been pointed out, incompatibilities/quirks
> >>> between minor versions could be a disaster.
> >>>
> >>>
> >>>
> >>>
> >> Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
> >> interoperability and upgrade, a bit on the edge of what most users
> >> liked, while the 1.1 -> 1.2 transition was much easier to do. We
> >> haven't actually gotten around to many x.y.z releases on 1.0 or
> >> 1.1, so having them happen at all in 1.2 should be a refreshing
> >> change :-). But I agree with you that compatibility is especially
> >> important within an x.y release cycle.
> >>
> >>
> >>
> >>> \Anders
> >>>
> >>>
> >>>
> >> Craig
> >>
> >> --------------------------------------------------------------------
> >> - 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN / Roadmap
Posted by Ted Husted <hu...@apache.org>.
I should be able to bring the Roadmap up to date later today (Friday), so you will be able to roll it over the weekend.
-Ted.
On Thu, 14 Oct 2004 15:40:56 -0700, Don Brown wrote:
> All that should remain is updating the roadmap, which I'll leave to
> folks more involved in the roadmap discussions. If there is
> anything else, let me know and I'll do it.
>
> Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN / Roadmap
Posted by Don Brown <mr...@twdata.org>.
All that should remain is updating the roadmap, which I'll leave to
folks more involved in the roadmap discussions. If there is anything
else, let me know and I'll do it.
Don
Craig McClanahan wrote:
>If you just refer to "build.xml" the docs should apply to a branch as
>well as they apply to the trunk. But it's worth mentioning "trunk" in
>the context of what URL you use to check out the repository in the
>first place.
>
>Craig
>
>
>On Thu, 14 Oct 2004 12:23:42 -0700, Don Brown <mr...@twdata.org> wrote:
>
>
>>I don't mind making those CVS to SVN documentation updates today. One
>>question though, are we assuming people checked Struts trunk out or the
>>entire Struts repository? This affects whether we refer to a file as
>>"trunk/build.xml" or just "build.xml".
>>
>>Don
>>
>>Martin Cooper wrote:
>>
>>
>>
>>
>>
>>>On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell <jm...@apache.org> wrote:
>>>
>>>
>>>
>>>
>>>>Are we not waiting for Ted's update? I haven't seen any commits come across
>>>>and I assumed he would do it this weekend....is this still true Ted?
>>>>
>>>>
>>>>
>>>>
>>>Yes, we should wait for Ted's updates. We do need to get the docs
>>>switched over to talk about SVN rather than CVS.
>>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>
>>>
>>>
>>>
>>>>--
>>>>James Mitchell
>>>>Software Engineer / Open Source Evangelist
>>>>EdgeTech, Inc.
>>>>678.910.8017
>>>>AIM: jmitchtx
>>>>
>>>>----- Original Message -----
>>>>From: "Don Brown" <mr...@twdata.org>
>>>>To: "Struts Developers List" <de...@struts.apache.org>
>>>>Sent: Thursday, October 14, 2004 1:49 PM
>>>>Subject: Re: CVS -> SVN / Roadmap
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Deal. Roll it James :)
>>>>>
>>>>>I'll integrate struts-chain and bring over struts-flow and struts-bsf as
>>>>>soon James cuts the release and creates the 1.2.x branch.
>>>>>
>>>>>Don
>>>>>
>>>>>Martin Cooper wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown <mr...@twdata.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Ted Husted wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>+1
>>>>>>>>
>>>>>>>>Let's stick to the roadmap we laid out in July.
>>>>>>>>
>>>>>>>>http://struts.apache.org/roadmap.html
>>>>>>>>
>>>>>>>>I'll update the site to reflect the CVS/SVN changes this weekend and
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>bring the roadmap page up to date.
>>>>
>>>>
>>>>
>>>>
>>>>>>>>If James is up for rolling a 1.2.5 release, that's fine with me.
>>>>>>>>
>>>>>>>>Either way, it may be time to call 1.2.x a branch and dub the head
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>1.3.x, and bring down that-there Struts Chain gizmo. :)
>>>>
>>>>
>>>>
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>+1 I vote we (or perhaps I specifically) integrate struts-chain this
>>>>>>>weekend. It is stable, and I've been using it in production for some
>>>>>>>time without problems. Course that also means we (again, perhaps I
>>>>>>>specifically) should release commons-chain 1.0. Ted, there are a few
>>>>>>>Guinnesses in it if you help me with the documentation.... :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x
>>>>>>build, then create a 1.2.x branch at that tag, and then roll in the
>>>>>>chain stuff as the first step on the 1.3.x ladder?
>>>>>>
>>>>>>--
>>>>>>Martin Cooper
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>And if Don wants to start setting up struts-flow and struts-scripting
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>along the same lines as struts-faces, I'll buy him a Guiness (or three) at
>>>>ApacheCon :)
>>>>
>>>>
>>>>
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>Ah, Guinness - the ultimate currency. You got yourself a deal.
>>>>>>>
>>>>>>>Don
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>-Ted.
>>>>>>>>
>>>>>>>>On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
>>>>>>>>><an...@steinlein.no> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Forgive my possible ignorance, but what is the policy on new
>>>>>>>>>>releases? I've understood that we can release whenever we want,
>>>>>>>>>>that version numbers are cheap and that you vote whether to make
>>>>>>>>>>a release alpha/beta/GA. But, what goes into a release? Does new
>>>>>>>>>>features/enhancements go into a 1.2.x release, or is it strictly
>>>>>>>>>>bug fixes?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>What we've talked about before is along these lines:
>>>>>>>>>
>>>>>>>>>Within the 1.2.x series, it's fine to fix bugs and add new stuff,
>>>>>>>>>but not fine to make any backwards-incompatible changes.
>>>>>>>>>
>>>>>>>>>For a 1.3.x series, we could be more liberal about adding new
>>>>>>>>>stuff, and possibly have some deprecations in 1.2.x that get
>>>>>>>>>removed -- but it shoujld in general be based on similar enough
>>>>>>>>>architectural principles that there be a clear upgrade path.
>>>>>>>>>
>>>>>>>>>The challenge, of course, is when do you make that split for the
>>>>>>>>>evolutionary path? I'd say that something as fundamental as using
>>>>>>>>>Struts Chain instead of the monolithic RequestProcessor, and the
>>>>>>>>>other changes we could make as a result of having that, would be
>>>>>>>>>good grounds for a 1.3.x series. If that were to start in the
>>>>>>>>>short term, then thinking of 1.2.x as being in maintenance mode
>>>>>>>>>seems likely (although if there's willingness to port features back
>>>>>>>>>and forth, it need not go that way immediately ... for example,
>>>>>>>>>Tomcat 4.1.x continued to develop for a little while at the
>>>>>>>>>beginning of 5.0.x, including some features ported back and forth,
>>>>>>>>>but this pretty much stopped as soon as there was a solid 5.0.x
>>>>>>>>>release for people to use).
>>>>>>>>>
>>>>>>>>>For a 2.x chain, we could have the freedom to be somewhat more
>>>>>>>>>aggressive at rearchitecting ("if we'd known then what we know now,
>>>>>>>>>what would Struts have looked like?"), and could in theory have a
>>>>>>>>>series of alpha releases in parallel with stable releases on 1.2 or
>>>>>>>>>1.3. As others have pointed out, how much simultanaeity there is,
>>>>>>>>>and how often releases happen, is more based on the directed energy
>>>>>>>>>of the committers (and what they want to work on), and less on
>>>>>>>>>whether there are parallel development efforts going on.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>The reason I ask is because I would love releases much, much more
>>>>>>>>>>often, but as have been pointed out, incompatibilities/quirks
>>>>>>>>>>between minor versions could be a disaster.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
>>>>>>>>>interoperability and upgrade, a bit on the edge of what most users
>>>>>>>>>liked, while the 1.1 -> 1.2 transition was much easier to do. We
>>>>>>>>>haven't actually gotten around to many x.y.z releases on 1.0 or
>>>>>>>>>1.1, so having them happen at all in 1.2 should be a refreshing
>>>>>>>>>change :-). But I agree with you that compatibility is especially
>>>>>>>>>important within an x.y release cycle.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>\Anders
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>Craig
>>>>>>>>>
>>>>>>>>>--------------------------------------------------------------------
>>>>>>>>>- 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN / Roadmap
Posted by Craig McClanahan <cr...@gmail.com>.
If you just refer to "build.xml" the docs should apply to a branch as
well as they apply to the trunk. But it's worth mentioning "trunk" in
the context of what URL you use to check out the repository in the
first place.
Craig
On Thu, 14 Oct 2004 12:23:42 -0700, Don Brown <mr...@twdata.org> wrote:
> I don't mind making those CVS to SVN documentation updates today. One
> question though, are we assuming people checked Struts trunk out or the
> entire Struts repository? This affects whether we refer to a file as
> "trunk/build.xml" or just "build.xml".
>
> Don
>
> Martin Cooper wrote:
>
>
>
> >On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell <jm...@apache.org> wrote:
> >
> >
> >>Are we not waiting for Ted's update? I haven't seen any commits come across
> >>and I assumed he would do it this weekend....is this still true Ted?
> >>
> >>
> >
> >Yes, we should wait for Ted's updates. We do need to get the docs
> >switched over to talk about SVN rather than CVS.
> >
> >--
> >Martin Cooper
> >
> >
> >
> >
> >>--
> >>James Mitchell
> >>Software Engineer / Open Source Evangelist
> >>EdgeTech, Inc.
> >>678.910.8017
> >>AIM: jmitchtx
> >>
> >>----- Original Message -----
> >>From: "Don Brown" <mr...@twdata.org>
> >>To: "Struts Developers List" <de...@struts.apache.org>
> >>Sent: Thursday, October 14, 2004 1:49 PM
> >>Subject: Re: CVS -> SVN / Roadmap
> >>
> >>
> >>
> >>>Deal. Roll it James :)
> >>>
> >>>I'll integrate struts-chain and bring over struts-flow and struts-bsf as
> >>>soon James cuts the release and creates the 1.2.x branch.
> >>>
> >>>Don
> >>>
> >>>Martin Cooper wrote:
> >>>
> >>>
> >>>
> >>>>On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown <mr...@twdata.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Ted Husted wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>+1
> >>>>>>
> >>>>>>Let's stick to the roadmap we laid out in July.
> >>>>>>
> >>>>>>http://struts.apache.org/roadmap.html
> >>>>>>
> >>>>>>I'll update the site to reflect the CVS/SVN changes this weekend and
> >>>>>>
> >>>>>>
> >>bring the roadmap page up to date.
> >>
> >>
> >>>>>>If James is up for rolling a 1.2.5 release, that's fine with me.
> >>>>>>
> >>>>>>Either way, it may be time to call 1.2.x a branch and dub the head
> >>>>>>
> >>>>>>
> >>1.3.x, and bring down that-there Struts Chain gizmo. :)
> >>
> >>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>+1 I vote we (or perhaps I specifically) integrate struts-chain this
> >>>>>weekend. It is stable, and I've been using it in production for some
> >>>>>time without problems. Course that also means we (again, perhaps I
> >>>>>specifically) should release commons-chain 1.0. Ted, there are a few
> >>>>>Guinnesses in it if you help me with the documentation.... :)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x
> >>>>build, then create a 1.2.x branch at that tag, and then roll in the
> >>>>chain stuff as the first step on the 1.3.x ladder?
> >>>>
> >>>>--
> >>>>Martin Cooper
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>And if Don wants to start setting up struts-flow and struts-scripting
> >>>>>>
> >>>>>>
> >>along the same lines as struts-faces, I'll buy him a Guiness (or three) at
> >>ApacheCon :)
> >>
> >>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>Ah, Guinness - the ultimate currency. You got yourself a deal.
> >>>>>
> >>>>>Don
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-Ted.
> >>>>>>
> >>>>>>On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
> >>>>>>><an...@steinlein.no> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Forgive my possible ignorance, but what is the policy on new
> >>>>>>>>releases? I've understood that we can release whenever we want,
> >>>>>>>>that version numbers are cheap and that you vote whether to make
> >>>>>>>>a release alpha/beta/GA. But, what goes into a release? Does new
> >>>>>>>>features/enhancements go into a 1.2.x release, or is it strictly
> >>>>>>>>bug fixes?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>What we've talked about before is along these lines:
> >>>>>>>
> >>>>>>>Within the 1.2.x series, it's fine to fix bugs and add new stuff,
> >>>>>>>but not fine to make any backwards-incompatible changes.
> >>>>>>>
> >>>>>>>For a 1.3.x series, we could be more liberal about adding new
> >>>>>>>stuff, and possibly have some deprecations in 1.2.x that get
> >>>>>>>removed -- but it shoujld in general be based on similar enough
> >>>>>>>architectural principles that there be a clear upgrade path.
> >>>>>>>
> >>>>>>>The challenge, of course, is when do you make that split for the
> >>>>>>>evolutionary path? I'd say that something as fundamental as using
> >>>>>>>Struts Chain instead of the monolithic RequestProcessor, and the
> >>>>>>>other changes we could make as a result of having that, would be
> >>>>>>>good grounds for a 1.3.x series. If that were to start in the
> >>>>>>>short term, then thinking of 1.2.x as being in maintenance mode
> >>>>>>>seems likely (although if there's willingness to port features back
> >>>>>>>and forth, it need not go that way immediately ... for example,
> >>>>>>>Tomcat 4.1.x continued to develop for a little while at the
> >>>>>>>beginning of 5.0.x, including some features ported back and forth,
> >>>>>>>but this pretty much stopped as soon as there was a solid 5.0.x
> >>>>>>>release for people to use).
> >>>>>>>
> >>>>>>>For a 2.x chain, we could have the freedom to be somewhat more
> >>>>>>>aggressive at rearchitecting ("if we'd known then what we know now,
> >>>>>>>what would Struts have looked like?"), and could in theory have a
> >>>>>>>series of alpha releases in parallel with stable releases on 1.2 or
> >>>>>>>1.3. As others have pointed out, how much simultanaeity there is,
> >>>>>>>and how often releases happen, is more based on the directed energy
> >>>>>>>of the committers (and what they want to work on), and less on
> >>>>>>>whether there are parallel development efforts going on.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>The reason I ask is because I would love releases much, much more
> >>>>>>>>often, but as have been pointed out, incompatibilities/quirks
> >>>>>>>>between minor versions could be a disaster.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
> >>>>>>>interoperability and upgrade, a bit on the edge of what most users
> >>>>>>>liked, while the 1.1 -> 1.2 transition was much easier to do. We
> >>>>>>>haven't actually gotten around to many x.y.z releases on 1.0 or
> >>>>>>>1.1, so having them happen at all in 1.2 should be a refreshing
> >>>>>>>change :-). But I agree with you that compatibility is especially
> >>>>>>>important within an x.y release cycle.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>\Anders
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>Craig
> >>>>>>>
> >>>>>>>--------------------------------------------------------------------
> >>>>>>>- 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>---------------------------------------------------------------------
> >>>>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
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >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: CVS -> SVN / Roadmap
Posted by Don Brown <mr...@twdata.org>.
I don't mind making those CVS to SVN documentation updates today. One
question though, are we assuming people checked Struts trunk out or the
entire Struts repository? This affects whether we refer to a file as
"trunk/build.xml" or just "build.xml".
Don
Martin Cooper wrote:
>On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell <jm...@apache.org> wrote:
>
>
>>Are we not waiting for Ted's update? I haven't seen any commits come across
>>and I assumed he would do it this weekend....is this still true Ted?
>>
>>
>
>Yes, we should wait for Ted's updates. We do need to get the docs
>switched over to talk about SVN rather than CVS.
>
>--
>Martin Cooper
>
>
>
>
>>--
>>James Mitchell
>>Software Engineer / Open Source Evangelist
>>EdgeTech, Inc.
>>678.910.8017
>>AIM: jmitchtx
>>
>>----- Original Message -----
>>From: "Don Brown" <mr...@twdata.org>
>>To: "Struts Developers List" <de...@struts.apache.org>
>>Sent: Thursday, October 14, 2004 1:49 PM
>>Subject: Re: CVS -> SVN / Roadmap
>>
>>
>>
>>>Deal. Roll it James :)
>>>
>>>I'll integrate struts-chain and bring over struts-flow and struts-bsf as
>>>soon James cuts the release and creates the 1.2.x branch.
>>>
>>>Don
>>>
>>>Martin Cooper wrote:
>>>
>>>
>>>
>>>>On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown <mr...@twdata.org> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Ted Husted wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>+1
>>>>>>
>>>>>>Let's stick to the roadmap we laid out in July.
>>>>>>
>>>>>>http://struts.apache.org/roadmap.html
>>>>>>
>>>>>>I'll update the site to reflect the CVS/SVN changes this weekend and
>>>>>>
>>>>>>
>>bring the roadmap page up to date.
>>
>>
>>>>>>If James is up for rolling a 1.2.5 release, that's fine with me.
>>>>>>
>>>>>>Either way, it may be time to call 1.2.x a branch and dub the head
>>>>>>
>>>>>>
>>1.3.x, and bring down that-there Struts Chain gizmo. :)
>>
>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>+1 I vote we (or perhaps I specifically) integrate struts-chain this
>>>>>weekend. It is stable, and I've been using it in production for some
>>>>>time without problems. Course that also means we (again, perhaps I
>>>>>specifically) should release commons-chain 1.0. Ted, there are a few
>>>>>Guinnesses in it if you help me with the documentation.... :)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x
>>>>build, then create a 1.2.x branch at that tag, and then roll in the
>>>>chain stuff as the first step on the 1.3.x ladder?
>>>>
>>>>--
>>>>Martin Cooper
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>And if Don wants to start setting up struts-flow and struts-scripting
>>>>>>
>>>>>>
>>along the same lines as struts-faces, I'll buy him a Guiness (or three) at
>>ApacheCon :)
>>
>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Ah, Guinness - the ultimate currency. You got yourself a deal.
>>>>>
>>>>>Don
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-Ted.
>>>>>>
>>>>>>On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
>>>>>>><an...@steinlein.no> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Forgive my possible ignorance, but what is the policy on new
>>>>>>>>releases? I've understood that we can release whenever we want,
>>>>>>>>that version numbers are cheap and that you vote whether to make
>>>>>>>>a release alpha/beta/GA. But, what goes into a release? Does new
>>>>>>>>features/enhancements go into a 1.2.x release, or is it strictly
>>>>>>>>bug fixes?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>What we've talked about before is along these lines:
>>>>>>>
>>>>>>>Within the 1.2.x series, it's fine to fix bugs and add new stuff,
>>>>>>>but not fine to make any backwards-incompatible changes.
>>>>>>>
>>>>>>>For a 1.3.x series, we could be more liberal about adding new
>>>>>>>stuff, and possibly have some deprecations in 1.2.x that get
>>>>>>>removed -- but it shoujld in general be based on similar enough
>>>>>>>architectural principles that there be a clear upgrade path.
>>>>>>>
>>>>>>>The challenge, of course, is when do you make that split for the
>>>>>>>evolutionary path? I'd say that something as fundamental as using
>>>>>>>Struts Chain instead of the monolithic RequestProcessor, and the
>>>>>>>other changes we could make as a result of having that, would be
>>>>>>>good grounds for a 1.3.x series. If that were to start in the
>>>>>>>short term, then thinking of 1.2.x as being in maintenance mode
>>>>>>>seems likely (although if there's willingness to port features back
>>>>>>>and forth, it need not go that way immediately ... for example,
>>>>>>>Tomcat 4.1.x continued to develop for a little while at the
>>>>>>>beginning of 5.0.x, including some features ported back and forth,
>>>>>>>but this pretty much stopped as soon as there was a solid 5.0.x
>>>>>>>release for people to use).
>>>>>>>
>>>>>>>For a 2.x chain, we could have the freedom to be somewhat more
>>>>>>>aggressive at rearchitecting ("if we'd known then what we know now,
>>>>>>>what would Struts have looked like?"), and could in theory have a
>>>>>>>series of alpha releases in parallel with stable releases on 1.2 or
>>>>>>>1.3. As others have pointed out, how much simultanaeity there is,
>>>>>>>and how often releases happen, is more based on the directed energy
>>>>>>>of the committers (and what they want to work on), and less on
>>>>>>>whether there are parallel development efforts going on.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>The reason I ask is because I would love releases much, much more
>>>>>>>>often, but as have been pointed out, incompatibilities/quirks
>>>>>>>>between minor versions could be a disaster.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
>>>>>>>interoperability and upgrade, a bit on the edge of what most users
>>>>>>>liked, while the 1.1 -> 1.2 transition was much easier to do. We
>>>>>>>haven't actually gotten around to many x.y.z releases on 1.0 or
>>>>>>>1.1, so having them happen at all in 1.2 should be a refreshing
>>>>>>>change :-). But I agree with you that compatibility is especially
>>>>>>>important within an x.y release cycle.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>\Anders
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>Craig
>>>>>>>
>>>>>>>--------------------------------------------------------------------
>>>>>>>- 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>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
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>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: CVS -> SVN / Roadmap
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell <jm...@apache.org> wrote:
> Are we not waiting for Ted's update? I haven't seen any commits come across
> and I assumed he would do it this weekend....is this still true Ted?
Yes, we should wait for Ted's updates. We do need to get the docs
switched over to talk about SVN rather than CVS.
--
Martin Cooper
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
>
> ----- Original Message -----
> From: "Don Brown" <mr...@twdata.org>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Thursday, October 14, 2004 1:49 PM
> Subject: Re: CVS -> SVN / Roadmap
>
> > Deal. Roll it James :)
> >
> > I'll integrate struts-chain and bring over struts-flow and struts-bsf as
> > soon James cuts the release and creates the 1.2.x branch.
> >
> > Don
> >
> > Martin Cooper wrote:
> >
> > >On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown <mr...@twdata.org> wrote:
> > >
> > >
> > >>Ted Husted wrote:
> > >>
> > >>
> > >>
> > >>>+1
> > >>>
> > >>>Let's stick to the roadmap we laid out in July.
> > >>>
> > >>>http://struts.apache.org/roadmap.html
> > >>>
> > >>>I'll update the site to reflect the CVS/SVN changes this weekend and
> bring the roadmap page up to date.
> > >>>
> > >>>If James is up for rolling a 1.2.5 release, that's fine with me.
> > >>>
> > >>>Either way, it may be time to call 1.2.x a branch and dub the head
> 1.3.x, and bring down that-there Struts Chain gizmo. :)
> > >>>
> > >>>
> > >>>
> > >>>
> > >>+1 I vote we (or perhaps I specifically) integrate struts-chain this
> > >>weekend. It is stable, and I've been using it in production for some
> > >>time without problems. Course that also means we (again, perhaps I
> > >>specifically) should release commons-chain 1.0. Ted, there are a few
> > >>Guinnesses in it if you help me with the documentation.... :)
> > >>
> > >>
> > >
> > >How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x
> > >build, then create a 1.2.x branch at that tag, and then roll in the
> > >chain stuff as the first step on the 1.3.x ladder?
> > >
> > >--
> > >Martin Cooper
> > >
> > >
> > >
> > >
> > >>>And if Don wants to start setting up struts-flow and struts-scripting
> along the same lines as struts-faces, I'll buy him a Guiness (or three) at
> ApacheCon :)
> > >>>
> > >>>
> > >>>
> > >>>
> > >>Ah, Guinness - the ultimate currency. You got yourself a deal.
> > >>
> > >>Don
> > >>
> > >>
> > >>
> > >>>-Ted.
> > >>>
> > >>>On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
> > >>>><an...@steinlein.no> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>Forgive my possible ignorance, but what is the policy on new
> > >>>>>releases? I've understood that we can release whenever we want,
> > >>>>>that version numbers are cheap and that you vote whether to make
> > >>>>>a release alpha/beta/GA. But, what goes into a release? Does new
> > >>>>>features/enhancements go into a 1.2.x release, or is it strictly
> > >>>>>bug fixes?
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>What we've talked about before is along these lines:
> > >>>>
> > >>>>Within the 1.2.x series, it's fine to fix bugs and add new stuff,
> > >>>>but not fine to make any backwards-incompatible changes.
> > >>>>
> > >>>>For a 1.3.x series, we could be more liberal about adding new
> > >>>>stuff, and possibly have some deprecations in 1.2.x that get
> > >>>>removed -- but it shoujld in general be based on similar enough
> > >>>>architectural principles that there be a clear upgrade path.
> > >>>>
> > >>>>The challenge, of course, is when do you make that split for the
> > >>>>evolutionary path? I'd say that something as fundamental as using
> > >>>>Struts Chain instead of the monolithic RequestProcessor, and the
> > >>>>other changes we could make as a result of having that, would be
> > >>>>good grounds for a 1.3.x series. If that were to start in the
> > >>>>short term, then thinking of 1.2.x as being in maintenance mode
> > >>>>seems likely (although if there's willingness to port features back
> > >>>>and forth, it need not go that way immediately ... for example,
> > >>>>Tomcat 4.1.x continued to develop for a little while at the
> > >>>>beginning of 5.0.x, including some features ported back and forth,
> > >>>>but this pretty much stopped as soon as there was a solid 5.0.x
> > >>>>release for people to use).
> > >>>>
> > >>>>For a 2.x chain, we could have the freedom to be somewhat more
> > >>>>aggressive at rearchitecting ("if we'd known then what we know now,
> > >>>>what would Struts have looked like?"), and could in theory have a
> > >>>>series of alpha releases in parallel with stable releases on 1.2 or
> > >>>>1.3. As others have pointed out, how much simultanaeity there is,
> > >>>>and how often releases happen, is more based on the directed energy
> > >>>>of the committers (and what they want to work on), and less on
> > >>>>whether there are parallel development efforts going on.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>The reason I ask is because I would love releases much, much more
> > >>>>>often, but as have been pointed out, incompatibilities/quirks
> > >>>>>between minor versions could be a disaster.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
> > >>>>interoperability and upgrade, a bit on the edge of what most users
> > >>>>liked, while the 1.1 -> 1.2 transition was much easier to do. We
> > >>>>haven't actually gotten around to many x.y.z releases on 1.0 or
> > >>>>1.1, so having them happen at all in 1.2 should be a refreshing
> > >>>>change :-). But I agree with you that compatibility is especially
> > >>>>important within an x.y release cycle.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>\Anders
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>Craig
> > >>>>
> > >>>>--------------------------------------------------------------------
> > >>>>- 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
> > >>
> > >>
> > >>
> > >>
> > >
> > >---------------------------------------------------------------------
> > >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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN / Roadmap
Posted by James Mitchell <jm...@apache.org>.
Are we not waiting for Ted's update? I haven't seen any commits come across
and I assumed he would do it this weekend....is this still true Ted?
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Don Brown" <mr...@twdata.org>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Thursday, October 14, 2004 1:49 PM
Subject: Re: CVS -> SVN / Roadmap
> Deal. Roll it James :)
>
> I'll integrate struts-chain and bring over struts-flow and struts-bsf as
> soon James cuts the release and creates the 1.2.x branch.
>
> Don
>
> Martin Cooper wrote:
>
> >On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown <mr...@twdata.org> wrote:
> >
> >
> >>Ted Husted wrote:
> >>
> >>
> >>
> >>>+1
> >>>
> >>>Let's stick to the roadmap we laid out in July.
> >>>
> >>>http://struts.apache.org/roadmap.html
> >>>
> >>>I'll update the site to reflect the CVS/SVN changes this weekend and
bring the roadmap page up to date.
> >>>
> >>>If James is up for rolling a 1.2.5 release, that's fine with me.
> >>>
> >>>Either way, it may be time to call 1.2.x a branch and dub the head
1.3.x, and bring down that-there Struts Chain gizmo. :)
> >>>
> >>>
> >>>
> >>>
> >>+1 I vote we (or perhaps I specifically) integrate struts-chain this
> >>weekend. It is stable, and I've been using it in production for some
> >>time without problems. Course that also means we (again, perhaps I
> >>specifically) should release commons-chain 1.0. Ted, there are a few
> >>Guinnesses in it if you help me with the documentation.... :)
> >>
> >>
> >
> >How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x
> >build, then create a 1.2.x branch at that tag, and then roll in the
> >chain stuff as the first step on the 1.3.x ladder?
> >
> >--
> >Martin Cooper
> >
> >
> >
> >
> >>>And if Don wants to start setting up struts-flow and struts-scripting
along the same lines as struts-faces, I'll buy him a Guiness (or three) at
ApacheCon :)
> >>>
> >>>
> >>>
> >>>
> >>Ah, Guinness - the ultimate currency. You got yourself a deal.
> >>
> >>Don
> >>
> >>
> >>
> >>>-Ted.
> >>>
> >>>On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
> >>>><an...@steinlein.no> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Forgive my possible ignorance, but what is the policy on new
> >>>>>releases? I've understood that we can release whenever we want,
> >>>>>that version numbers are cheap and that you vote whether to make
> >>>>>a release alpha/beta/GA. But, what goes into a release? Does new
> >>>>>features/enhancements go into a 1.2.x release, or is it strictly
> >>>>>bug fixes?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>What we've talked about before is along these lines:
> >>>>
> >>>>Within the 1.2.x series, it's fine to fix bugs and add new stuff,
> >>>>but not fine to make any backwards-incompatible changes.
> >>>>
> >>>>For a 1.3.x series, we could be more liberal about adding new
> >>>>stuff, and possibly have some deprecations in 1.2.x that get
> >>>>removed -- but it shoujld in general be based on similar enough
> >>>>architectural principles that there be a clear upgrade path.
> >>>>
> >>>>The challenge, of course, is when do you make that split for the
> >>>>evolutionary path? I'd say that something as fundamental as using
> >>>>Struts Chain instead of the monolithic RequestProcessor, and the
> >>>>other changes we could make as a result of having that, would be
> >>>>good grounds for a 1.3.x series. If that were to start in the
> >>>>short term, then thinking of 1.2.x as being in maintenance mode
> >>>>seems likely (although if there's willingness to port features back
> >>>>and forth, it need not go that way immediately ... for example,
> >>>>Tomcat 4.1.x continued to develop for a little while at the
> >>>>beginning of 5.0.x, including some features ported back and forth,
> >>>>but this pretty much stopped as soon as there was a solid 5.0.x
> >>>>release for people to use).
> >>>>
> >>>>For a 2.x chain, we could have the freedom to be somewhat more
> >>>>aggressive at rearchitecting ("if we'd known then what we know now,
> >>>>what would Struts have looked like?"), and could in theory have a
> >>>>series of alpha releases in parallel with stable releases on 1.2 or
> >>>>1.3. As others have pointed out, how much simultanaeity there is,
> >>>>and how often releases happen, is more based on the directed energy
> >>>>of the committers (and what they want to work on), and less on
> >>>>whether there are parallel development efforts going on.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>The reason I ask is because I would love releases much, much more
> >>>>>often, but as have been pointed out, incompatibilities/quirks
> >>>>>between minor versions could be a disaster.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
> >>>>interoperability and upgrade, a bit on the edge of what most users
> >>>>liked, while the 1.1 -> 1.2 transition was much easier to do. We
> >>>>haven't actually gotten around to many x.y.z releases on 1.0 or
> >>>>1.1, so having them happen at all in 1.2 should be a refreshing
> >>>>change :-). But I agree with you that compatibility is especially
> >>>>important within an x.y release cycle.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>\Anders
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Craig
> >>>>
> >>>>--------------------------------------------------------------------
> >>>>- 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
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >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: CVS -> SVN / Roadmap
Posted by Don Brown <mr...@twdata.org>.
Deal. Roll it James :)
I'll integrate struts-chain and bring over struts-flow and struts-bsf as
soon James cuts the release and creates the 1.2.x branch.
Don
Martin Cooper wrote:
>On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown <mr...@twdata.org> wrote:
>
>
>>Ted Husted wrote:
>>
>>
>>
>>>+1
>>>
>>>Let's stick to the roadmap we laid out in July.
>>>
>>>http://struts.apache.org/roadmap.html
>>>
>>>I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date.
>>>
>>>If James is up for rolling a 1.2.5 release, that's fine with me.
>>>
>>>Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :)
>>>
>>>
>>>
>>>
>>+1 I vote we (or perhaps I specifically) integrate struts-chain this
>>weekend. It is stable, and I've been using it in production for some
>>time without problems. Course that also means we (again, perhaps I
>>specifically) should release commons-chain 1.0. Ted, there are a few
>>Guinnesses in it if you help me with the documentation.... :)
>>
>>
>
>How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x
>build, then create a 1.2.x branch at that tag, and then roll in the
>chain stuff as the first step on the 1.3.x ladder?
>
>--
>Martin Cooper
>
>
>
>
>>>And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :)
>>>
>>>
>>>
>>>
>>Ah, Guinness - the ultimate currency. You got yourself a deal.
>>
>>Don
>>
>>
>>
>>>-Ted.
>>>
>>>On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
>>>
>>>
>>>
>>>
>>>>On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
>>>><an...@steinlein.no> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Forgive my possible ignorance, but what is the policy on new
>>>>>releases? I've understood that we can release whenever we want,
>>>>>that version numbers are cheap and that you vote whether to make
>>>>>a release alpha/beta/GA. But, what goes into a release? Does new
>>>>>features/enhancements go into a 1.2.x release, or is it strictly
>>>>>bug fixes?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>What we've talked about before is along these lines:
>>>>
>>>>Within the 1.2.x series, it's fine to fix bugs and add new stuff,
>>>>but not fine to make any backwards-incompatible changes.
>>>>
>>>>For a 1.3.x series, we could be more liberal about adding new
>>>>stuff, and possibly have some deprecations in 1.2.x that get
>>>>removed -- but it shoujld in general be based on similar enough
>>>>architectural principles that there be a clear upgrade path.
>>>>
>>>>The challenge, of course, is when do you make that split for the
>>>>evolutionary path? I'd say that something as fundamental as using
>>>>Struts Chain instead of the monolithic RequestProcessor, and the
>>>>other changes we could make as a result of having that, would be
>>>>good grounds for a 1.3.x series. If that were to start in the
>>>>short term, then thinking of 1.2.x as being in maintenance mode
>>>>seems likely (although if there's willingness to port features back
>>>>and forth, it need not go that way immediately ... for example,
>>>>Tomcat 4.1.x continued to develop for a little while at the
>>>>beginning of 5.0.x, including some features ported back and forth,
>>>>but this pretty much stopped as soon as there was a solid 5.0.x
>>>>release for people to use).
>>>>
>>>>For a 2.x chain, we could have the freedom to be somewhat more
>>>>aggressive at rearchitecting ("if we'd known then what we know now,
>>>>what would Struts have looked like?"), and could in theory have a
>>>>series of alpha releases in parallel with stable releases on 1.2 or
>>>>1.3. As others have pointed out, how much simultanaeity there is,
>>>>and how often releases happen, is more based on the directed energy
>>>>of the committers (and what they want to work on), and less on
>>>>whether there are parallel development efforts going on.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>The reason I ask is because I would love releases much, much more
>>>>>often, but as have been pointed out, incompatibilities/quirks
>>>>>between minor versions could be a disaster.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
>>>>interoperability and upgrade, a bit on the edge of what most users
>>>>liked, while the 1.1 -> 1.2 transition was much easier to do. We
>>>>haven't actually gotten around to many x.y.z releases on 1.0 or
>>>>1.1, so having them happen at all in 1.2 should be a refreshing
>>>>change :-). But I agree with you that compatibility is especially
>>>>important within an x.y release cycle.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>\Anders
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Craig
>>>>
>>>>--------------------------------------------------------------------
>>>>- 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
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>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: CVS -> SVN / Roadmap
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown <mr...@twdata.org> wrote:
> Ted Husted wrote:
>
> >+1
> >
> >Let's stick to the roadmap we laid out in July.
> >
> >http://struts.apache.org/roadmap.html
> >
> >I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date.
> >
> >If James is up for rolling a 1.2.5 release, that's fine with me.
> >
> >Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :)
> >
> >
> +1 I vote we (or perhaps I specifically) integrate struts-chain this
> weekend. It is stable, and I've been using it in production for some
> time without problems. Course that also means we (again, perhaps I
> specifically) should release commons-chain 1.0. Ted, there are a few
> Guinnesses in it if you help me with the documentation.... :)
How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x
build, then create a 1.2.x branch at that tag, and then roll in the
chain stuff as the first step on the 1.3.x ladder?
--
Martin Cooper
>
> >And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :)
> >
> >
> Ah, Guinness - the ultimate currency. You got yourself a deal.
>
> Don
>
> >-Ted.
> >
> >On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
> >
> >
> >> On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
> >> <an...@steinlein.no> wrote:
> >>
> >>
> >>> Forgive my possible ignorance, but what is the policy on new
> >>> releases? I've understood that we can release whenever we want,
> >>> that version numbers are cheap and that you vote whether to make
> >>> a release alpha/beta/GA. But, what goes into a release? Does new
> >>> features/enhancements go into a 1.2.x release, or is it strictly
> >>> bug fixes?
> >>>
> >>>
> >>>
> >>>
> >> What we've talked about before is along these lines:
> >>
> >> Within the 1.2.x series, it's fine to fix bugs and add new stuff,
> >> but not fine to make any backwards-incompatible changes.
> >>
> >> For a 1.3.x series, we could be more liberal about adding new
> >> stuff, and possibly have some deprecations in 1.2.x that get
> >> removed -- but it shoujld in general be based on similar enough
> >> architectural principles that there be a clear upgrade path.
> >>
> >> The challenge, of course, is when do you make that split for the
> >> evolutionary path? I'd say that something as fundamental as using
> >> Struts Chain instead of the monolithic RequestProcessor, and the
> >> other changes we could make as a result of having that, would be
> >> good grounds for a 1.3.x series. If that were to start in the
> >> short term, then thinking of 1.2.x as being in maintenance mode
> >> seems likely (although if there's willingness to port features back
> >> and forth, it need not go that way immediately ... for example,
> >> Tomcat 4.1.x continued to develop for a little while at the
> >> beginning of 5.0.x, including some features ported back and forth,
> >> but this pretty much stopped as soon as there was a solid 5.0.x
> >> release for people to use).
> >>
> >> For a 2.x chain, we could have the freedom to be somewhat more
> >> aggressive at rearchitecting ("if we'd known then what we know now,
> >> what would Struts have looked like?"), and could in theory have a
> >> series of alpha releases in parallel with stable releases on 1.2 or
> >> 1.3. As others have pointed out, how much simultanaeity there is,
> >> and how often releases happen, is more based on the directed energy
> >> of the committers (and what they want to work on), and less on
> >> whether there are parallel development efforts going on.
> >>
> >>
> >>
> >>> The reason I ask is because I would love releases much, much more
> >>> often, but as have been pointed out, incompatibilities/quirks
> >>> between minor versions could be a disaster.
> >>>
> >>>
> >>>
> >>>
> >> Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
> >> interoperability and upgrade, a bit on the edge of what most users
> >> liked, while the 1.1 -> 1.2 transition was much easier to do. We
> >> haven't actually gotten around to many x.y.z releases on 1.0 or
> >> 1.1, so having them happen at all in 1.2 should be a refreshing
> >> change :-). But I agree with you that compatibility is especially
> >> important within an x.y release cycle.
> >>
> >>
> >>
> >>> \Anders
> >>>
> >>>
> >>>
> >> Craig
> >>
> >> --------------------------------------------------------------------
> >> - 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN / Roadmap
Posted by Don Brown <mr...@twdata.org>.
Ted Husted wrote:
>+1
>
>Let's stick to the roadmap we laid out in July.
>
>http://struts.apache.org/roadmap.html
>
>I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date.
>
>If James is up for rolling a 1.2.5 release, that's fine with me.
>
>Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :)
>
>
+1 I vote we (or perhaps I specifically) integrate struts-chain this
weekend. It is stable, and I've been using it in production for some
time without problems. Course that also means we (again, perhaps I
specifically) should release commons-chain 1.0. Ted, there are a few
Guinnesses in it if you help me with the documentation.... :)
>And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :)
>
>
Ah, Guinness - the ultimate currency. You got yourself a deal.
Don
>-Ted.
>
>On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
>
>
>> On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
>> <an...@steinlein.no> wrote:
>>
>>
>>> Forgive my possible ignorance, but what is the policy on new
>>> releases? I've understood that we can release whenever we want,
>>> that version numbers are cheap and that you vote whether to make
>>> a release alpha/beta/GA. But, what goes into a release? Does new
>>> features/enhancements go into a 1.2.x release, or is it strictly
>>> bug fixes?
>>>
>>>
>>>
>>>
>> What we've talked about before is along these lines:
>>
>> Within the 1.2.x series, it's fine to fix bugs and add new stuff,
>> but not fine to make any backwards-incompatible changes.
>>
>> For a 1.3.x series, we could be more liberal about adding new
>> stuff, and possibly have some deprecations in 1.2.x that get
>> removed -- but it shoujld in general be based on similar enough
>> architectural principles that there be a clear upgrade path.
>>
>> The challenge, of course, is when do you make that split for the
>> evolutionary path? I'd say that something as fundamental as using
>> Struts Chain instead of the monolithic RequestProcessor, and the
>> other changes we could make as a result of having that, would be
>> good grounds for a 1.3.x series. If that were to start in the
>> short term, then thinking of 1.2.x as being in maintenance mode
>> seems likely (although if there's willingness to port features back
>> and forth, it need not go that way immediately ... for example,
>> Tomcat 4.1.x continued to develop for a little while at the
>> beginning of 5.0.x, including some features ported back and forth,
>> but this pretty much stopped as soon as there was a solid 5.0.x
>> release for people to use).
>>
>> For a 2.x chain, we could have the freedom to be somewhat more
>> aggressive at rearchitecting ("if we'd known then what we know now,
>> what would Struts have looked like?"), and could in theory have a
>> series of alpha releases in parallel with stable releases on 1.2 or
>> 1.3. As others have pointed out, how much simultanaeity there is,
>> and how often releases happen, is more based on the directed energy
>> of the committers (and what they want to work on), and less on
>> whether there are parallel development efforts going on.
>>
>>
>>
>>> The reason I ask is because I would love releases much, much more
>>> often, but as have been pointed out, incompatibilities/quirks
>>> between minor versions could be a disaster.
>>>
>>>
>>>
>>>
>> Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
>> interoperability and upgrade, a bit on the edge of what most users
>> liked, while the 1.1 -> 1.2 transition was much easier to do. We
>> haven't actually gotten around to many x.y.z releases on 1.0 or
>> 1.1, so having them happen at all in 1.2 should be a refreshing
>> change :-). But I agree with you that compatibility is especially
>> important within an x.y release cycle.
>>
>>
>>
>>> \Anders
>>>
>>>
>>>
>> Craig
>>
>> --------------------------------------------------------------------
>> - 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: CVS -> SVN / Roadmap
Posted by Ted Husted <hu...@apache.org>.
+1
Let's stick to the roadmap we laid out in July.
http://struts.apache.org/roadmap.html
I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date.
If James is up for rolling a 1.2.5 release, that's fine with me.
Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :)
And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :)
-Ted.
On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
>�On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
>�<an...@steinlein.no>�wrote:
>>�Forgive my possible ignorance, but what is the policy on new
>>�releases? I've understood that we can release whenever we want,
>>�that version numbers are cheap and that you vote whether to make
>>�a release alpha/beta/GA. But, what goes into a release? Does new
>>�features/enhancements go into a 1.2.x release, or is it strictly
>>�bug fixes?
>>
>>
>�What we've talked about before is along these lines:
>
>�Within the 1.2.x series, it's fine to fix bugs and add new stuff,
>�but not fine to make any backwards-incompatible changes.
>
>�For a 1.3.x series, we could be more liberal about adding new
>�stuff, and possibly have some deprecations in 1.2.x that get
>�removed -- but it shoujld in general be based on similar enough
>�architectural principles that there be a clear upgrade path.
>
>�The challenge, of course, is when do you make that split for the
>�evolutionary path? �I'd say that something as fundamental as using
>�Struts Chain instead of the monolithic RequestProcessor, and the
>�other changes we could make as a result of having that, would be
>�good grounds for a 1.3.x series. �If that were to start in the
>�short term, then thinking of 1.2.x as being in maintenance mode
>�seems likely (although if there's willingness to port features back
>�and forth, it need not go that way immediately ... for example,
>�Tomcat 4.1.x continued to develop for a little while at the
>�beginning of 5.0.x, including some features ported back and forth,
>�but this pretty much stopped as soon as there was a solid 5.0.x
>�release for people to use).
>
>�For a 2.x chain, we could have the freedom to be somewhat more
>�aggressive at rearchitecting ("if we'd known then what we know now,
>�what would Struts have looked like?"), and could in theory have a
>�series of alpha releases in parallel with stable releases on 1.2 or
>�1.3. �As others have pointed out, how much simultanaeity there is,
>�and how often releases happen, is more based on the directed energy
>�of the committers (and what they want to work on), and less on
>�whether there are parallel development efforts going on.
>
>>�The reason I ask is because I would love releases much, much more
>>�often, but as have been pointed out, incompatibilities/quirks
>>�between minor versions could be a disaster.
>>
>>
>�Historically, I'd say our 1.0 ->�1.1 transition was, in terms of
>�interoperability and upgrade, a bit on the edge of what most users
>�liked, while the 1.1 ->�1.2 transition was much easier to do. �We
>�haven't actually gotten around to many x.y.z releases on 1.0 or
>�1.1, so having them happen at all in 1.2 should be a refreshing
>�change :-). But I agree with you that compatibility is especially
>�important within an x.y release cycle.
>
>>�\Anders
>>
>�Craig
>
>�--------------------------------------------------------------------
>�- 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: CVS -> SVN
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
<an...@steinlein.no> wrote:
> Forgive my possible ignorance, but what is the policy on new releases?
> I've understood that we can release whenever we want, that version numbers
> are cheap and that you vote whether to make a release alpha/beta/GA. But,
> what goes into a release? Does new features/enhancements go into a 1.2.x
> release, or is it strictly bug fixes?
>
What we've talked about before is along these lines:
Within the 1.2.x series, it's fine to fix bugs and add new stuff, but
not fine to make any backwards-incompatible changes.
For a 1.3.x series, we could be more liberal about adding new stuff,
and possibly have some deprecations in 1.2.x that get removed -- but
it shoujld in general be based on similar enough architectural
principles that there be a clear upgrade path.
The challenge, of course, is when do you make that split for the
evolutionary path? I'd say that something as fundamental as using
Struts Chain instead of the monolithic RequestProcessor, and the other
changes we could make as a result of having that, would be good
grounds for a 1.3.x series. If that were to start in the short term,
then thinking of 1.2.x as being in maintenance mode seems likely
(although if there's willingness to port features back and forth, it
need not go that way immediately ... for example, Tomcat 4.1.x
continued to develop for a little while at the beginning of 5.0.x,
including some features ported back and forth, but this pretty much
stopped as soon as there was a solid 5.0.x release for people to use).
For a 2.x chain, we could have the freedom to be somewhat more
aggressive at rearchitecting ("if we'd known then what we know now,
what would Struts have looked like?"), and could in theory have a
series of alpha releases in parallel with stable releases on 1.2 or
1.3. As others have pointed out, how much simultanaeity there is, and
how often releases happen, is more based on the directed energy of the
committers (and what they want to work on), and less on whether there
are parallel development efforts going on.
> The reason I ask is because I would love releases much, much more often,
> but as have been pointed out, incompatibilities/quirks between minor
> versions could be a disaster.
>
Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
interoperability and upgrade, a bit on the edge of what most users
liked, while the 1.1 -> 1.2 transition was much easier to do. We
haven't actually gotten around to many x.y.z releases on 1.0 or 1.1,
so having them happen at all in 1.2 should be a refreshing change :-).
But I agree with you that compatibility is especially important
within an x.y release cycle.
> \Anders
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN
Posted by Ted Husted <hu...@apache.org>.
Works for me. I'm getting ready for a one-day trip on Thursday, but if it's not done by this weekend, I'll do it as soon as I get back.
On Wed, 13 Oct 2004 09:37:39 -0400, James Mitchell wrote:
> I'd like to roll a release after you are finished with that. I
> really, REALLY want to keep these rolling (about 1 every few weeks)
> which has the added benefit of (hopefully) breaking this bad habit
> we seem to be in (~18 month GA release cycle).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: CVS -> SVN
Posted by Anders Steinlein <an...@steinlein.no>.
Forgive my possible ignorance, but what is the policy on new releases?
I've understood that we can release whenever we want, that version numbers
are cheap and that you vote whether to make a release alpha/beta/GA. But,
what goes into a release? Does new features/enhancements go into a 1.2.x
release, or is it strictly bug fixes?
The reason I ask is because I would love releases much, much more often,
but as have been pointed out, incompatibilities/quirks between minor
versions could be a disaster.
\Anders
> -----Original Message-----
> From: James Mitchell [mailto:jmitchell@apache.org]
> Sent: 13. oktober 2004 15:38
> To: Struts Developers List
> Subject: Re: CVS -> SVN
>
> I'd like to roll a release after you are finished with that.
> I really, REALLY want to keep these rolling (about 1 every
> few weeks) which has the added benefit of (hopefully)
> breaking this bad habit we seem to be in (~18 month GA release cycle).
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS -> SVN
Posted by James Mitchell <jm...@apache.org>.
I'd like to roll a release after you are finished with that. I really,
REALLY want to keep these rolling (about 1 every few weeks) which has the
added benefit of (hopefully) breaking this bad habit we seem to be in (~18
month GA release cycle).
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Tuesday, October 12, 2004 10:15 AM
Subject: Re: CVS -> SVN
If no one beats me to it, I'll update the site and roadmap over this coming
weekend, to reflect the many changes we made over the last few weeks.
(Way to go Team Struts!)
-Ted.
On Sun, 10 Oct 2004 23:53:31 -0400, Addy Kapur wrote:
> on the Struts main page "CVS Repository" is listed under
> "Development" menu item. Should this be changed to "SVN Repository"
> as the repository has moved to SVN now?
>
> --------------------------------------------------------------------
> - 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: CVS -> SVN
Posted by Ted Husted <hu...@apache.org>.
If no one beats me to it, I'll update the site and roadmap over this coming weekend, to reflect the many changes we made over the last few weeks.
(Way to go Team Struts!)
-Ted.
On Sun, 10 Oct 2004 23:53:31 -0400, Addy Kapur wrote:
>�on the Struts main page "CVS Repository" is listed under
>�"Development" menu item. Should this be changed to "SVN Repository"
>�as the repository �has moved to SVN now?
>
>�--------------------------------------------------------------------
>�- 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
CVS -> SVN
Posted by Addy Kapur <ad...@gmail.com>.
on the Struts main page "CVS Repository" is listed under "Development"
menu item. Should this be changed to "SVN Repository" as the
repository has moved to SVN now?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Roadmap
Posted by Mike Stanley <ms...@mstanley.net>.
Joe Germuska wrote:
> At 6:18 PM -0400 10/10/04, Mike Stanley wrote:
>
>> Ted Husted wrote:
>>
>>> On Sun, 10 Oct 2004 16:04:40 -0400, Mike Stanley wrote:
>>>
>>>> Another simple suggstion I would like to make (enhancement request) -
>>>> it would be extremely powerful to add the property support that
>>>> exists for plugin configuration, to action and request processors.
>>>> This can go along way for special purpose actions. The parameter
>>>> attribute is ok - but too limiting (IMO).
>>>>
>>>
>>>
>>> Sounds good to me. You should file this with Bugzilla and attach a
>>> patch if you can.
>>>
>>> A related enhancement, which is long overdue, is
>>> * Enhance all configs to extend one configuration element from
>>> another, as is done with Tiles Definitions
>>>
>>> I'd dearly love to see a patch for this enhancement. It would make
>>> such a difference in so many Struts config files. And now that we're
>>> in the 1.3 zone, the gloves are off :)
>>>
>>>
>> That would be nice, and does make a lot of sense. This could lead to
>> the standardization of attribute names such as "className" a.k.a -
>> "type", "processorClass", "handler".... :-)
>
>
> I'm pretty sure that Ted was talking instead about inheriting
> configurations. For example, you could have an "address" dynaform
> that you extended so that various forms which all had common
> street/city, etc fields wouldn't require them to be redefined, and
> then you could extend the validation rules also, so that your rules
> would be consistent without duplicate configuration code.
ahh.. I see. I misread that.
> Note that, at least with ActionConfigs, there is an important
> difference between "type" and "className". "className" refers to the
> type of the ActionConfig itself, should you want to use a subclass
> (say, for custom properties) while "type" refers to the type of the
> Action which will be created to service the ActionConfig. This can be
> confusing, but they aren't synonymous. I'm not sure that I think
> that the other cases where you've named attributes shoudl all be
> standardized either, but maybe if it were laid out in front of me as a
> proposal, I'd think harder about it...
Hmmm... I wasn't aware you could specify an ActionConfig class
(subclass). In fact, I wasn't aware you could specify the className for
Form, Controllers, or Actions at all :-). How does this attribute work
with digester rules, dtd validation, etc?
I guess in this light, things are a bit different. I do still feel
there are some inconsistencies though. Some thoughts
- the use of "handler" in the exception element seems inconsistent. IMO
it would be more consistent to use "type" as the exception handler
class, and add an attribute "match" or "exceptionClass" for the
registered exception.
- in datasource, form, controller, message-resources, form-property and
action: className refers to the Config class. But in plugin, and
action forward: className is the type to instantiate.
- "name" is something I always felt was inconsistent. action refers to
the associated form bean, but in form bean and action forward elements
name is the unique identifier.
I did notice that there is a "set-property" mapping for all elements
(even form-properties which is a bit strange :-). Does this work like
it does in the PlugIn class for actions? I never noticed it before.
That's basically what I was referring to originally and I see the dtd
already supports it.
- Mike
>
> Joe
>
>
>
>> - Mike
>>
>>> -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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Roadmap
Posted by Joe Germuska <Jo...@Germuska.com>.
At 6:18 PM -0400 10/10/04, Mike Stanley wrote:
>Ted Husted wrote:
>
>>On Sun, 10 Oct 2004 16:04:40 -0400, Mike Stanley wrote:
>>
>>>Another simple suggstion I would like to make (enhancement request) -
>>> it would be extremely powerful to add the property support that
>>>exists for plugin configuration, to action and request processors.
>>>This can go along way for special purpose actions. The parameter
>>>attribute is ok - but too limiting (IMO).
>>>
>>>
>>
>>Sounds good to me. You should file this with Bugzilla and attach a
>>patch if you can.
>>
>>A related enhancement, which is long overdue, is
>>* Enhance all configs to extend one configuration element from
>>another, as is done with Tiles Definitions
>>
>>I'd dearly love to see a patch for this enhancement. It would make
>>such a difference in so many Struts config files. And now that
>>we're in the 1.3 zone, the gloves are off :)
>>
>>
>That would be nice, and does make a lot of sense. This could lead
>to the standardization of attribute names such as "className" a.k.a
>- "type", "processorClass", "handler".... :-)
I'm pretty sure that Ted was talking instead about inheriting
configurations. For example, you could have an "address" dynaform
that you extended so that various forms which all had common
street/city, etc fields wouldn't require them to be redefined, and
then you could extend the validation rules also, so that your rules
would be consistent without duplicate configuration code.
Note that, at least with ActionConfigs, there is an important
difference between "type" and "className". "className" refers to the
type of the ActionConfig itself, should you want to use a subclass
(say, for custom properties) while "type" refers to the type of the
Action which will be created to service the ActionConfig. This can
be confusing, but they aren't synonymous. I'm not sure that I think
that the other cases where you've named attributes shoudl all be
standardized either, but maybe if it were laid out in front of me as
a proposal, I'd think harder about it...
Joe
>- Mike
>
>>-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
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Roadmap
Posted by Mike Stanley <ms...@mstanley.net>.
Ted Husted wrote:
>On Sun, 10 Oct 2004 16:04:40 -0400, Mike Stanley wrote:
>
>
>> Another simple suggstion I would like to make (enhancement request) -
>> it would be extremely powerful to add the property support that
>> exists for plugin configuration, to action and request processors.
>> This can go along way for special purpose actions. The parameter
>> attribute is ok - but too limiting (IMO).
>>
>>
>
>Sounds good to me. You should file this with Bugzilla and attach a patch if you can.
>
>A related enhancement, which is long overdue, is
>
>* Enhance all configs to extend one configuration element from another, as is done with Tiles Definitions
>
>I'd dearly love to see a patch for this enhancement. It would make such a difference in so many Struts config files. And now that we're in the 1.3 zone, the gloves are off :)
>
>
>
That would be nice, and does make a lot of sense. This could lead to
the standardization of attribute names such as "className" a.k.a -
"type", "processorClass", "handler".... :-)
- Mike
>-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: Roadmap
Posted by Ted Husted <hu...@apache.org>.
On Sun, 10 Oct 2004 16:04:40 -0400, Mike Stanley wrote:
> Another simple suggstion I would like to make (enhancement request) -
> it would be extremely powerful to add the property support that
> exists for plugin configuration, to action and request processors.
> This can go along way for special purpose actions. The parameter
> attribute is ok - but too limiting (IMO).
Sounds good to me. You should file this with Bugzilla and attach a patch if you can.
A related enhancement, which is long overdue, is
* Enhance all configs to extend one configuration element from another, as is done with Tiles Definitions
I'd dearly love to see a patch for this enhancement. It would make such a difference in so many Struts config files. And now that we're in the 1.3 zone, the gloves are off :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Roadmap
Posted by Mike Stanley <ms...@mstanley.net>.
quick thoughts/suggestion - my pizza just came ;-)
* Action Form - Form Context
How about adopting XForms (http://www.w3.org/MarkUp/Forms/) as the model
for all Action Forms? This contains a model for representing everything
you spoke about in your email - basically the seperation of purpose
(data) and presentation. In addition, you could easily handle
transformation between xml form data and business objects in special
request processing commands, utilizing tools likes digester and/or
existing marshalling frameworks.
Also - just for the record. Revolution not evolution :-) Chain is
definitely a step in the right direction.
Another simple suggstion I would like to make (enhancement request) - it
would be extremely powerful to add the property support that exists for
plugin configuration, to action and request processors. This can go
along way for special purpose actions. The parameter attribute is ok -
but too limiting (IMO).
I have more to say.... but I'm hungry. I'll speak up later.
- Mike
Ted Husted wrote:
>To follow up some other threads about the "architectural vision" for Struts Next, I'd like to offer the following:
>
>----
>
>Most of us are torn whether to create Struts Next by evolution or revolution. I think what most of us revolutionaries really want to to create Struts Next by mutation. We're not displeased with Struts 1.x. It's just that we are still carrying around an appendix or two that muddle our "clear vision" of the Struts 1.x architecture.
>
>For Struts Next, whether we get there by evolution or mutation, I would envision three pillar components:
>
>* Request Processor
>* Action/View Context
>* Form Context
>
>--Request Processor--
>
>The core of the Struts core is now, and has always been, the Request Processor. In Struts 1.0, it was buried amongst other methods in the ActionServlet, but you could see that it was there. In Struts 1.1.x, we pulled it out for all to see. In Struts 1.3.x, we're installing a revolutionary Request Processor based on Commons Chain <http://jakarta.apache.org/commons/chain/>.
>
>For Struts Next, I'd imagine we'd continue using and refining the Struts Chain Request Processor. The (ironically-named) Chain gives us the flexibility to make Struts less like a framework and more like a toolkit for building frameworks. For example, in Struts 1.3, we already plan to offer an alternate Command Catalog that supports portlets.
>
>--Action/View Context--
>
>The hand maiden of a Chain of Responsibility is a Context. We've been batting around the idea of an ActionContext for some time. Joe brought it up again the other day. The basic idea is simple. Instead of passing around several members in a signature, we put them all in a JavaBean and Context, and pass this around instead.
>
>The idea of a ViewContext is similar, except that it is designed to expose everything a View would want to know about Struts as a single, coherent JavaBean or Context.
>
>There was an experimental implementation, called the ConfigHelper, in February 2002
>
><http://tinyurl.com/3t3m9>
>
>which was used as the basis of the ActionConfig of December 2002
>
><http://tinyurl.com/3jwpj>
>
>In Struts Next, I would imagine that an ActionContext is used internally by the RequestProcessor and a ViewContext is exposed to the page or dialog. The difference being that the ViewContext would free of web semantics, so it could be used without change on any platform.
>
>--Form Context--
>
>We have a love/hate relationship with ActionForms. One of the big things Struts Chain buys will be the ability to easily change how automatic population takes place. If you don't like that link in the chain, you can change it just by changing the default XML catalog descriptor.
>
>The ActionForm filled a lot of roles in Struts 1.x, and I think some people will want to keep it. I've also used WebWork type frameworks. They are simpler than the Struts Action/ActionForm combo, and in some ways better, but there are still pieces missing.
>
>IMHO, what we need is a complete metadescription of the UI controls and forms (collections of controls) an application is using. If we combine the DynaActionForm with the ValidatorForm, we already have 80% of what we need. But, I believe, we should also be able to define a default control, a UI label, a UI "hint", and a default conversion/transformation method. (The latter is already implied by the validation.)
>
>The end game should be that if we pass this description to a smart control, it should be able to render a basic input or output form.
>
>Of course, basic is never good enough, so we would also want to be able to pass it to individual controls who would render part of the form. But, the proof of concept should be:
>
><struts:form readonly="false"/>
>
>and have a complete input form, with labels and hints, dropdown lists, and or
>
><struts:form readonly="true"/>
>
>and get the non-input version.
>
>The conventional Struts paradigm would remaint the same. But instead of controls looking to the request, session, or application contexts for a JavaBean/ActionForm, they would look to the ViewContext for a FormContext (or collection of FormContexts). But the FormContext would not only carry the value of the control, but its label, hint, and other attributes.
>
>Another important role for a FormContext is to serve as a JavaBean factory. What most of really want to do is to say to a *valid* FormContext: "It's great that the input is valid, now can I have those values in a business object, please".
>
>The idea being that if we specify in the XML descriptor what type we want each (string) attribute of the FormContext to create, and the context could then create the target type for each attribute and us them to populate a JavaBean, and return the populated instance, ready to hand off to your business logic. (Something like a JSF Managed Bean.)
>
>The FromProc tool in SourceForge does this sort of thing now <http://sourceforge.net/projects/formproc>. Instead of just validating the input, as we do with the Commons Validator, it validates the input and then converts it to a target object.
>
>--Testability--
>
>A fourth pillar has to be testability. The original Struts implementation was created just before the interest in JUnit began to peak. Struts Next has to be testable from square one, and we must avoid any designs which are difficult to test.
>
>--
>
>Personally, I believe the original Struts scenario is sound, which is why it has lasted so long.
>
>(0) Client submits request
>(1) System receives the incoming request
>(2) System transfers matching values to a form object
>(3) System validates the object
>(4) System branches to success or failure.
>(4a) On success, system executes/delegates the business logic.
>(4b) On failure, system returns the faulty input.
>(5) A view displays the nominal result or redisplays faulty input.
>
>We just need to identify what improvements we need to make at each step, and any additional steps we'd like to add.
>
>It might be interesting to expand this quick list into a formal set of use-case scenarios. If you have UML Distilled, Fowler mentions scenarios at the opening of Chapter 3.
>
>-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: Roadmap
Posted by Mike Stanley <ms...@mstanley.net>.
<snip>
> The other thing I would add is strong debuggability. Is it true that Tapestry's web
> debugging is the best of the current crop of web application frameworks?
"Line precise error messages" - are very useful. This however, is not
as easy with a JSP engine, given the nature of JSP (template -> source
-> compile -> class). Tapestry has the benefit of using it's own html
template parser. This provides greater flexibility in terms of
"knowing" where something goes wrong.
Struts could improve it's configuration error messages.
Perhaps someone could write a utility for describing a JspException.
Those can be confusing. lots of nested, stacks.
But I'm afraid, as long as JSP is the "view", error messages will always
lack that of Tapestry.
- Mike
>
>
>
> > --
> >
> > Personally, I believe the original Struts scenario is sound, which is why it has lasted so
> > long.
> >
> > (0) Client submits request (1) System receives the incoming request (2) System transfers
> > matching values to a form object (3) System validates the object (4) System branches to
> > success or failure. (4a) On success, system executes/delegates the business logic. (4b) On
> > failure, system returns the faulty input. (5) A view displays the nominal result or
> > redisplays faulty input.
> >
> > We just need to identify what improvements we need to make at each step, and any additional
> > steps we'd like to add.
> >
> > It might be interesting to expand this quick list into a formal set of use-case scenarios. If
> > you have UML Distilled, Fowler mentions scenarios at the opening of Chapter 3.
> >
> > -Ted.
> >
> >
> >
> > --------------------------------------------------------------------- To unsubscribe, e-mail:
> > dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
Re: Roadmap
Posted by "Peter A. Pilgrim" <pe...@xenonsoft.demon.co.uk>.
Ted Husted wrote:
> To follow up some other threads about the "architectural vision" for Struts Next, I'd like to
> offer the following:
>
> ----
>
> Most of us are torn whether to create Struts Next by evolution or revolution. I think what
> most of us revolutionaries really want to to create Struts Next by mutation. We're not
> displeased with Struts 1.x. It's just that we are still carrying around an appendix or two
> that muddle our "clear vision" of the Struts 1.x architecture.
>
> For Struts Next, whether we get there by evolution or mutation, I would envision three pillar
> components:
>
> * Request Processor * Action/View Context * Form Context
>
> --Request Processor--
>
> The core of the Struts core is now, and has always been, the Request Processor. In Struts
> 1.0, it was buried amongst other methods in the ActionServlet, but you could see that it was
> there. In Struts 1.1.x, we pulled it out for all to see. In Struts 1.3.x, we're installing a
> revolutionary Request Processor based on Commons Chain
> <http://jakarta.apache.org/commons/chain/>.
>
> For Struts Next, I'd imagine we'd continue using and refining the Struts Chain Request
> Processor. The (ironically-named) Chain gives us the flexibility to make Struts less like a
> framework and more like a toolkit for building frameworks. For example, in Struts 1.3, we
> already plan to offer an alternate Command Catalog that supports portlets.
>
> --Action/View Context--
>
> The hand maiden of a Chain of Responsibility is a Context. We've been batting around the idea
> of an ActionContext for some time. Joe brought it up again the other day. The basic idea is
> simple. Instead of passing around several members in a signature, we put them all in a
> JavaBean and Context, and pass this around instead.
>
> The idea of a ViewContext is similar, except that it is designed to expose everything a View
> would want to know about Struts as a single, coherent JavaBean or Context.
>
> There was an experimental implementation, called the ConfigHelper, in February 2002
>
> <http://tinyurl.com/3t3m9>
>
> which was used as the basis of the ActionConfig of December 2002
>
> <http://tinyurl.com/3jwpj>
>
All well and good.
The ViewContext is responsible for the output is an Action. Is that what you
are saying?
> In Struts Next, I would imagine that an ActionContext is used internally by the
> RequestProcessor and a ViewContext is exposed to the page or dialog. The difference being
> that the ViewContext would free of web semantics, so it could be used without change on any
> platform.
>
> --Form Context--
>
> We have a love/hate relationship with ActionForms. One of the big things Struts Chain buys
> will be the ability to easily change how automatic population takes place. If you don't like
> that link in the chain, you can change it just by changing the default XML catalog
> descriptor.
>
> The ActionForm filled a lot of roles in Struts 1.x, and I think some people will want to keep
> it. I've also used WebWork type frameworks. They are simpler than the Struts
> Action/ActionForm combo, and in some ways better, but there are still pieces missing.
>
> IMHO, what we need is a complete metadescription of the UI controls and forms (collections of
> controls) an application is using. If we combine the DynaActionForm with the ValidatorForm,
> we already have 80% of what we need. But, I believe, we should also be able to define a
> default control, a UI label, a UI "hint", and a default conversion/transformation method.
> (The latter is already implied by the validation.)
>
> The end game should be that if we pass this description to a smart control, it should be able
> to render a basic input or output form.
>
This does sound like JavaServer Faces to me. It is an another intermediate rendering language
expressed as Java object. Sounds to be like reverse of the Element Construction Set (ECS)
again but in abstract form.
> Of course, basic is never good enough, so we would also want to be able to pass it to
> individual controls who would render part of the form. But, the proof of concept should be:
>
> <struts:form readonly="false"/>
>
> and have a complete input form, with labels and hints, dropdown lists, and or
>
> <struts:form readonly="true"/>
>
> and get the non-input version.
>
> The conventional Struts paradigm would remaint the same. But instead of controls looking to
> the request, session, or application contexts for a JavaBean/ActionForm, they would look to
> the ViewContext for a FormContext (or collection of FormContexts). But the FormContext would
> not only carry the value of the control, but its label, hint, and other attributes.
Ok in the HTTP environment, I think you pushing an old idea that we pass context around
instead of long parameter arguments. So one of these contexts FormContext and/or
ViewContext, a subclass implementation, will hold the HttpServletRequest and
HttpServletResponse objects etc. Is this how it works?
>
> Another important role for a FormContext is to serve as a JavaBean factory. What most of
> really want to do is to say to a *valid* FormContext: "It's great that the input is valid,
> now can I have those values in a business object, please".
>
> The idea being that if we specify in the XML descriptor what type we want each (string)
> attribute of the FormContext to create, and the context could then create the target type for
> each attribute and us them to populate a JavaBean, and return the populated instance, ready
> to hand off to your business logic. (Something like a JSF Managed Bean.)
>
Yes by gum I was right about JSF incluence. If you are going to create JavaBeans, what
about creating beans by proxy such as IoC container. In your FormContext bean creation
message thing, I would hope that you divorce the actual creation logic, so one can
plugin there own service assembler.
> The FromProc tool in SourceForge does this sort of thing now
> <http://sourceforge.net/projects/formproc>. Instead of just validating the input, as we do
> with the Commons Validator, it validates the input and then converts it to a target object.
>
What happens if your object is expensive to create?
> --Testability--
>
> A fourth pillar has to be testability. The original Struts implementation was created just
> before the interest in JUnit began to peak. Struts Next has to be testable from square one,
> and we must avoid any designs which are difficult to test.
>
Outside of container test is a boon. Pushing the submit from the command line or DOS prompt
is lot easier than firing up tomcat or redeploying to web logic each time.
The other thing I would add is strong debuggability. Is it true that Tapestry's web
debugging is the best of the current crop of web application frameworks?
> --
>
> Personally, I believe the original Struts scenario is sound, which is why it has lasted so
> long.
>
> (0) Client submits request (1) System receives the incoming request (2) System transfers
> matching values to a form object (3) System validates the object (4) System branches to
> success or failure. (4a) On success, system executes/delegates the business logic. (4b) On
> failure, system returns the faulty input. (5) A view displays the nominal result or
> redisplays faulty input.
>
> We just need to identify what improvements we need to make at each step, and any additional
> steps we'd like to add.
>
> It might be interesting to expand this quick list into a formal set of use-case scenarios. If
> you have UML Distilled, Fowler mentions scenarios at the opening of Chapter 3.
>
> -Ted.
>
>
>
> --------------------------------------------------------------------- To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
--
Peter Pilgrim
__ _____ _____ _____
/ //__ // ___// ___/ + Serverside Java
/ /___/ // /__ / /__ + Struts
/ // ___// ___// ___/ + Expresso Committer
__/ // /__ / /__ / /__ + Independent Contractor
/___//____//____//____/ + Intrinsic Motivation
On Line Resume
||
\\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Roadmap
Posted by Ted Husted <hu...@apache.org>.
To follow up some other threads about the "architectural vision" for Struts Next, I'd like to offer the following:
----
Most of us are torn whether to create Struts Next by evolution or revolution. I think what most of us revolutionaries really want to to create Struts Next by mutation. We're not displeased with Struts 1.x. It's just that we are still carrying around an appendix or two that muddle our "clear vision" of the Struts 1.x architecture.
For Struts Next, whether we get there by evolution or mutation, I would envision three pillar components:
* Request Processor
* Action/View Context
* Form Context
--Request Processor--
The core of the Struts core is now, and has always been, the Request Processor. In Struts 1.0, it was buried amongst other methods in the ActionServlet, but you could see that it was there. In Struts 1.1.x, we pulled it out for all to see. In Struts 1.3.x, we're installing a revolutionary Request Processor based on Commons Chain <http://jakarta.apache.org/commons/chain/>.
For Struts Next, I'd imagine we'd continue using and refining the Struts Chain Request Processor. The (ironically-named) Chain gives us the flexibility to make Struts less like a framework and more like a toolkit for building frameworks. For example, in Struts 1.3, we already plan to offer an alternate Command Catalog that supports portlets.
--Action/View Context--
The hand maiden of a Chain of Responsibility is a Context. We've been batting around the idea of an ActionContext for some time. Joe brought it up again the other day. The basic idea is simple. Instead of passing around several members in a signature, we put them all in a JavaBean and Context, and pass this around instead.
The idea of a ViewContext is similar, except that it is designed to expose everything a View would want to know about Struts as a single, coherent JavaBean or Context.
There was an experimental implementation, called the ConfigHelper, in February 2002
<http://tinyurl.com/3t3m9>
which was used as the basis of the ActionConfig of December 2002
<http://tinyurl.com/3jwpj>
In Struts Next, I would imagine that an ActionContext is used internally by the RequestProcessor and a ViewContext is exposed to the page or dialog. The difference being that the ViewContext would free of web semantics, so it could be used without change on any platform.
--Form Context--
We have a love/hate relationship with ActionForms. One of the big things Struts Chain buys will be the ability to easily change how automatic population takes place. If you don't like that link in the chain, you can change it just by changing the default XML catalog descriptor.
The ActionForm filled a lot of roles in Struts 1.x, and I think some people will want to keep it. I've also used WebWork type frameworks. They are simpler than the Struts Action/ActionForm combo, and in some ways better, but there are still pieces missing.
IMHO, what we need is a complete metadescription of the UI controls and forms (collections of controls) an application is using. If we combine the DynaActionForm with the ValidatorForm, we already have 80% of what we need. But, I believe, we should also be able to define a default control, a UI label, a UI "hint", and a default conversion/transformation method. (The latter is already implied by the validation.)
The end game should be that if we pass this description to a smart control, it should be able to render a basic input or output form.
Of course, basic is never good enough, so we would also want to be able to pass it to individual controls who would render part of the form. But, the proof of concept should be:
<struts:form readonly="false"/>
and have a complete input form, with labels and hints, dropdown lists, and or
<struts:form readonly="true"/>
and get the non-input version.
The conventional Struts paradigm would remaint the same. But instead of controls looking to the request, session, or application contexts for a JavaBean/ActionForm, they would look to the ViewContext for a FormContext (or collection of FormContexts). But the FormContext would not only carry the value of the control, but its label, hint, and other attributes.
Another important role for a FormContext is to serve as a JavaBean factory. What most of really want to do is to say to a *valid* FormContext: "It's great that the input is valid, now can I have those values in a business object, please".
The idea being that if we specify in the XML descriptor what type we want each (string) attribute of the FormContext to create, and the context could then create the target type for each attribute and us them to populate a JavaBean, and return the populated instance, ready to hand off to your business logic. (Something like a JSF Managed Bean.)
The FromProc tool in SourceForge does this sort of thing now <http://sourceforge.net/projects/formproc>. Instead of just validating the input, as we do with the Commons Validator, it validates the input and then converts it to a target object.
--Testability--
A fourth pillar has to be testability. The original Struts implementation was created just before the interest in JUnit began to peak. Struts Next has to be testable from square one, and we must avoid any designs which are difficult to test.
--
Personally, I believe the original Struts scenario is sound, which is why it has lasted so long.
(0) Client submits request
(1) System receives the incoming request
(2) System transfers matching values to a form object
(3) System validates the object
(4) System branches to success or failure.
(4a) On success, system executes/delegates the business logic.
(4b) On failure, system returns the faulty input.
(5) A view displays the nominal result or redisplays faulty input.
We just need to identify what improvements we need to make at each step, and any additional steps we'd like to add.
It might be interesting to expand this quick list into a formal set of use-case scenarios. If you have UML Distilled, Fowler mentions scenarios at the opening of Chapter 3.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Roadmap was (Re: [VOTE] Move minimum to 2.3 ..)
Posted by Susan Bradeen <Su...@softlanding.com>.
IMO, FWIW ...
Ted Husted <hu...@apache.org> wrote on 09/03/2004 07:11:48 AM:
> OK, to sum up what people seem to be saying here:
>
> [Struts 1.2.x]
>
> * The minimums for 1.2.3 will remain Servlet 2.2
>
> * We create a branch at the 1.2.3 tag, in case we need to make
> critical fixes to 1.2.x later.
>
+1
> [Struts HEAD]
>
> * For now, Struts HEAD can remain in evolutionary mode, but we will
> bump the minimum to Servlet 2.3. At this point in time, this seems
> like a minor change, and so for the purposes of the Roadmap, we
> could assume the next release will be 1.3.0. But the final decision
> is up to the PMC when there's something to ready to release. (
>
+1
> * If anyone on the PMC feels strongly about the versioning, we can
> change all the markers on the Roadmap, so features slotted for 1.3.x
> ascribe to 2.0.x, and so forth, but that seems like a lot of churn
> for little benefit
>
> * Some of the reasons we are moving to Servlet 2.3 are:
>
> * It is preferred platform of active Struts developers.
> * It is needed for certain enhancements, including some to file
upload.
> * It simplifies distribution and integration of JavaServer Faces
> components which are dependant on Servlet 2.3.
>
Agree.
> * If at any time, we decide to move the HEAD to revolutionary mode,
> so as to stretch or break backward-compatibility, we can branch
> again, and assume that the HEAD will become 2.0.0 at the next
> release. But, we don't have to make that decision until a
> revolutionary commit is pending :)
>
+2
> * So far, items like Struts Chain count as evolutionary, since it
> seems we will be extending the API to support other "Action"
> signatures (e.g. for Portlets), but not removing the old ones. (As
> we did when we changed the signature for Exception handling.)
>
> [Struts NEXT]
>
<snip/>
Susan Bradeen
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org