Makes sense to me. Would we bundle the second-tier plugins in our release or just the first tier? Would second-tier plugins each get their own release cycle, share one together, or be linked to the main Struts 2 release cycle?
Don On 8/20/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > Hi all. > > I think the Spring framework has a great model for this kind of problem. > They call it the "Spring portfolio" which is the Spring Framework (proper) > and then subprojects for very special criteria (security, web services, > etc.). We all know Spring is pretty good at integrating technologies, but > not every technology has the "weight" to get first tier support. When it is > lesser, they get maintained in the "Spring Modules" project. > > I think we could do the same thing here. Struts 2 could include only > first-tier plugins that actually are part of the Struts release, but then > have another Struts subproject that maintains other plugins. > > In case someone may bring up Shale and the old "umbrella" framework > argument, I think my proposal is quite different. I am not proposing > different frameworks and communities, but simply creating another Maven > project under Struts for Struts plugins. > > Paul > > On 8/19/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > > Martin Cooper wrote: > > > Perhaps. Perhaps not. But it's pretty much guaranteed that we would > > lower > > > the base of people who _could_ use them if they're not here. Some > > companies > > > (my current employer included) require approval for each and every open > > > source component before it can be used within the company. > > > > FYI, I'm in the same boat where I am, and I know the hassles we go > > through sometimes to get various libraries/components/whatever approved, > > so I definitely know where your coming from with this point. In talking > > to other folks, this doesn't seem to be unusual at all. > > > > > I disagree. I think it is just fine to distribute such code. If people > > start > > > to use it and have problems with it, then perhaps this will drive > > additional > > > contributors to it. Gaining additional contributors to it as part of > > Struts > > > seems much more likely to me than if it's off in the weeds somewhere. > > > > You mentioned the "...respected source such as the ASF" in the previous > > paragraph, and I certainly agree. I think however that if the approach > > was as you say, that potentially untested code, or more accurately code > > not used to a great extent by active committers, which I believe is what > > Ted was talking about, was coming out of a respected ASF project, it's > > not hard to imagine that respect declining when a lot of bug reports are > > opened for a particular plugin. One plugin could wind up ruining the > > good reputation of the larger project. > > > > And if no one was maintaining and using that code to begin with, I think > > it's a bit of a gamble to hope someone will be spurred into action by > > some negative feedback. Maybe someone will be, but I don't think that's > > a risk worth taking if you want to keep a good reputation and keep being > > a respected project :) > > > > I for one see Ted's suggestion as a good compromise... you could almost > > in a sense view the external location, wherever that happens to be, as > > something of a plugin incubator... assure the code has a community of > > developers willing to maintain it and ensure it's at a level of quality > > that fits in with the rest of the S2 distro proper, and *then* roll it > > in to the distro later. For any plugin that there's any doubt about > > today (and I don't know which those are), they can be shifted there and > > allowed to grow that community. And if some never do, it's not the end > > of the world: they're still there for anyone that wants them. > > > > To address the concern you raised about approvals, I think it would be > > important to make the external location an endorsed source of plugins. > > Maybe it makes more sense to have a plugins subproject under Struts, I > > don't know, but whatever the case, so long as people understood that > > yes, this plugin repository/incubator/whatever was *the* approved place > > to get plugins from, I believe the approval process would be eased a bit > > for most users in that same situation as we are. > > > > At the end of the day, it's always said that an ASF project depends on > > developers who themselves are using the code. It's supposed to be code > > for themselves that they happen to share with others, that's how I've > > come to understand the underlying concept anyway. If that's true, then > > it seems like keeping code in S2 that might not be maintained and > > actually used by active commutters is a contradiction of that, and Ted's > > suggestion offers a viable alternative that keeps the code alive, and in > > fact presents (possibly) a better chance for it to succeed. > > > > > -- > > > Martin Cooper > > > > Frank > > > > -- > > Frank W. Zammetti > > Founder and Chief Software Architect > > Omnytex Technologies > > http://www.omnytex.com > > AIM/Yahoo: fzammetti > > MSN: [EMAIL PROTECTED] > > Author of "Practical Ajax Projects With Java Technology" > > (2006, Apress, ISBN 1-59059-695-1) > > and "JavaScript, DOM Scripting and Ajax Projects" > > (2007, Apress, ISBN 1-59059-816-4) > > Java Web Parts - http://javawebparts.sourceforge.net > > Supplying the wheel, so you don't have to reinvent it! > > > > --------------------------------------------------------------------- > > 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]
