I'm sold with Paul's idea, now a question, could it be possible for people to become committers to the plugins in this subproject without being an struts committer?
I have 2 people helping me with the GWT plugin, and the JSON plugin, in the first case one of them rewrote the plugin for the new GWT version, on the second case the other one is fixing bugs and making improvements. It would be great if people could become committers to this subproject easier (compared to becoming an struts committer). musachy On 8/19/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > Don, > > I want to propose independent projects/releases. The only problem is going > to be versioning, because all plug-ins are probably 2.0.x, right? > > Paul > > On 8/19/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] > > > > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
