+1 for keeping the Portlet plugin in the core Struts 2 distribution and project. Nils-H is actively maintaining it and I am interested in maintaining it as well.
James On Tue Aug 21 1:43 , 'Nils-Helge Garli' <[EMAIL PROTECTED]> sent: >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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
