I assume there will be at least one beta release of Struts 1.1 and a release candidate after that. That will provide ample time to identify any specific incompatibilities and address them. At least we will be able to identify the exact cause of the incompatibility and then we can discuss a specific problem rather than unidentified issues.
It's too early to give up on the ideal solution which is not adding a second package. A second package will cause grief similar to the struts-form.tld. The periodic bug reports of people trying to use that taglib are annoying but imagine the time the bug reporters wasted trying to use that taglib. It probably would have saved the world some time if it had been removed prior to 1.0. People using pre-1.0 Struts or pre-1.1 nightly builds should expect to make some minor changes if they upgrade. Especially when the changes will save them time in the long run. People moving from 1.0 to 1.1 are already in for some global search and replace due to the commons stuff. They are also going to have to do some extensive testing because a great deal of changes have been made, aside from the Big check-in. Nobody needs to upgrade an application that is well underway with a particular version of Struts. If they do upgrade then they need to examine the migration issues and weigh the migration cost against benefits of the new features. Hopefully there won't be any known migration issues that aren't resolved during a beta release. Hal > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 18, 2002 7:47 AM > To: Struts Developers List > Subject: Re: [PROPOSAL] Modular Applications (the BIG checkin) [LONG] > > > Martin Cooper wrote: > > If there are incompatibilities that cannot be remedied, > yes. But that is > > true of any change we might make from one version to the > next. If people > > don't want to use new functionality, they don't have to upgrade. > > I haven't been able to trace everything back, but I have run > into issues > with the new controller looking for an ActionConfig object if I get my > pre-BIG and post-BIG 1.1 JARs get confused. This may be a > Tiles-related > issue (which would also apply to any ad-hoc Tiles-like enhancements > people have made). > > My core issue is that we really had enough for 1.1 release before the > new servlet. > > Now if for any reason they cannot use the new servlet, then we have > effectively locked them out of the reset of the 1.1 codebase, with > falling back all the way back to 1.0 being the only ready > alternative. > > > > > If people are as eager as they appear to be to use the other new > > functionality being introduced in Struts 1.1 (indexed and nested tag > > extensions, declaratoive exception handling, etc), then I > would think that > > the beta and RC cycles should flush out anything else. > > Again, this is my point. I'm concerned that we are linking a > rather big, > extremely cool change with all these very useful, but somewhat boring > incremental changes, and not providing developers with enough > granularity. > > > > > I'm not sure what you're referring to here. What import > statements need to > > be changed to deploy Struts 1.1 today? I have not had to > change any except > > where I'm actually extending the new functionality. > > Here I refer to the the switch from 1.0 to 1.1, where we > changed over to > the Commons packages. > > > > > > 8. The existing package is not broken. The likelihood that it will > > > require maintenance is negligible. If we declare that the original > > > ActionServlet is feature-locked, we are not obligated to > change it in > > > any way. All new functionality can be bundled with the > new controller. > > > > There are currently almost 100 open issues in Bugzilla, so > to some extent it > > is broken. Of course, we'll be fixing some number of those prior to > > releasing Struts 1.1 anyway. However, if we have separate > packages for the > > multi-app stuff, then maintenance becomes harder, because each bug > > potentially needs to be fixed in two places. > > I don't believe the "broken" issues relate to the > ActionServlet package. > > If they did, then they should also be part of a 1.0.3 release. > > > > > > 13. Giving the new package a new name will reduce the > maintenance cost > > > of dependent components by allowing a single distribution > that works > > > with either controller. > > > > I guess I don't understand this point. > > The point is that if distributing both servlets did not > create a lot of > duplicate code, why can't we have both? > > People who can't use the new one for some reason, say they > extended the > ActionServlet in unseemly ways, can continue to use the original > servlet, and still be able to use the other new features. > Some of these > features have been in place since right after 1.0 was released. > > If distributing both servlets does create a lot of duplicate > code, then > I would anticipate that once this gets out of the laboratory, we will > find a lot of people with compatibility issues. > > > > In my day job, my team is already starting to build a > substantial multi-app > > application on top of the new code, so we'll be helping > flush out any > > remaining problems (even while we are also extending the > new framework). > > That will help. ;-) > > That's certainly good news! Unfortunately, my substantial applications > are based on Tiles, and so I haven't been able to test the new servlet > with my real production applications, nor have I been able to start > retrofitting these for multiapps. > > I'm eager to do this, but having to do it just makes a 1.1 > release-candidate seem farther away then ever. > > > > > I think we're going to want at least one beta cycle before > we go to an RC. I > > say that not just because of the multi-app support, but > because of all the > > other new functionality that has been introduced since > 1.0.x. We can most > > likely get docs done, if not before beta, then before RC1. > > Which underscores my other main point. If not for the new servlet, we > could go to a 1.1 release-candidate with the other new functionality, > and have a final release in circulation for JavaOne. We had in fact > talked about doing that, and the 1.0.x releases were to be > preludes to a > 1.1 RC. The new servlet is going to require more testing and more > changes to the documentation, which is keeping the rest of 1.1 out of > the hands of teams who are not permitted to use Nightly Builds in > production. Unfortunately, many organizations I work with > treat this as > a Prime Directive. The magic "release" stamp means a lot. > > Based on the pre-BIG codebase, we can definately have 1.1 out for > JavaOne. It would still be ~possible~ with the new servlet, but, > realistically, by no means assured. > > I'd also like to get away from these monolithic releases, and try to > develop a more step-wise pattern, so as get things out to the > production > teams more often than once a year. > > > > > As I mentioned earlier, with so many developers eager to > use the other new > > functionality introduced since 1.0.x, we'll get more > compatibility testing > > than we would otherwise get. In particular, if we had a > later release for > > only the multi-app support, then people who didn't want to > use that would > > not bother to test against it, and we wouldn't have nearly as much > > compatibility testing. That would be a bad thing. > > I believe that the multiapp support is the greatest thing for Struts > since, well, since Struts. This will really open Struts up for use by > larger teams and even larger applications. We will quickly > seen snap-in > Strutlets, and power users building entire applications just by > assembling things other people have built. We will not have > any problems > in finding lots and lots of people to test this. > > The Bad Thing, I think, is forcing people to buy into the new servlet > just to make use of all the other changes made this year. > > Again, I do think the new servlet is a Good Thing, an engineering > marvel, really. But we have positioned Struts as a framework for > serious, professional teams, and it is incumbent upon us to be > conservative. Or, to at least thoroughly consider the most > conservative > path before rushing forward, burning bridges as we go. > > > -- Ted Husted, Husted dot Com > -- For priority Struts support, > -> visit http://husted.com/about/services > > -- > 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]>
