[Apache Struts Wiki] Updated: StrutsWebLinks
Date: 2004-10-14T01:17:49 Editor: RoryWinston [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsWebLinks URL: http://wiki.apache.org/struts/StrutsWebLinks no comment Change Log: -- @@ -48,6 +48,14 @@ * http://www.national-lottery.co.uk (UK national lottery) * https://www.foodcourtlive.com (an online foodcourt specifically designed for people working in Raritan center NJ) * http://demo.raibledesigns.com/struts-resume (an online resume building/viewing system) + * http://www.merchantspace.com MerchantSpace Commerce - Service-oriented e-Commerce software utilizing Struts, Velocity, Hibernate + * http://www.esagegroup.com - eSage Group A consulting company, most of our projects are built on Tomcat. + * http://www.ebia.com - Employee Benefits Institute of America provided COBRA and 401K Law Reviews + * http://www.agileedge.com Agility Bug Tracker + * http://telemetry.logica.co.uk Master Control - telemetry on the web, produced by LogicaCMG built on Tomcat. + * http://openmozart.net + * http://www.hotels.com - Several parts of hotels.com use Struts. + === Other Applications Using Struts === * IBM WebSphere 5.x Admin Console (Built on Struts) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: PoweredBy
Date: 2004-10-14T01:18:55 Editor: RoryWinston [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: PoweredBy URL: http://wiki.apache.org/struts/PoweredBy no comment Change Log: -- @@ -1,8 +1 @@ -Here is a list of sites that are currently powered by Struts: - * [http://www.merchantspace.com MerchantSpace Commerce - Service-oriented e-Commerce software utilizing Struts, Velocity, Hibernate.] - * [http://www.esagegroup.com eSage Group] A consulting company, most of our projects are built on Tomcat. - * [http://www.ebia.com Employee Benefits Institute of America provided COBRA and 401K Law Reviews] - * [http://www.agileedge.com Agility Bug Tracker] - * [http://telemetry.logica.co.uk] Master Control - telemetry on the web, produced by LogicaCMG built on Tomcat. - * [http://openmozart.net] - * [http://www.hotels.com] - Several parts of hotels.com use Struts. +See here for a list of sites that use Struts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: PoweredBy
Date: 2004-10-14T01:19:37 Editor: RoryWinston [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: PoweredBy URL: http://wiki.apache.org/struts/PoweredBy no comment Change Log: -- @@ -1 +1 @@ -See here for a list of sites that use Struts +See ,[[http://wiki.apache.org/struts/StrutsWebLinks here]] for a list of sites that use Struts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: PoweredBy
Date: 2004-10-14T01:19:45 Editor: RoryWinston [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: PoweredBy URL: http://wiki.apache.org/struts/PoweredBy no comment Change Log: -- @@ -1 +1 @@ -See ,[[http://wiki.apache.org/struts/StrutsWebLinks here]] for a list of sites that use Struts +See [[http://wiki.apache.org/struts/StrutsWebLinks here]] for a list of sites that use Struts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: PoweredBy
Date: 2004-10-14T01:19:56 Editor: RoryWinston [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: PoweredBy URL: http://wiki.apache.org/struts/PoweredBy no comment Change Log: -- @@ -1 +1 @@ -See [[http://wiki.apache.org/struts/StrutsWebLinks here]] for a list of sites that use Struts +See [http://wiki.apache.org/struts/StrutsWebLinks here] for a list of sites that use Struts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsWebLinks
Date: 2004-10-14T01:25:07 Editor: RoryWinston [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsWebLinks URL: http://wiki.apache.org/struts/StrutsWebLinks no comment Change Log: -- @@ -51,11 +51,12 @@ * http://www.merchantspace.com MerchantSpace Commerce - Service-oriented e-Commerce software utilizing Struts, Velocity, Hibernate * http://www.esagegroup.com - eSage Group A consulting company, most of our projects are built on Tomcat. * http://www.ebia.com - Employee Benefits Institute of America provided COBRA and 401K Law Reviews - * http://www.agileedge.com Agility Bug Tracker - * http://telemetry.logica.co.uk Master Control - telemetry on the web, produced by LogicaCMG built on Tomcat. + * http://www.agileedge.com - Agility Bug Tracker + * http://telemetry.logica.co.uk - Master Control - telemetry on the web, produced by LogicaCMG built on Tomcat. * http://openmozart.net - * http://www.hotels.com - Several parts of hotels.com use Struts. - + * http://www.hotels.com - Several parts of hotels.com use Struts + * http://bugs.sun.com/bugdatabase - Sun's bug tracker for Java + * http://www.vodafone.co.uk/livestudio - Vodafone's multimedia site for MMS devices === Other Applications Using Struts === * IBM WebSphere 5.x Admin Console (Built on Struts) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS - SVN
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon
Yes, I'll be there. On Wed, 13 Oct 2004 13:20:56 -0700, Don Brown wrote: Any Struts committers planning on attending ApacheCon? If so, how about the Hackathon? I'll be there and am anxious to have lively discussions over these roadmap ideas being brought up. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS - SVN / Roadmap
+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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion Refactoring Frenzy and Maven Questions
On Wed, 2004-10-13 at 23:18, Martin Cooper wrote: On Wed, 13 Oct 2004 06:26:00 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 12 Oct 2004 15:22:38 -0700, Martin Cooper wrote: That said, I would really like to see us all stick together for as long as possible, and not diverge into 1.x and 2.x paths too soon, simply because I don't think there is enough energy here to sustain two parallel version of Struts. Apache teams have had that discussion before. In practice, parallel development creates more energy. People don't work on open source just because it is there. They do it because they have an itch to scratch. People are running out of 1.x itches. A 2.x codebase is not going to steal hours from 1.x. The hours people would put into 2.x are not being put into 1.x now. I think this depends on how we're defining 1.x. If 1.x is simply a maintenance branch, then I agree that there's not going to be a lot of energy put into it. However, if 1.3.x is where we move to Servlets 2.3, push struts-chain into the mainstream, factor out file uploads, separate Tiles, and those kinds of things, while 2.x is the purview of those fortunate enough to be able to use Servlets 2.4 containers, then I really do think that we'll split the community unless we do the bulk of these things before we split off the 2.0 version. Personally, I think 1.3.x should include everything you listed above. I think 2.x should be a strong move to (1) Java 5.0, (2) J2EE = 1.4 In my opinion 2.x should be designed around new capabilities, and design trends. 2.x should make Struts - leading the way again. Most of what I've heard so far on this list and in the (280+ open issues, which are mostly enhancement requests) are changes that fit the 1.3.x mold. Flow control can stay the same, while we adopt chain as the primary request processor, without breaking backwards compatibility so I think that is a 1.3.x feature. Same goes for the other things that were mentioned. Perhaps to signify it is a significant change but still same design, it can be versioned 1.5.x (nicknamed 5.0 to spoof Sun :-) As for the SVN trunks and branches: - leave 1.3.x at the trunk. focus efforts there, while discussing, white boarding, and planning 2.x. (Like I said, most of what I've heard/read so far is 1.3.x) - when planning is complete and code is starting to be contributed create a 2.x branch. - when the branch starts to stabilize (which may take some time ;-) and focus starts to shift to 2.x development, make 2.x the trunk and the 1.x (trunk) to a branch. The head/trunk should be primary development. branches should be used for two things - radical changes that should be done in parallel as not to conflict with primary development, and for maintenance versions and back porting Subversion makes moving between trunk and head, copies, etc. cheap and painless. The trunk is really another branch, which is really just a tag, which is really just a build number alias. Creating copies/branches/tags - are essentially just creating an alias to single build. Since builds are atomic, a build is the entire snapshot. Which is one of the many reasons subversion rules. Every commit is essentially a tag and branch. Because of this you also get the great gift of true history - no matter how you refactor, move, or copy files or folders around, you always have version history going back to were it originated. (and since it is all done with pointers and meta data, folders are files are props). Welcome to Subversion! I don't think a 2.x branch should be created until there is some more planning. We need consensus on 1.x future and 2.x goals. There is still a lot of room for 1.x revolution. It is a good design, and with minor changes can become even more flexible and powerful. scratching a lot of itches. I don't think it should be labeled maintenance. 1.2.x is maintenance. There is a lot you can do with the current framework to (1) excite developers, (2) improve productivity and efficiency of struts application development, (3) increase flexibility and plug-ability through refactoring - chain is a great example of this. next stop forms improvements, (4) prepare for 2.x, and last but definitely not least (5) have fun developing it. In my opinion, were 2.x should be radically different is in the areas of: - configuration - wiring of components - container agnostic (servlet, standalone application, junit test, whatever) - use of latest greatest specs and tech (5.0 features including variable args, meta data/attributes, and typed enums) One thing I haven't mentioned yet, was momentum and timing. I don't think it is the right time or the right momentum to start 2.x coding. There is more MVC framework competition in the industry than any other year. Developers have a hard time keeping up with the new changes. A market place like this creates 2 things - buzz and demand for new techniques, and
Re: CVS - SVN
On Thu, 14 Oct 2004 06:57:14 -0400, Ted Husted [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31351] - JSF 1.1_01 and Struts-faces Problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31351 JSF 1.1_01 and Struts-faces Problem --- Additional Comments From [EMAIL PROTECTED] 2004-10-14 13:49 --- It seem to be the same bug as TR 30696, and a potential fix to this blank page problem as part of TR 30696 was reported by Piero collagrosso. I tested this fix, it work perfect. If your project use Tiles, please see the comments to that TR on how to obtain and test the candidate fix to the 'blank page' problem. If you don't use Tiles in your project, juste replace in FaceRequestProcessor the call to context.responseComplete() by context.release(). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31351] - JSF 1.1_01 and Struts-faces Problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31351 JSF 1.1_01 and Struts-faces Problem --- Additional Comments From [EMAIL PROTECTED] 2004-10-14 13:56 --- Hi Craig, Do you plane to include this fix in your next release of Struts-faces ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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: [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]
struts-faces maven build
Hi,
In the spirit of converting struts to maven as well as my desire to begin using
(or testing, or whatever point it's at) struts-faces. I've created the
necessary maven files to
1) create struts-faces.jar
2) create example1-webapp.war
One issue is that no jsf artifacts exist on ibiblio. I hope to get myfaces up
there eventually, but in the meantime they'll have to be downloaded manually.
See the end of this message if you need to know how to do this. The other
issue I'm running into concerns the war file. I can't seem to find the file
struts-faces.tld anywhere. I do see it in the struts-faces.jar nightly build.
Is this file somehow not in svn, or am I blind?
Anyone interested in this patch (Craig, I'm trying to win you over to Maven) can
find it here:
http://www.benanderson.us/bd/maven.txt
I plan to continue work on this until it's obvious that Maven will simplify
things, so this should only be considered an intermediary patch.
I realize Maven is a lot more than what some people want, but I've found the
beauty in it's simple build mechanism. Craig, you mentioned that Maven
creates only a single artifact. While this is true, you're directory structure
can dictate subprojects (each creating it's own artifact). struts-faces is
already lined out nicely to do this. For instance, the core-libary directory
produces struts-faces.jar. The example1-webapp produces example1-webapp.war.
Does this pertain to your single artifact concerns, or is there some other
artifact I'm missing?
Sorry for the rambling. Craig, I think struts-faces is pretty awesome and
appreciate the work you've done across the board ;-)
-Ben
To set jars that aren't in ibiblio's repository in maven's classpath:
I decided to stick with the jsfri, so in order for the following to make sense
in maven...
dependency
groupIdsun/groupId
artifactIdjsf-api/artifactId
version1.0/version
properties
war.bundletrue/war.bundle
/properties
/dependency
dependency
groupIdsun/groupId
artifactIdjsf-impl/artifactId
version1.0/version
properties
war.bundletrue/war.bundle
/properties
/dependency
you must create the following directory structure in your local maven repository
${LOCAL_MAVEN_REPOS} -- this is not a formal name
--sun
jars
--jsf-api-1.0.jar -- I realize this is actually 1.0.1. I just picked
--jsf-impl-1.0.jar -- a number to satisfy Maven's desire for a version #.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS - SVN / Roadmap
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 [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: CVS - SVN / Roadmap
On Thu, 14 Oct 2004 12:50:49 -0400, James Mitchell [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: CVS - SVN / Roadmap
On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon
The hackathon is typically a conference room at the hotel where ApacheCon will be held, and offers an opportunity for committers on the various Apache projects to get together and hack on code face to face, or otherwise get to know each other better. Historically it's been held on the Saturday and Sunday before the conference (which starts on a Monday). Craig On Wed, 13 Oct 2004 21:08:40 -0700, Martin Cooper [EMAIL PROTECTED] wrote: I'm hoping to be at ApacheCon for the first time this year, and still trying to figure out what the Hackathon is all about. ;-) -- Martin Cooper On Wed, 13 Oct 2004 13:20:56 -0700, Don Brown [EMAIL PROTECTED] wrote: Any Struts committers planning on attending ApacheCon? If so, how about the Hackathon? I'll be there and am anxious to have lively discussions over these roadmap ideas being brought up. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31351] - JSF 1.1_01 and Struts-faces Problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31351 JSF 1.1_01 and Struts-faces Problem --- Additional Comments From [EMAIL PROTECTED] 2004-10-14 18:28 --- As a progress note, I plan on evaluating and testing this proposed fix over the next few days (as I've finally been able to allocate some time to work on it). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS - SVN / Roadmap
Are we not waiting for Ted's update? I haven't seen any commits come across and I assumed he would do it this weekendis this still true Ted? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands,
Re: CVS - SVN / Roadmap
On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell [EMAIL PROTECTED] 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 weekendis 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 [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: CVS - SVN / Roadmap
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 [EMAIL PROTECTED] 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 weekendis 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 [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: CVS - SVN / Roadmap
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 weekendis 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 [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
[Apache Struts Wiki] Updated: StrutsReleasePlans
Date: 2004-10-14T13:37:12 Editor: JamesMitchell [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsReleasePlans URL: http://wiki.apache.org/struts/StrutsReleasePlans Preliminary release checklist Change Log: -- @@ -12,3 +12,4 @@ * StrutsRelease122 * StrutsRelease123 * StrutsRelease124 + * StrutsRelease125 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] New: StrutsRelease125
Date: 2004-10-14T13:37:33 Editor: JamesMitchell [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsRelease125 URL: http://wiki.apache.org/struts/StrutsRelease125 Initial checklist New Page: = Struts 1.2.5 Release = == Info == 1. See Struts [http://struts.apache.org/releases.html#Releases Release Guidelines] 1. See Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] 1. See Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] for cutting a release == Release Manager == The release manager is '''James Mitchell''' == Issues == == Outstanding Bug Review == || '''ID''' || '''Summary''' || '''Component''' || '''Prevents Release''' || == Preparation Checklist == See on the Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] || '''#''' || '''Description''' || '''Completed''' || || 1. || Review/Resolve Outstanding Bugs || _ || || 2. || Update Release Notes || _ || || 3. || Check Dependencies || _ || || 4. || Update to version 1.2.5 build.xml, project.xml, and the MANIFEST.MF || _ || Dependency versions for this release: || '''Dependency''' || '''Version''' || '''Status''' || || Commons BeanUtils || 1.6.1 || Released || || Commons Collections || 2.1.1 || Released || || Commons Digester || 1.5 || Released || || Commons FileUpload || 1.0 || Released || || Commons Lang (this should be removed) || 2.0 || Released || || Commons Logging || 1.0.4 || Released || || Commons Validator || 1.1.3 || Released || == Testing Checklist == === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || _ || || 2. || Run Cactus Tests (see below) || _ || || 3. || Play test bundled applications (latest GA release of Tomcat) || _ || === Cactus Tests === || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Completed''' || || 2. || J2SE 1.3.1_13 || Tomcat 4.1.30 || _ || || 3. || J2SE 1.3.1_13 || Tomcat 5.0.28 || _ || || 5. || J2SE 1.4.2_04 || Tomcat 4.1.30 || _ || || 6. || J2SE 1.4.2_04 || Tomcat 5.0.28 || _ || == Point Release Checklist (A) == See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || || A1. || Tag release in cvs: STRUTS_1_2_4 || _ || || A2. || Run Distribution Target || _ || || A3. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/v1.2.5 || _ || || A4. || Deploy JAR to Apache Java-Repository || _ || || A5. || Update Acquiring page on website || _ || || A6. || Post release-quality vote on dev@ list || _ || == Vote == == General Availability Checklist (B) == || '''#''' || '''Description''' || '''Completed''' || || B1. || Create Sums and Sign Distributions || _ || || B2. || Copy Distribution to Mirrored Directories || _ || || B3. || Update Acquiring page on website and Test Downloads || _ || || B4. || Post an announcement to lists and website || _ || || B5. || Request new Bugzilla version level (1.2.5) || _ || CategoryHomepage StrutsReleasePlans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsRelease125
Date: 2004-10-14T13:41:09 Editor: JamesMitchell [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsRelease125 URL: http://wiki.apache.org/struts/StrutsRelease125 no comment Change Log: -- @@ -49,6 +49,8 @@ || 2. || Run Cactus Tests (see below) || _ || || 3. || Play test bundled applications (latest GA release of Tomcat) || _ || +Note - would be nice to have a set of Struts test cases to run against these apps ;) + === Cactus Tests === || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Completed''' || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Apache Struts Wiki] New: StrutsRelease125
|| Commons Lang (this should be removed) || 2.0 || Released || I took a look at this a few weeks ago when it came up last time, and it seems like all that's really called is one method. That method is used a lot by the tests, but it can easily be moved into a util class and that should take care of the dependency. If you want, I can work on a patch for this. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS - SVN / Roadmap
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 weekendis 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 [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [HI][TAGS] Greetings
I'm here to see if the struts development community is open for tags add-on for the existing struts tagslibs. Depends -- what do you have in mind? Going forward, I think we would only want to add tags that are specifically focused around Struts functionality. Tags that don't depend on Struts don't really belong in the Struts project -- some might fit into existing Jakarta Taglibs projects, or might be proposed as new subprojects there, and others might make good projects on their own, like the displaytag libraries. What do your tag libraries do? Joe -- Joe Germuska [EMAIL PROTECTED] 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
RE: Roadmap
Struts relies on Jakarta Commons stuff. So I think the pizza base is only good as the quality of the ingredients on top of it. Is there a way, for example, to get precise line error when, say the Digester cant intercept the struts-config.xml file, or when the underlying SAX XML Parser finds fault. I thought I remembered Howard Lewis Ship talking about factoring out the code which provides this to Tapestry into a commons library, but I don't see any signs of it. Of course, Tapestry is open source, and under the Apache license, so if someone wanted to try to apply its methods to Digester (or to Struts), either by factoring out or copying, that route is open. Joe -- Joe Germuska [EMAIL PROTECTED] 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
RE: Roadmap
On Thu, 2004-10-14 at 20:47, Joe Germuska wrote: Struts relies on Jakarta Commons stuff. So I think the pizza base is only good as the quality of the ingredients on top of it. Is there a way, for example, to get precise line error when, say the Digester cant intercept the struts-config.xml file, or when the underlying SAX XML Parser finds fault. I thought I remembered Howard Lewis Ship talking about factoring out the code which provides this to Tapestry into a commons library, but I don't see any signs of it. Hmmm You may be thinking of HiveMind, which is the refactored IOC-type container that grew out of Tapestry. HiveMind is similar in focus to Spring, but follows an approach that is similar to Eclipse. (separation of configuration, services, with extension points). I believe you can get line information from the SAX Parser -- you can definitely get a lot of details from it. But to tell you the truth, personally whenever there is a configuration bug in the XML I don't have a hard time finding it. I think the information in the current stack trace is pretty informative. As for JSPs. That's a problem were not going to solve. When Tapestry refers to line precise error reporting, it really has more to do with views / components and misconfiguration of them. It is definitely a cool thing, but unfortunately JSP is an ass backwards template language. With that said, let me just go on record as saying I was intrigued with Tapestry. I definitely liked the mile high concepts they went after. (reminds me of ASP.NET). There is a lot i don't like about it. And there is stuff they are working on that may make it better (but auto binding of the Attributes like they do is nice in theory, but difficult in practice. Take a look at the IN/OUT/RESET workflow. In practice however, I hated using it. And in the end I boiled the difference down to top down compilation of component pages (tiles and jsf) to inside - out (tapestry). Personally I'm a top-down guy. (although struts can borrow some decorator ideas from site mesh -- with the request processor chain it could be possible to pretty easily make a StrutsMesh). I'm rambling... Of course, Tapestry is open source, and under the Apache license, so if someone wanted to try to apply its methods to Digester (or to Struts), either by factoring out or copying, that route is open. Joe -- Joe Germuska [EMAIL PROTECTED] 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
RE: Roadmap
Hmmm You may be thinking of HiveMind, which is the refactored IOC-type container that grew out of Tapestry. HiveMind is similar in focus to Spring, but follows an approach that is similar to Eclipse. (separation of configuration, services, with extension points). No, I know about HiveMind, although I must admit that it seems like a lot of overhead for a lightweight container. So far, Spring is serving my purposes for dependency injection pretty well... With that said, let me just go on record as saying I was intrigued with Tapestry. We should definitely learn all the lessons we can from Tapestry, and all the other controllers out there. Easier for me to say than to do, although I have looked at WebWork a little bit. (although struts can borrow some decorator ideas from site mesh -- with the request processor chain it could be possible to pretty easily make a StrutsMesh). What would StrutsMesh do that couldn't just be done with SiteMesh? I have only looked at SiteMesh a little, but it seems like it should be able to fit in anyway. -- Joe Germuska [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
