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]>
