Re: Struts 1.3.5 distribution snapshots updated
On 7/4/06, Wendy Smoak [EMAIL PROTECTED] wrote: The struts-master v3 pom is available in the snapshot repo, so as long as it looks good, the parent tag in struts1/pom.xml can be changed: 3-SNAPSHOT - 3. Done. The repository ids for distributionManagement have been consolidated. If you're using a private key or password in settings.xml, take another look at the suggested settings on the StrutsMaintenanceMaven wiki page. You should only need 'apache.snapshots' and 'apache-site' now. Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release the struts-master pom v3
+1 -- James Mitchell On Jul 5, 2006, at 1:05 AM, Wendy Smoak wrote: It's time to release version 3 of the struts-master pom: * http://svn.apache.org/repos/asf/struts/maven/trunk/pom/pom.xml This is the master pom from which struts-parent inherits, and it needs to be released prior to Struts 1.3.5. Changes since v2 include: - Change the artifactId to struts-master. - Upgrade to the latest Apache master pom, version 2. - Override the repository so that we always release to the snapshot repo. - Added Paul, Michael and Bob as committers. - Added scm info so we can build with Continuum. Here's my +1. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1
On 7/1/06, Don Brown (JIRA) [EMAIL PROTECTED] wrote: Rename Struts Action 1 to Struts 1 If we are using struts1 and struts2 for the repository folders (which is fine with me), why are we using 1.x and 2.0 for the website folders? * http://struts.apache.org/1.x/ * http://struts.apache.org/2.0/ In the view of convention over configuration, I feel we we should work toward using a consistent set of conventions across tools. If there is not a technical reason why we need to use symbols, I'd like to use struts1 and struts2 for the website folders. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.3.5 distribution snapshots updated
On 7/5/06, Wendy Smoak [EMAIL PROTECTED] wrote: Ted is threatening to roll 1.3.5 any day now Yes, I'm reviewing the release plans for 1.3.5 and 2.0 today, and wrapping up any outstanding issues (especially STR-2898). I'm glad to see how busy everyone has been over the weekend. It looks like a lot of the heavy-lifting is already done! -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
See * http://issues.apache.org/struts/browse/STR-2898 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write JUnit test case to an Action class which extends TilesAction
Right now, only the Struts Dev forum is available as a OS Forum.
The best place to post a question like this is the Struts User list,
where there are more people to help and the answers are archived.
* http://struts.apache.org/mail.html
-Ted.
On 7/3/06, Ashok Kumar Y [EMAIL PROTECTED] wrote:
Hi,
I am working with Struts Action class which extends TilesAction class. Below is
the sample code.I need to write JUnit Test case for that. If anyone have
worked. Could u help me regarding this.
public class DisplayLayoutareaController extends TilesAction implements
Controller
{
public void execute(ComponentContext tileContext,
HttpServletRequest request, HttpServletResponse response,
ServletContext servletContext)
{
//some code
}
public void perform(ComponentContext tileContext,
HttpServletRequest request,HttpServletResponse response,
ServletContext servletContext) throws ServletException,
java.io.IOException
{
//
}
}
Thanks Regards
Ashok
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=36264messageID=71055#71055
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
HTH, Ted.
* http://www.husted.com/struts/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release the struts-master pom v3
+1 James Mitchell wrote: +1 -- James Mitchell On Jul 5, 2006, at 1:05 AM, Wendy Smoak wrote: It's time to release version 3 of the struts-master pom: * http://svn.apache.org/repos/asf/struts/maven/trunk/pom/pom.xml This is the master pom from which struts-parent inherits, and it needs to be released prior to Struts 1.3.5. Changes since v2 include: - Change the artifactId to struts-master. - Upgrade to the latest Apache master pom, version 2. - Override the repository so that we always release to the snapshot repo. - Added Paul, Michael and Bob as committers. - Added scm info so we can build with Continuum. Here's my +1. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1
I chose 1.x and 2.0 because I think it fits better with the other archived web sites. The struts1 and struts2 names are more for internal use and in particular, struts1 is only used in svn due to the maven workaround. I think 1.x and 2.0, as well as the past 1.2.9 and so on, is easier for the user to guess and remember. Don Ted Husted wrote: On 7/1/06, Don Brown (JIRA) [EMAIL PROTECTED] wrote: Rename Struts Action 1 to Struts 1 If we are using struts1 and struts2 for the repository folders (which is fine with me), why are we using 1.x and 2.0 for the website folders? * http://struts.apache.org/1.x/ * http://struts.apache.org/2.0/ In the view of convention over configuration, I feel we we should work toward using a consistent set of conventions across tools. If there is not a technical reason why we need to use symbols, I'd like to use struts1 and struts2 for the website folders. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to call java script in jspx ?
it is configured, it doesn't help - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=36323messageID=71456#71456 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
I hate to bring this question back, but do we have a final decision on how 1.x and 2.x codebases are treated name-wise and what is the official way to refer to a product/version? Because seems that Don, for example, have a different idea on naming: I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1, etc... The whole point of this proposal is to unify Struts as a single project, getting away from this concept of separately versioned subprojects. There will be Struts 1.x releases, and there will be Struts 2.x releases, and perhaps some day, Struts 3.x releases. I would prefer having Struts 1 and Struts 2 *names* as you stated, but to Don and some others these are just different *versions of one product* , and apparently should be written as Struts 1.x or Struts 2.x [ Approach 1: generations/branches ] * Struts 1.x, 2.x and any consecutive codebases is collectively called Struts Framework (full name) or just Struts (short name). BTW, Have we decided to drop Action or the full official name is Struts Action Framework? * Struts 1.x codebase is collectively called Struts 1 where 1 is part of the name. * Struts 2.x codebase and any concecutive codebases is collectively called Struts 2; 2 is part of the name. [ Approach 2: one unified product] * Struts 1.x, 2.x and any concecutive codebases is collectively called Struts Framework (full name) or just Struts (short name). * Struts 1.x codebase is collectively called Struts 1.x where 1.x designates version range. * Struts 2.x codebase is collectively called Struts 2.x where 2.x designates version range. * Same pattern goes for future codebases. Therefore there are no official Struts 1 or Struts 2 names/products. Few people see what happens in SVN. But documentation is highly visible, and we must choose one approach and follow it strictly. I prefer the first one because it assumes that 1.x codebase is not immediately replaced with 2.x codebase and still can be developed separately (yes, this is marketing stuff). Anyway, I will obey any decision, we just need to make *one*. Have I missed it? After the final naming decision is made, proper names MUST be used in Javadocs, site docs, public emails and in other places. [ Code Names ] Codenames like Classic for 1.x codebase is a separate issue and this too must be finally dicided on. We discussed it many times, but have the official and final decision been made? We need to chose official (while optional) names and use only them or not use any codenames at all. Michael. On 7/2/06, Niall Pemberton [EMAIL PROTECTED] wrote: It might appear redundant but Struts 1 is the name rather than version number and hopefully what people will get used to distinguish between the two flavours on offer. Its no different than what Sun did when they introduced Java 2 and who knows where out version numbers are going to go in the two parts. That in itself is good enouh reason to leave it IMO - but also I'm against overriding the defaults of the build unless absolutely necessary - that way if things change in the future theres less places to remember. If we'd done this in the previous year we would have had to correct it 3 or 4 times! Niall On 7/2/06, Paul Benedict [EMAIL PROTECTED] wrote: Wendy, thanks. I understand the proposal. Version 1 is already in 1.3.5; so it doesn't need to be said everytime; the version number is enough to indicate its version 1. Wendy Smoak [EMAIL PROTECTED] wrote: On 7/2/06, Paul Benedict wrote: Does anyone else find this kind of title redudant? Struts 1 - Core 1.3.5-SNAPSHOT API We can specify it in the pom. I recommend: Struts Core 1.3.5-SNAPSHOT API This change results from Don's proposal thread [1] about renaming Struts Action - Struts, in which I believe the consensus was to go with 'Struts 1' and 'Struts 2'. [1] http://www.nabble.com/-PROPOSAL--Rename-Struts-Action-as-Struts-tf1864462.html -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
I think you are over-thinking this one. Struts is a single product with multiple versions. Since both are still developed, at times, it is helpful to refer to Struts 2.0 as Struts 2 and Struts 1.x as Struts 1, but these names are really optional and a tool to help clarify versions. In the end, we just have Struts. As for this particular API issue, I just threw Struts 1 in there to perhaps make it clearer, but looking at it again, I don't think it did. Struts Core 1.3.5-SNAPSHOT API is much better, in my opinion. Don Michael Jouravlev wrote: I hate to bring this question back, but do we have a final decision on how 1.x and 2.x codebases are treated name-wise and what is the official way to refer to a product/version? Because seems that Don, for example, have a different idea on naming: I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1, etc... The whole point of this proposal is to unify Struts as a single project, getting away from this concept of separately versioned subprojects. There will be Struts 1.x releases, and there will be Struts 2.x releases, and perhaps some day, Struts 3.x releases. I would prefer having Struts 1 and Struts 2 *names* as you stated, but to Don and some others these are just different *versions of one product* , and apparently should be written as Struts 1.x or Struts 2.x [ Approach 1: generations/branches ] * Struts 1.x, 2.x and any consecutive codebases is collectively called Struts Framework (full name) or just Struts (short name). BTW, Have we decided to drop Action or the full official name is Struts Action Framework? * Struts 1.x codebase is collectively called Struts 1 where 1 is part of the name. * Struts 2.x codebase and any concecutive codebases is collectively called Struts 2; 2 is part of the name. [ Approach 2: one unified product] * Struts 1.x, 2.x and any concecutive codebases is collectively called Struts Framework (full name) or just Struts (short name). * Struts 1.x codebase is collectively called Struts 1.x where 1.x designates version range. * Struts 2.x codebase is collectively called Struts 2.x where 2.x designates version range. * Same pattern goes for future codebases. Therefore there are no official Struts 1 or Struts 2 names/products. Few people see what happens in SVN. But documentation is highly visible, and we must choose one approach and follow it strictly. I prefer the first one because it assumes that 1.x codebase is not immediately replaced with 2.x codebase and still can be developed separately (yes, this is marketing stuff). Anyway, I will obey any decision, we just need to make *one*. Have I missed it? After the final naming decision is made, proper names MUST be used in Javadocs, site docs, public emails and in other places. [ Code Names ] Codenames like Classic for 1.x codebase is a separate issue and this too must be finally dicided on. We discussed it many times, but have the official and final decision been made? We need to chose official (while optional) names and use only them or not use any codenames at all. Michael. On 7/2/06, Niall Pemberton [EMAIL PROTECTED] wrote: It might appear redundant but Struts 1 is the name rather than version number and hopefully what people will get used to distinguish between the two flavours on offer. Its no different than what Sun did when they introduced Java 2 and who knows where out version numbers are going to go in the two parts. That in itself is good enouh reason to leave it IMO - but also I'm against overriding the defaults of the build unless absolutely necessary - that way if things change in the future theres less places to remember. If we'd done this in the previous year we would have had to correct it 3 or 4 times! Niall On 7/2/06, Paul Benedict [EMAIL PROTECTED] wrote: Wendy, thanks. I understand the proposal. Version 1 is already in 1.3.5; so it doesn't need to be said everytime; the version number is enough to indicate its version 1. Wendy Smoak [EMAIL PROTECTED] wrote: On 7/2/06, Paul Benedict wrote: Does anyone else find this kind of title redudant? Struts 1 - Core 1.3.5-SNAPSHOT API We can specify it in the pom. I recommend: Struts Core 1.3.5-SNAPSHOT API This change results from Don's proposal thread [1] about renaming Struts Action - Struts, in which I believe the consensus was to go with 'Struts 1' and 'Struts 2'. [1] http://www.nabble.com/-PROPOSAL--Rename-Struts-Action-as-Struts-tf1864462.html -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
I think that there should be ONE strict naming system that every commiter has to obey whether writing a high-profile article or an informan email. Such a system will indeed serve as a tool to help clarify versions. After all, when I say for example Struts 2 I do not want to explain later have I meant only Struts 2.x or Struts 2.x+. Having a system is usually a good thing. On 7/5/06, Don Brown [EMAIL PROTECTED] wrote: I think you are over-thinking this one. Struts is a single product with multiple versions. Since both are still developed, at times, it is helpful to refer to Struts 2.0 as Struts 2 and Struts 1.x as Struts 1, but these names are really optional and a tool to help clarify versions. In the end, we just have Struts. As for this particular API issue, I just threw Struts 1 in there to perhaps make it clearer, but looking at it again, I don't think it did. Struts Core 1.3.5-SNAPSHOT API is much better, in my opinion. Don Michael Jouravlev wrote: I hate to bring this question back, but do we have a final decision on how 1.x and 2.x codebases are treated name-wise and what is the official way to refer to a product/version? Because seems that Don, for example, have a different idea on naming: I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1, etc... The whole point of this proposal is to unify Struts as a single project, getting away from this concept of separately versioned subprojects. There will be Struts 1.x releases, and there will be Struts 2.x releases, and perhaps some day, Struts 3.x releases. I would prefer having Struts 1 and Struts 2 *names* as you stated, but to Don and some others these are just different *versions of one product* , and apparently should be written as Struts 1.x or Struts 2.x [ Approach 1: generations/branches ] * Struts 1.x, 2.x and any consecutive codebases is collectively called Struts Framework (full name) or just Struts (short name). BTW, Have we decided to drop Action or the full official name is Struts Action Framework? * Struts 1.x codebase is collectively called Struts 1 where 1 is part of the name. * Struts 2.x codebase and any concecutive codebases is collectively called Struts 2; 2 is part of the name. [ Approach 2: one unified product] * Struts 1.x, 2.x and any concecutive codebases is collectively called Struts Framework (full name) or just Struts (short name). * Struts 1.x codebase is collectively called Struts 1.x where 1.x designates version range. * Struts 2.x codebase is collectively called Struts 2.x where 2.x designates version range. * Same pattern goes for future codebases. Therefore there are no official Struts 1 or Struts 2 names/products. Few people see what happens in SVN. But documentation is highly visible, and we must choose one approach and follow it strictly. I prefer the first one because it assumes that 1.x codebase is not immediately replaced with 2.x codebase and still can be developed separately (yes, this is marketing stuff). Anyway, I will obey any decision, we just need to make *one*. Have I missed it? After the final naming decision is made, proper names MUST be used in Javadocs, site docs, public emails and in other places. [ Code Names ] Codenames like Classic for 1.x codebase is a separate issue and this too must be finally dicided on. We discussed it many times, but have the official and final decision been made? We need to chose official (while optional) names and use only them or not use any codenames at all. Michael. On 7/2/06, Niall Pemberton [EMAIL PROTECTED] wrote: It might appear redundant but Struts 1 is the name rather than version number and hopefully what people will get used to distinguish between the two flavours on offer. Its no different than what Sun did when they introduced Java 2 and who knows where out version numbers are going to go in the two parts. That in itself is good enouh reason to leave it IMO - but also I'm against overriding the defaults of the build unless absolutely necessary - that way if things change in the future theres less places to remember. If we'd done this in the previous year we would have had to correct it 3 or 4 times! Niall On 7/2/06, Paul Benedict [EMAIL PROTECTED] wrote: Wendy, thanks. I understand the proposal. Version 1 is already in 1.3.5; so it doesn't need to be said everytime; the version number is enough to indicate its version 1. Wendy Smoak [EMAIL PROTECTED] wrote: On 7/2/06, Paul Benedict wrote: Does anyone else find this kind of title redudant? Struts 1 - Core 1.3.5-SNAPSHOT API We can specify it in the pom. I recommend: Struts Core 1.3.5-SNAPSHOT API This change results from Don's proposal thread [1] about renaming Struts Action - Struts, in which I believe the consensus was to go with 'Struts 1' and 'Struts 2'. [1] http://www.nabble.com/-PROPOSAL--Rename-Struts-Action-as-Struts-tf1864462.html -- Wendy
Re: API Doc Title
On 7/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: Having a system is usually a good thing. Perhaps it would help to define these terms, which I think many people use naturally. Struts 2 - The product represented by the repository head. Struts 2.x - The product that the repository head is becoming. Struts 2.0.0 - The version of the product we are working to release now. In general, I feel the documentation should avoid too many direct references to the product name. On the the last pass, I used framework as much as possible and SAF2 on occasion. Now, I would use Struts 2 wherever I was using SAF2 or SAF 2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1
On 7/5/06, Don Brown [EMAIL PROTECTED] wrote: I chose 1.x and 2.0 because I think it fits better with the other archived web sites. The struts1 and struts2 names are more for internal use and in particular, struts1 is only used in svn due to the maven workaround. I think 1.x and 2.0, as well as the past 1.2.9 and so on, is easier for the user to guess and remember. I could see a case for creating such folders to automatically version the websites. Instead of creating 1.3.5 and 2.0.0 folders later to host site archives, as we do now, * http://struts.apache.org/1.2.9/ We could start creating the versioned folders upfront and then redirecting from struts/1.2 to struts/1.2.9, and so forth. If we want to do that, then we should setup physical folders for 1.3.5 and 2.0.0 and setup the appropriate redirects for struts/1.3 and struts/2.0 to the latest versions. Then once each version rolls, we could create the 1.3.6 and 2.0.1 folders and update the redirects. In this way, people could link to Struts/1.3 or Struts/2.0 and be directed to the site for the latest working milestone in the series. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to call java script in jspx ?
It would be better to take this thead to the user list. * http://struts.apache.org/mail.html (Perhaps it is time to setup a OS forum for the Struts user list too.) -Ted. On 7/5/06, ninavagyan [EMAIL PROTECTED] wrote: it is configured, it doesn't help - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=36323messageID=71456#71456 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
So in your terms Struts 2 == SAF2. This does not tell me much ;-) Is it strictly WW2.x or anything starting from WW2.x codebase onwards? I guess the latter considering that Struts 2 is represented by the repository head. See, your definition is not clear enough for an end user while being too technical. Why would end users care about repository naming conventions? They download binaries and they read docs and articles, names should match there. I agree that javadocs should not mention a particular version unless it is important. Javadocs are tied to a particular release anyway. On 7/5/06, Ted Husted [EMAIL PROTECTED] wrote: On 7/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: Having a system is usually a good thing. Perhaps it would help to define these terms, which I think many people use naturally. Struts 2 - The product represented by the repository head. Struts 2.x - The product that the repository head is becoming. Struts 2.0.0 - The version of the product we are working to release now. In general, I feel the documentation should avoid too many direct references to the product name. On the the last pass, I used framework as much as possible and SAF2 on occasion. Now, I would use Struts 2 wherever I was using SAF2 or SAF 2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Website version handling (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)
Well, that raises an interesting problem. When a user goes to the Struts site, they expect to see documentation covering the latest released version, but when developers maintain the site, they are documenting the latest code in development. I like the idea of automatically versioned sites as part of our release process as it makes it easier for the users. Also, this scheme makes it more obvious which version the material covers. I'm especially in favor of it as long as the unreleased versions are cleared marked with a link to the last stable. To be clear, the primary Struts site isn't and shouldn't be versioned. This is the code in struts/site. The versioning discussion is regarding the generated site docs from each Struts version. In summary, I think the solution you propose solves all the issues nicely. Don Ted Husted wrote: On 7/5/06, Don Brown [EMAIL PROTECTED] wrote: I chose 1.x and 2.0 because I think it fits better with the other archived web sites. The struts1 and struts2 names are more for internal use and in particular, struts1 is only used in svn due to the maven workaround. I think 1.x and 2.0, as well as the past 1.2.9 and so on, is easier for the user to guess and remember. I could see a case for creating such folders to automatically version the websites. Instead of creating 1.3.5 and 2.0.0 folders later to host site archives, as we do now, * http://struts.apache.org/1.2.9/ We could start creating the versioned folders upfront and then redirecting from struts/1.2 to struts/1.2.9, and so forth. If we want to do that, then we should setup physical folders for 1.3.5 and 2.0.0 and setup the appropriate redirects for struts/1.3 and struts/2.0 to the latest versions. Then once each version rolls, we could create the 1.3.6 and 2.0.1 folders and update the redirects. In this way, people could link to Struts/1.3 or Struts/2.0 and be directed to the site for the latest working milestone in the series. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
On 7/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: So in your terms Struts 2 == SAF2. This does not tell me much ;-) Is it strictly WW2.x or anything starting from WW2.x codebase onwards? I guess the latter considering that Struts 2 is represented by the repository head. Yes, I think the repository head is as clear as it gets. If the documentation is consistent -- and I intend to do everything I can to assure that it is -- then readers will take our meaning from context. See, your definition is not clear enough for an end user while being too technical. Why would end users care about repository naming conventions? They download binaries and they read docs and articles, names should match there. We are talking about guidelines for people writing documentation. If we define the terms in a way meaningful to ourselves, and use them consistently in context, then the meaning to other readers will take care of itself. I agree that javadocs should not mention a particular version unless it is important. Javadocs are tied to a particular release anyway. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
IMHO Struts means the latest/current developmentin other words...SAF2, struts2, 2.x, I think we should just say Struts, but clarify only if we mean an older version. I mean, we do that now with everything else. If someone has a question about Struts, and it happens to pertain to 1.0 or 1.1, they usually say so. Same goes for other libraries/frameworks. Just my $0.02 -- James Mitchell On Jul 5, 2006, at 3:08 PM, Michael Jouravlev wrote: So in your terms Struts 2 == SAF2. This does not tell me much ;-) Is it strictly WW2.x or anything starting from WW2.x codebase onwards? I guess the latter considering that Struts 2 is represented by the repository head. See, your definition is not clear enough for an end user while being too technical. Why would end users care about repository naming conventions? They download binaries and they read docs and articles, names should match there. I agree that javadocs should not mention a particular version unless it is important. Javadocs are tied to a particular release anyway. On 7/5/06, Ted Husted [EMAIL PROTECTED] wrote: On 7/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: Having a system is usually a good thing. Perhaps it would help to define these terms, which I think many people use naturally. Struts 2 - The product represented by the repository head. Struts 2.x - The product that the repository head is becoming. Struts 2.0.0 - The version of the product we are working to release now. In general, I feel the documentation should avoid too many direct references to the product name. On the the last pass, I used framework as much as possible and SAF2 on occasion. Now, I would use Struts 2 wherever I was using SAF2 or SAF 2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website version handling (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)
On 7/5/06, Don Brown [EMAIL PROTECTED] wrote: Well, that raises an interesting problem. When a user goes to the Struts site, they expect to see documentation covering the latest released version, but when developers maintain the site, they are documenting the latest code in development. Yes, we expect to see both the latest documentation and the documentation for the release we are using in production. Right now, I can go to MySQL and surfe the documentation for the development version 5.1, 5.0 , 4.1, 4.0, and 3.0. I like the idea of automatically versioned sites as part of our release process as it makes it easier for the users. Also, this scheme makes it more obvious which version the material covers. I'm especially in favor of it as long as the unreleased versions are cleared marked with a link to the last stable. Yes, if we create the 1.3.5 folder before we release 1.3.5, then we can link to that exact location as appropriate, and to 1.3 when appropriate. But if we want a latest link, then we would also need a 1.x and 2.x link. Right now these woud equate to 1.3 and 2.0, but later they may equate to 1.4 and 2.1 To be clear, the primary Struts site isn't and shouldn't be versioned. This is the code in struts/site. The versioning discussion is regarding the generated site docs from each Struts version. Yes, not versioned in the sense that we are putting the website under version control, but we do want site archives available for every version, whether it is 1.x, 2.x, or 9.x.. In summary, I think the solution you propose solves all the issues nicely. One issue to consider is what do we do if a version does not go GA. If we had been doing this all along, then we would have created a website folder for 1.3.1. Would we have kept 1.3.1 around once we decided it was a permanent Alpha, or do we delete folders for versions that we know are not going GA. If we are careful to constrain the references to a specific version of the website, it would be possible to remove beta release sites, so that we only retain the GA sites over time. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
That assumes all the development and support effort go towards one framework, Struts 2. If we're still actively supporting and developing the Struts 1.x line, then references to Struts should include a qualification of which Struts framework is meant. Hubert On 7/5/06, James Mitchell [EMAIL PROTECTED] wrote: IMHO Struts means the latest/current developmentin other words...SAF2, struts2, 2.x, I think we should just say Struts, but clarify only if we mean an older version. I mean, we do that now with everything else. If someone has a question about Struts, and it happens to pertain to 1.0 or 1.1, they usually say so. Same goes for other libraries/frameworks. Just my $0.02 -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2 Archetype
On 7/2/06, Wendy Smoak [EMAIL PROTECTED] wrote: Does the JasperReports dependency [2] need to be commented out by default? I thought it was under a non-ASL-compatible license, and couldn't be included in any 'default' build. I'm not exactly sure how that applies to an archetype, but wanted to bring it up for discussion. Yes, it must be commented out. The end-user has to decide to use JasperReports along with its license. The comment could also say that JasperReports is available under the GPL, LGPL, and commercial licenses and link to their licensing page [http://www.jaspersoft.com/pr_licensing.html]. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2 Archetype
Yes, I think we should avoid confusion with QuickStart. I haven't looked at all of these closely yet. Can we go back to calling it blank, or is there already another by that name? -Ted. On 7/2/06, Wendy Smoak [EMAIL PROTECTED] wrote: Another thought on the Struts 2 archetype: Is there going to be any confusion with Quickstart vs. struts2-archetype-quickstart? Should we rename it struts2-archetype-starter (or something else)? Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
I respectfully disagree. I think having to clarify Struts as 1 or 2 is just as bad as having to say Struts Action 1 vs. Struts Action 2 vs. Shale. Believe me, I'm not trying to discount the 1.x development. I have stated as much on several threads. Also, I have many 1.x apps to support, and I think my recent work on getting the 1.2.x and 1.3.x nightlies back online proves my commitment to both of those lines. I will be doing more as time allows. I just think we should all just get used to a default when we say Struts. And if we mean an different/older version, then can say so. Your thoughts? -- James Mitchell On Jul 5, 2006, at 3:33 PM, Hubert Rabago wrote: That assumes all the development and support effort go towards one framework, Struts 2. If we're still actively supporting and developing the Struts 1.x line, then references to Struts should include a qualification of which Struts framework is meant. Hubert On 7/5/06, James Mitchell [EMAIL PROTECTED] wrote: IMHO Struts means the latest/current developmentin other words...SAF2, struts2, 2.x, I think we should just say Struts, but clarify only if we mean an older version. I mean, we do that now with everything else. If someone has a question about Struts, and it happens to pertain to 1.0 or 1.1, they usually say so. Same goes for other libraries/ frameworks. Just my $0.02 -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
On 7/5/06, James Mitchell [EMAIL PROTECTED] wrote: Your thoughts? I think we are dangerously closed to discussion what is is :) So, lets have that discussion and get it over with. First, in practice, the committers uniformly cite what version we are talking about. I don't think we have a problem with talking amongst ourselves. :) Other people are going to refer to Struts the same way we refer to MySQL or ASP.NET. Right now, today, when a random person says they are using Struts, they undoubtedly mean some version of Struts. It might mean Struts 1.1 (and probably does), or it could mean Struts 1.2. In rare cases, it could even mean Struts 1.3. If someone on the user list says they are using Struts, dollars to dougnuts, they mean some release of Struts 1.x. In a year or two that will change, and a bald reference to Struts is likely to mean Struts 2.x. That's a normal evolution that happens over time with any product. Just like when I say I use ASP.NET, I could mean 1.0, or 1.1, or even 2.0. When I say I use MySQL, I could mean anything from 3.0 to 4.0 to 4.1 to 5.0 to 5.1. If I have a technical question, the version could be important. But often it is not. To sum up the other thread, most people seemed to agree that we wanted to just call the product Struts, and that we didn't want to use codenames (like Tiger or Vista). No matter what we say, in practice, reference to Struts or Struts 1 or Struts 2 are going to be no different in meaning than references to MySQL 4 or MySQL 5. (Nor do most of us want them to be.) :) Since Don changed the setting of the API title, can we let all this drop now? :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
On 7/5/06, James Mitchell [EMAIL PROTECTED] wrote: Believe me, I'm not trying to discount the 1.x development. I have stated as much on several threads. Also, I have many 1.x apps to support, and I think my recent work on getting the 1.2.x and 1.3.x nightlies back online proves my commitment to both of those lines. I will be doing more as time allows. Oops, apologies. I'm aware of your stand on this and didn't intend to imply you meant otherwise. The last thing I want to do is discount anyone's contributions. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website version handling (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)
See * http://issues.apache.org/struts/browse/SITE-8 -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help in switching from http to https in struts
This is question for the user list, but I can mention that switching between http and https is not fun to do in Struts 1, but the SSL Ext taglib may help. * http://sslext.sourceforge.net/ -Ted. On 6/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi , Iam developing application in struts which has login page and when username and password are given it should be authenticated and the page should be switched to https I had made necessary changes to include transport-guarantee and login-config to include the user properties but the form-login-config form-login-page/display.jsp/form-login-page form-error-page/error.jsp/form-error-page /form-login-config /login-config is forcing it to go to the pages which i give in form-login-page instead it should go to NameAction java file which extends Action and based on the logic there i should go to the required success or error page and iam not understanding the importance of form-login-config like if i remove the lines form-login-config form-login-page/display.jsp/form-login-page form-error-page/error.jsp/form-error-page /form-login-config /login-config i get the exceptions 18:59:15,687 WARN [FormAuthenticator] Unexpected error forwarding to login page java.lang.NullPointerException at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAut hen ticator.java:238) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticator Bas e.java:446) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.j ava :59) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :12 6) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :10 5) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. jav a:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1 48) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:85 6) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC onn ection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint .ja va:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorker Thr ead.java:112) at java.lang.Thread.run(Thread.java:595) Could you please help me resolve this Note: The switching to https is happening the only thing is iam not getting the required result Regards Bhanu Thanks and Regards Bhanuprakash Singh Wipro Technologies Bangalore Contact#: ESN-6-877-5107 PBX: 28520408-Ext.83244 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
On 7/5/06, Ted Husted [EMAIL PROTECTED] wrote: On 7/5/06, James Mitchell [EMAIL PROTECTED] wrote: Your thoughts? I think we are dangerously closed to discussion what is is :) So, lets have that discussion and get it over with. skipped Other people are going to refer to Struts the same way we refer to MySQL or ASP.NET. skipped Just like when I say I use ASP.NET, I could mean 1.0, or 1.1, or even 2.0. When I say I use MySQL, I could mean anything from 3.0 to 4.0 to 4.1 to 5.0 to 5.1. If I have a technical question, the version could be important. But often it is not. I think that no one disagrees that Struts is a collective name for all Struts versions. Apparently no one disagrees that default Struts version will change in time, moving from 1.x codebase to 2.x codebase, like it happened with Windows for example. The disagreement and confusion is having and publicly using 1 and 2 labels. Do we use them internally? Do we use them publicly? What do these labels mean? Do they identify generations like Java and Java2 or Win9x and WinNT, or do they identify major version number? That was the reason why I resurrected this thread. Please allow me to quote myself (with modifications): === cut here === [ Approach 1: generations/branches ] * Struts 1.x, 2.x and any consecutive codebases is collectively called Struts Framework (full name) or just Struts (short name). * Struts 1.x codebase is collectively called Struts 1 where 1 is part of the name. * Struts 2.x codebase and any consecutive codebases is collectively called Struts 2 where 2 is part of the name. [ Approach 2: continuous version numbering of one unified product] * Struts 1.x, 2.x and any concecutive codebases is collectively called Struts Framework (full name) or just Struts (short name). * Struts 1.x or Struts 2.x or Struts x.y identifies a version number or version range of Struts Framework as one product; x.y can be any valid version number. Therefore: ** Struts 1.x codebase is collectively called Struts 1.x where 1.x means original Struts Framework. * Struts 2.x codebase is collectively called Struts 2.x where 2.x means version range for code brought by WW and any future development. * There are NO official Struts 1 or Struts 2 names/products. === cut here === I see that most committers lean to the second option. If yes, then let us choose it and stick with it, even in informal mailing list correspondence. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shale SVN moved
So people know, I just did: svn move -m Moving Shale to TLP https://svn.apache.org/repos/asf/struts/shale https://svn .apache.org/repos/asf/shale Committed revision 419348. You'll need to use svn switch to change your svn checkout to the new location. ( svn switch https://svn.apache.org/repos/asf/shale ) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
On 7/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: The disagreement and confusion is having and publicly using 1 and 2 labels. Do we use them internally? Do we use them publicly? Everything we do is public. There aren't any secret internal-use labels. What do these labels mean? Do they identify generations like Java and Java2 or Win9x and WinNT, or do they identify major version number? In the case of Apache Struts, the notion of a generation and major version are the same. So long as we can keep one release backwardly-compatible with another, we have always chosen to increment the minor version number, even if the feature set has been significantly expanded. We have said for years that the only reason we would increment the major version number was because the new version was *not* 100% backwardly compatible with the existing version. Other people might call that a generation. We call it a revolution. The numerals are *not* labels. The numerals 1 and 2 indicate the major release series. Depending on what happens with phase 2, that could become Struts 3 or it might just be Struts 2.1. The litmus test for us has always been backward-compatibility. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Doc Title
On 7/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: The disagreement and confusion is having and publicly using 1 and 2 labels. Do we use them internally? Do we use them publicly? What do these labels mean? Do they identify generations like Java and Java2 or Win9x and WinNT, or do they identify major version number? That was the reason why I resurrected this thread. Please allow me to quote myself (with modifications): I don't see much difference in the two approaches. If it has anything to do with marketing then I object on general principles. ;) It's just Struts. Depending on the context, use a version number if it makes things more clear. Or not, if it doesn't. Expect to find (and fix!) inconsistencies all over the documentation-- it's been rearranged and renamed multiple times in the past year. Here's hoping this is the last time... -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1
A thought occured to me today. If we ever want to share code between struts 1 and struts 2c (ie: locale resolution), having the org.apache.struts package structure being the neutral place makes sense, with action (1.x) and action2 (2.x) being specific implementations. Well, not that the renaming is done, I think we have no normal way of sharing code across packages. Thoughts? -- Paul Ted Husted [EMAIL PROTECTED] wrote: On 7/1/06, Don Brown (JIRA) wrote: Rename Struts Action 1 to Struts 1 If we are using struts1 and struts2 for the repository folders (which is fine with me), why are we using 1.x and 2.0 for the website folders? * http://struts.apache.org/1.x/ * http://struts.apache.org/2.0/ In the view of convention over configuration, I feel we we should work toward using a consistent set of conventions across tools. If there is not a technical reason why we need to use symbols, I'd like to use struts1 and struts2 for the website folders. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Want to be your own boss? Learn how on Yahoo! Small Business.
Re: API Doc Title
I do not think Struts connotates 1.x, or 2.x, or the current production release, or whatever. It's just a title for our line of products. If you need to talk about a version, just say so. I am content and agree with James. James Mitchell [EMAIL PROTECTED] wrote: I respectfully disagree. I think having to clarify Struts as 1 or 2 is just as bad as having to say Struts Action 1 vs. Struts Action 2 vs. Shale. Believe me, I'm not trying to discount the 1.x development. I have stated as much on several threads. Also, I have many 1.x apps to support, and I think my recent work on getting the 1.2.x and 1.3.x nightlies back online proves my commitment to both of those lines. I will be doing more as time allows. I just think we should all just get used to a default when we say Struts. And if we mean an different/older version, then can say so. Your thoughts? -- James Mitchell On Jul 5, 2006, at 3:33 PM, Hubert Rabago wrote: That assumes all the development and support effort go towards one framework, Struts 2. If we're still actively supporting and developing the Struts 1.x line, then references to Struts should include a qualification of which Struts framework is meant. Hubert On 7/5/06, James Mitchell wrote: IMHO Struts means the latest/current developmentin other words...SAF2, struts2, 2.x, I think we should just say Struts, but clarify only if we mean an older version. I mean, we do that now with everything else. If someone has a question about Struts, and it happens to pertain to 1.0 or 1.1, they usually say so. Same goes for other libraries/ frameworks. Just my $0.02 -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
Re: API Doc Title
Everything we do is public. There aren't any secret internal use labels. Ted, then you are obviously not in on the secret. :) Ted Husted [EMAIL PROTECTED] wrote: On 7/5/06, Michael Jouravlev wrote: The disagreement and confusion is having and publicly using 1 and 2 labels. Do we use them internally? Do we use them publicly? Everything we do is public. There aren't any secret internal-use labels. What do these labels mean? Do they identify generations like Java and Java2 or Win9x and WinNT, or do they identify major version number? In the case of Apache Struts, the notion of a generation and major version are the same. So long as we can keep one release backwardly-compatible with another, we have always chosen to increment the minor version number, even if the feature set has been significantly expanded. We have said for years that the only reason we would increment the major version number was because the new version was *not* 100% backwardly compatible with the existing version. Other people might call that a generation. We call it a revolution. The numerals are *not* labels. The numerals 1 and 2 indicate the major release series. Depending on what happens with phase 2, that could become Struts 3 or it might just be Struts 2.1. The litmus test for us has always been backward-compatibility. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
Sharing code between versions (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)
Good question. Here are the options of the top of my head: - Jakarta Commons project - Put it in Struts 1.x, since Struts 2 will probably have 1 has a dep for migration code - Create new Struts Commons - Just have two copies of the code To be honest, I lean towards the last option, unless the code is large enough to warrant the first. For example, Struts 1 has WildcardHelper, but so does XWork 2.0 (used by Struts 2) and it all came from Cocoon. Cocoon recently rewrote the class, so I'll need to bring over the changes into those two new projects. Sure, that is a bit of work, but not in comparison to starting a new project just for that class. Don Paul Benedict wrote: A thought occured to me today. If we ever want to share code between struts 1 and struts 2c (ie: locale resolution), having the org.apache.struts package structure being the neutral place makes sense, with action (1.x) and action2 (2.x) being specific implementations. Well, not that the renaming is done, I think we have no normal way of sharing code across packages. Thoughts? -- Paul Ted Husted [EMAIL PROTECTED] wrote: On 7/1/06, Don Brown (JIRA) wrote: Rename Struts Action 1 to Struts 1 If we are using struts1 and struts2 for the repository folders (which is fine with me), why are we using 1.x and 2.0 for the website folders? * http://struts.apache.org/1.x/ * http://struts.apache.org/2.0/ In the view of convention over configuration, I feel we we should work toward using a consistent set of conventions across tools. If there is not a technical reason why we need to use symbols, I'd like to use struts1 and struts2 for the website folders. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Want to be your own boss? Learn how on Yahoo! Small Business. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sharing code between versions (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)
On 7/5/06, Don Brown [EMAIL PROTECTED] wrote: Good question. Here are the options of the top of my head: - Jakarta Commons project - Put it in Struts 1.x, since Struts 2 will probably have 1 has a dep for migration code - Create new Struts Commons - Just have two copies of the code FWIW, the MyFaces folks have gone through the same sort of discussion recently, trying to decide whether/how to share code between the JSF implementation and the component classes. The hardest part of the whole thing is actually synchronizing releases of the helper classes, since both framework versions would have dependencies on the common stuff. They ended up with a variation of the third approach -- a shared module in the MyFaces repository that both things could depend on. Craig To be honest, I lean towards the last option, unless the code is large enough to warrant the first. For example, Struts 1 has WildcardHelper, but so does XWork 2.0 (used by Struts 2) and it all came from Cocoon. Cocoon recently rewrote the class, so I'll need to bring over the changes into those two new projects. Sure, that is a bit of work, but not in comparison to starting a new project just for that class. Don Paul Benedict wrote: A thought occured to me today. If we ever want to share code between struts 1 and struts 2c (ie: locale resolution), having the org.apache.struts package structure being the neutral place makes sense, with action (1.x) and action2 (2.x) being specific implementations. Well, not that the renaming is done, I think we have no normal way of sharing code across packages. Thoughts? -- Paul Ted Husted [EMAIL PROTECTED] wrote: On 7/1/06, Don Brown (JIRA) wrote: Rename Struts Action 1 to Struts 1 If we are using struts1 and struts2 for the repository folders (which is fine with me), why are we using 1.x and 2.0 for the website folders? * http://struts.apache.org/1.x/ * http://struts.apache.org/2.0/ In the view of convention over configuration, I feel we we should work toward using a consistent set of conventions across tools. If there is not a technical reason why we need to use symbols, I'd like to use struts1 and struts2 for the website folders. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Want to be your own boss? Learn how on Yahoo! Small Business. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2 Archetype
On 7/5/06, Ted Husted [EMAIL PROTECTED] wrote: Yes, I think we should avoid confusion with QuickStart. I haven't looked at all of these closely yet. Can we go back to calling it blank, or is there already another by that name? Toby, is the archetype patterned more after the struts2-blank or struts2-starter app? Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.3.5 distribution snapshots updated
On Jul 5, 2006, at 2:33 AM, Wendy Smoak wrote: Ted is threatening to roll 1.3.5 any day now, so here are updated snapshots of the assemblies: http://people.apache.org/builds/struts/1.3.x/assembly/ Looks great Wendy! I took a quick look around, and noticed that both the myfaces-api and portlet-api jars are included.They can be marked 'provided' in the assembly pom to keep them out for now, longer term we need to find out where they're coming from and fix it there. Yes, and I wish there was a decent tool for POM management so that finding these issues (and others) would be easier. And they might also be included in the .war files; that needs to be checked. (My bet is that one of the recently upgraded dependencies hasn't properly marked these 'provided' or 'optional' in its pom.) The struts-master v3 pom is available in the snapshot repo, so as long as it looks good, the parent tag in struts1/pom.xml can be changed: 3-SNAPSHOT - 3. Things may have changed a little since the instructions were written, so if something on the StrutsMaintenanceMaven or StrutsMavenRelease wiki pages doesn't make sense, just ask. Thanks, -- Wendy Thanks again Wendy -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2 Archetype
I think it would be more towards starter, i guess. It is runnable and have a simple action in it with validation and conversion as well. rgds. - Original Message From: Wendy Smoak [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Cc: [EMAIL PROTECTED] Sent: Thursday, 6 July, 2006 10:53:55 AM Subject: Re: [s2] Struts 2 Archetype On 7/5/06, Ted Husted [EMAIL PROTECTED] wrote: Yes, I think we should avoid confusion with QuickStart. I haven't looked at all of these closely yet. Can we go back to calling it blank, or is there already another by that name? Toby, is the archetype patterned more after the struts2-blank or struts2-starter app? Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
