I think the problem I see with that is that if you are making changes to existing code in the Struts distribution it means that people have to make a conscious choice to go down a potentially incompatible path.
I think struts.sf.net works fine for things that truly are extensions, i.e., things that don't require an updated struts.jar for instance... But, anything that would require that, like these Ajax-aware tags requires one existing class be altered, makes it more difficult... If I were to finish this up and post it on struts.sf.net (or the Wiki, same argument) and then people decide to use it, they won't be able to move to 1.3... well, *theoretically* they couldn't, in this case they actually probably could, but for something like my setupItems a while back for instance, they couldn't. They would be relying on ME to upgrade it for each new Struts version (or prior versions maybe even) or they would have to do it themselves. But, if it was accepted into the Struts project proper, then it would be dealt with as part of the project, and while I myself still might be responsible for making sure it works with the next version, I am then doing so in the context of the larger project. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, April 7, 2005 2:01 am, Don Brown said: > I haven't really been following closely, but what is wrong with using > struts.sf.net for distributing struts-related extensions? I've been > using that site for years with good results. Some ideas became struts > subprojects and others didn't go anywhere. We've been very accepting of > new projects over there and I believe Martin or Ted have already > suggested it. struts.sf.net gets tons of hits and is a very good way to > get your project out there and known. > > Don > > Dakota Jack wrote: >> The below is a continuing problem. At this stage, Struts is pretty >> mature and if you are not a committer able to make decisions, there >> really is not too much you can do of interest with Struts other than >> applications, although I will probably write my own branch this summer >> for my own use with IoC. However, again, unless you are a committer >> as in MappingDispatchAction, LookupDispatchAction, UploadAction, and >> other like Strust application code not really part of the framework, >> you face this problem Frank is facing because there is no effective >> way to make these potential plugins available to the public. It would >> be wonderful if there were a way to provide choices without having the >> pecking order more important than the diversity of projects. I hope >> to Hell that no one takes this as being a personal matter. Sometimes >> you have to discuss principles and leave the personal trash at home. >> A general scheme for application plugins would be really nice. There >> should be a way for Frank's work to become available for people that >> would like to use it. I don't think a rehash of the Wiki and like >> recommendations really would be helpful on this, so please don't go >> there unless you feel you must. >> >> >> <SNIP> >> On Apr 6, 2005 9:40 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> >>>Martin Cooper wrote: >>> > It's just a subset of >>> >>>>the possible schemes that people use for partial page rendering. By >>>>adopting something like this as a Struts subproject, it gives the >>>>appearance that Struts is endorsing this one particular approach to >>>>the more general problem. That will carry a lot of weight in the >>>>Struts community, and since I don't believe that this is the "one true >>>>way" (LOTR again ;), that is not something I want to see. >>> >>>That's a valid point. No doubt there are 100 ways to skin this >>>particular cat, and I wouldn't even claim to be proposing the best of >>>the bunch. >> >> </SNIP. > > > --------------------------------------------------------------------- > 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]
