A good way to go would be to open a ticket in Bugzilla with the notes from this thread, and mention that you are working on an implementation there.
10/16/2002 6:27:16 AM, Chanoch <[EMAIL PROTECTED]> wrote: >If noone else is doing this, I've got a day or two to give to this.... > >Since support for 3.2 is being dropped - shall I replace the 32 target >with a 33 target when submitting the diff? > > >chanoch > > >------------------------------------------------------------- > >The information transmitted is intended only for the person or entity to >which it is addressed and may contain confidential and/or privileged >material. Any review, retransmission, dissemination or other use of, or >taking of any action in reliance upon, this information by persons or >entities other than the intended recipient is prohibited. If you >received this in error, please contact the sender and delete the >material from any computer. Although we routinely screen for viruses, >recipients should check this e-mail and any attachment for viruses. We >make no warranty as to absence of viruses in this e-mail or any >attachments. > > >-----Original Message----- >From: Martin Cooper [mailto:[EMAIL PROTECTED]] >Sent: 16 October 2002 00:22 >To: 'Struts Developers List' >Subject: RE: Future Release Suggestion > > >If you, or someone else with some time on their hands, are a Tomcat >user, there is one thing that would be a big help. > >We have a series of unit tests that are run against different Tomcat >versions. At this time, we have configurations for Tomcat 3.2, 4.0 and >4.1. However, we know that Struts does not work with Tomcat 3.2, and >have decided to drop support for 3.2 in favour of 3.3. However, at this >time we don't have a test configuration for 3.3. > >I started messing with this a while ago, and discovered that 3.3 is >different enough from both 3.2 and 4.0 that blindly hacking at one of >these didn't work. ;-) However, I'm not a Tomcat user, so not really >familiar with what I needed to do to get it working. > >If someone is up for this, the place to look is build-tests.xml, in the >root of the Struts source tree. There, you'll find targets such as >'test.tomcat.nn' where 'nn' is 32, 40 or 41. All we need is a >'test.tomcat.33' that works against Tomcat 3.3.1. ;-) > >Seriously, though, it would be great to get this working. > >-- >Martin Cooper > > >> -----Original Message----- >> From: Daniel Honig [mailto:[EMAIL PROTECTED]] >> Sent: Tuesday, October 15, 2002 4:05 PM >> To: Struts Developers List >> Subject: RE: Future Release Suggestion >> >> >> Hello, >> With this in mind I'd like to announce that I've got some time on my > >> hands. Probably too much. So I'd like to attempt to get out of >> lurker >> mode and start helping out the committers. Can someone give me some >> direction as to some bugs >> that might be good to look at. >> I'll probaby spend half a day getting up to speed on >> catctus and the test >> framework which is crucial for any patches I might suggest. >> But I'd love >> to have a few of the committers deputize me to go off and inspect some >> issues. I've been collaborating with a couple guys on a tag >> library for >> WML. >> They've had to do most of the work until now so part of my >> effort is going >> to be helping them validate it and get it ready for review >> by the larger community. >> >> >> -Daniel >> >> -----Original Message----- >> From: Ted Husted [mailto:[EMAIL PROTECTED]] >> Sent: Tuesday, October 15, 2002 6:50 PM >> To: Struts Developers List >> Subject: Re: Future Release Suggestion >> >> >> As Craig pointed out recently, we all really do this for our >> own use, and if >> someone else can use it too, then >> that's "icing on the cake". >> >> Most of the Committers are highly enough placed in their own >> organizations >> that they can use the nightly build >> if they have to. So, the pressure to make incremental >> releases has not been >> so great. >> >> But a good portion of my income now comes from working with >> teams that are >> prohibited from using betas or a >> nightly build. So, to keep shoes on the kids, I'm going to >> need to work >> toward more incremental releases, so >> that my clients can use it (and so they can in turn use me ;0) >> >> But, yes, I think that down the road we will need to start looking for > >> reasons to cut a release. If we have several releases a year, then >> there will be less pressure to slip in one >> more "gotta have it", since the next >> release won't be so far away. >> >> Of course, at this point the die is cast, and we need to >> debug the features >> already promised. >> >> -Ted. >> >> >> 10/15/2002 6:35:28 PM, David Graham <[EMAIL PROTECTED]> wrote: >> >> >I think the problem is that some very heavy hitters were >> added into 1.1. >> >Validator, sub modules, map backed form attributes, tiles, >> RequestProcessor, >> >Plugins, etc. are all new (AFAIK) to 1.1. This amount of >> change requires >> >quite a while to accomplish. >> > >> >It may be beneficial in the future to address bug fixes and >> one big new >> item >> >per release. This way, production releases are more frequent. >> > >> >What do the comitters think? >> > >> >David >> > >> > >> > >> > >> >>From: [EMAIL PROTECTED] >> >>Reply-To: "Struts Users Mailing List" >> <[EMAIL PROTECTED]> >> >>To: <[EMAIL PROTECTED]> >> >>Subject: RE: Struts 1.1 Release >> >>Date: Tue, 15 Oct 2002 23:25:40 +0100 >> >> >> >>I totally understand and agree with the release policy, but >> I think it's >> >>worth remembering that a lot of these questions are driven by the >> >>constraints of users' environments - e.g. in corporate >> environments like >> >>ours, there any many people like myself continually >> fighting to get great >> >>open source products like Struts into the organisation so >> that development >> >>teams can use them, and the latest versions of them. >> However, this has to >> >>be done within the processes and policies that apply to any >> third party >> >>software, commercial or otherwise. >> >> >> >>Specifically, in our case, I am the product owner of Struts >> here among >> >>other products from the Apache family of projects here and it is my > >> >>responsibility to make the standard builds of Struts on our software > >> >>distribution servers so that development can reference this >> for use by >> >>their applications, as must be done for all external >> software (it's an >> >>audit point). However, in order to do this, I must get the >> new version >> >>approved by a central department which is extremely >> difficult, if not >> >>impossible for software that is tagged as beta regardless >> of the quality. >> >>(Yes, you can imagine how commercial software vendors deal >> with this in >> >>their versioning policy... :-( ) Therefore, all our applications are > >> >>currently stuck on v1.0.2 rather than the latest and greatest 1.1 >> >>regardless of how stable it may be in practice. I know >> that we are not >> >>alone in this kind of approach, and that this kind of >> situation and red >> >>tape is the reality in big organisations... >> >> >> >>Working in one of our architecture teams, I advise >> application development >> >>teams in our area when it comes to working out and >> implementing their >> >>roadmaps, and part of this requires the recommendation of >> technologies on >> >>the basis of an understanding of when certain products such >> as Struts can >> >>be made available for their use - this applies equally to >> any kind of >> >>software. >> >> >> >>So I would be interested in hearing any suggestions about >> how we could >> >>resolve the need for us to have a better understanding of >> how close we are >> >>to a final release of any given version, e.g. clearly >> listing the issues >> >>that are preventing a release being deemed as 1.1 quality >> on the website? >> >>Would it be possible to change the versioning policy so >> that more non-beta >> >>dot releases are made possible, since many components are >> known to have no >> >>issues? These are just some ideas - they may well not be >> workable but I >> >>would like to know what could be done, since it is very >> frustrating for me >> >>and others like me to play with great "beta" products and >> rave about them >> >>to colleagues, but not be able to make them available for >> use by their >> >>applications - this ultimately results in a lack of >> interest and apathy >> >>towards such products, which is a great shame given their quality. >> >> >> >>Hope something useful can come out of this! >> >> >> >>Best regards, >> >> >> >> >> >>Kosh >> >> >> >> >-----Original Message----- >> >> >From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] >> >> >Sent: 15 October 2002 22:58 >> >> >To: Struts Users Mailing List >> >> >Subject: RE: Struts 1.1 Release >> >> > >> >> > >> >> >Were you subscribed to the mailing list earlier today when this >> >> >was discussed? >> >> > >> >> >Struts 1.1 will be released when it's released. Period. No >> >> >variation from that. >> >> > >> >> >That said, even the beta versions of Struts far exceed other >> >> >software in terms of usefulness and reliability, so don't worry >> >> >about formal release dates and just start using the thing. >> >> > >> >> >Simon >> >> > >> >> >----------------------------------------------------------------- >> >> >Simon P. Chappell [EMAIL PROTECTED] >> >> >Java Programming Specialist www.landsend.com >> >> >Lands' End, Inc. (608) 935-4526 >> >> > >> >> > >> >> >>-----Original Message----- >> >> >>From: Bachan Sadanandan [mailto:[EMAIL PROTECTED]] >> >> >>Sent: Tuesday, October 15, 2002 4:54 PM >> >> >>To: Struts Users Mailing List >> >> >>Subject: Struts 1.1 Release >> >> >> >> >> >> >> >> >>Hi all, >> >> >>Any idea when Struts 1.1 would be ready for Production .??? >> >> >> >> >> >>Thanks ! >> >> >>Bachan >> >> >> >> >> >>-- >> >> >>To unsubscribe, e-mail: >> >> >><mailto:struts-user->[EMAIL PROTECTED]> >> >> >>For >> >> >>additional commands, >> >> >>e-mail: <mailto:[EMAIL PROTECTED]> >> >> >> >> >> >> >> >> > >> >> >-- >> >> >To unsubscribe, e-mail: >> >> ><mailto:[EMAIL PROTECTED]> >> >> >For >> >> >additional commands, e-mail: >> >><mailto:[EMAIL PROTECTED]> >> >> >> >> >> >>Visit our website at http://www.ubswarburg.com >> >> >> >>This message contains confidential information and is intended only >> >>for the individual named. If you are not the named addressee you >> >>should not disseminate, distribute or copy this e-mail. Please >> >>notify the sender immediately by e-mail if you have received this >> >>e-mail by mistake and delete this e-mail from your system. >> >> >> >>E-mail transmission cannot be guaranteed to be secure or error-free >> >>as information could be intercepted, corrupted, lost, destroyed, >> >>arrive late or incomplete, or contain viruses. The sender therefore > >> >>does not accept liability for any errors or omissions in >> the contents >> >>of this message which arise as a result of e-mail transmission. If >> >>verification is required please request a hard-copy version. This >> >>message is provided for informational purposes and should not be >> >>construed as a solicitation or offer to buy or sell any >> securities or >> >>related financial instruments. >> >> >> >> >> >>-- >> >>To unsubscribe, e-mail: >> >><mailto:[EMAIL PROTECTED]> >> >>For additional commands, e-mail: >> >><mailto:[EMAIL PROTECTED]> >> > >> > >> >_________________________________________________________________ >> >Internet access plans that fit your lifestyle -- join MSN. >> >http://resourcecenter.msn.com/access/plans/default.asp >> > >> > >> >-- >> >To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> >> >For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> >> > >> > >> >> >> >> >> -- >> To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
