I couldn't fint the portlet plugin mentioned on the list of plugins for the different tiers. Where does it fit in?
As a plugin developer, I would definetively see it as a motivation having the "Struts 2" brand on the plugin. Nils-H On 8/20/07, Don Brown <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
