On 8/19/07, Ted Husted <[EMAIL PROTECTED]> wrote: > > I'm not sure that anyone is maintaining them now. I'm not sure that > they all work. > > My thinking is that if they are kept at another location where there > is a lower bar to entry, then perhaps we can attract someone to > maintain them.
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. By pushing plugins out of the Struts distribution, we force additional approvals at such companies just to be able to use the plugins. Many will opt to avoid those additional dependencies, either because of the hassle or because they cannot justify the additional external dependency that now doesn't come from a respected source such as the ASF. My concern is that some of the code in our distribution is not being > used, or otherwise fully tested, by anyone in the group. When that is > the case, then we should not be distributing the code. 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. -- Martin Cooper We should > archive it, and, perhaps, for added value, make it available at > another location. > > -Ted. > > On 8/19/07, Don Brown <[EMAIL PROTECTED]> wrote: > > Agreed, Spring should be a first-tier plugin. I'm fine with spinning > > off the others, but who would maintain them? If it will be the same > > people, then perhaps we should keep them in the repository. > > > > How does Maven handle this situation? Wendy? > > > > Don > > > > On 8/20/07, Tom Schneider <[EMAIL PROTECTED]> wrote: > > > I disagree with moving the Spring plugin outside of the core set of > > > plugins. I think a lot of people use Spring and it would be a shame > to > > > not have it as a core feature. Keep in mind that I think we run a > huge > > > risk (IMO) of plugins being unmaintained if we set them free, however, > > > I'm more than happy to do it for the more fringe plugins that not a > lot > > > of people use. I also think the JSF plugin is more of a fringe > > > plugin--I'd be curious to know how many people are actually using it > in > > > production. > > > > > > There has been no interest whatsoever of anyone helping out on table > > > tags. I knew I wouldn't have the time to work on it after I initially > > > created it, but I was hoping other developers would take > interest. That > > > hasn't happened. (I may get some time if we upgrade to struts 2 at > > > work) If we want to integrate it into core, we need developers to > > > really run with it and make it real. Right now it isn't production > > > ready--I just haven't spent enough time with it. > > > > > > Everything else in your list looks good to me. > > > Tom > > > > > > Ted Husted wrote: > > > > On 8/18/07, Musachy Barroso <[EMAIL PROTECTED]> wrote: > > > > > > > >> do you mean to move the plugin out of Struts? Because Dojo is > already > > > >> on its own plugin in trunk. > > > >> > > > > > > > > My question was whether we wanted to keep Dojo as part of the > project, > > > > or move it GoogleCode, along with the YUI plugin. I think some of > the > > > > other questions misunderstood where we already are, in that for > 2.1.x > > > > Dojo is one of our bundled plugins, like Spring and JasperReports. > > > > Right now the bundled plugin list for 2.1.x is > > > > > > > > * codebehind > > > > * config-browser > > > > * dojo > > > > * jasperreports > > > > * jfreechart > > > > * jsf > > > > * pell-multichart > > > > * plexus > > > > * spring > > > > * struts1 > > > > * tiles > > > > > > > > The underlying question is whether we have active committers who > > > > actually *want* to maintain all of these plugins as part of the > trunk. > > > > > > > > Initially, we dragged most of these along because there were part of > > > > WebWork and 2.0 was the backward-compatibility series. Moving > forward, > > > > we might want to be more careful about the plugins that we bundle. > One > > > > idea would be to create a Struts Plugin project somewhere, where > > > > third-party plugins could be maintained jointly. > > > > > > > > My suggestion would be to retain > > > > > > > > * codebehind > > > > * config-browser > > > > * jsf > > > > * struts1 > > > > * tiles > > > > > > > > and add (with the permission of the owners) > > > > > > > > * JSON Plugin > > > > * Table Tags > > > > * Smart URLs > > > > > > > > And then encourage the remainder be adopted by an independant open > > > > source project (while we keep a snapshot of what we have now in the > > > > Archive). > > > > > > > > * dojo > > > > * jasperreports > > > > * jfreechart > > > > * pell-multichart > > > > * plexus > > > > * spring > > > > > > > > Ideally, some of the other plugin projects might merge into the > > > > independant Struts Plugin project, making it easier for people to > gain > > > > access later if the original author drifts awqay. > > > > > > > > Thoughts? > > > > > > > > -Ted. > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > > -- > HTH, Ted <http://www.husted.com/ted/blog/> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
