If they are in the wild, by all means polish them up and release them! (moving them to the sandbox svn area is unlikely to affect their uptake, really - but released is better if they are being used :)
- Brett Jeff Genender wrote: > -1 on demotion...unless we can release before a said demotion... > > There are 2 (jspc and jboss) that are becoming used pretty heavily...and > I think a demotion would be a negative...since they have been out in the > wild for some time now. > > So should I enable a vote for those in another thread? > > Jeff > > Brett Porter wrote: >> +1 to these, but let's make the sandbox plugins distinct. >> >> Let's also demote to the sandbox anything that hasn't had a release yet. >> >> - Brett >> >> Brian E. Fox wrote: >>> I've been looking at some plugins in the sandbox and I see some issues: >>> >>> 1. If sandbox plugins deploy sites, (as they probably should so they get >>> some visability), the scm connections are wrong because they inherit >>> from the mojo parent. >>> 2. Some plugins have the name maven-xxx-plugin instead of xxx-maven-plugin >>> 3. Many plugins aren't even posted on the mojo site. >>> >>> I'd like to have a vote on these issues: >>> >>> 1a. Should we create a mojo-sandbox parent and have sandbox plugins >>> derive from here? This way we can set the scm urls and anything else >>> that comes along here. Only the parent section would need to change when >>> a plugin graduates from the sandbox. >>> >>> - OR- >>> >>> 1b. Keep deriving from mojo parent, but add instructions to site to tell >>> devs how to override the scm connection when added to sandbox and add >>> instructions to guidelines for release to have devs remember to remove >>> the override when graduating. >>> >>> >>> 2. Should we correct the plugin names? >>> >>> 3. Should all sandbox plugins be added to the mojo sandbox site? >>> >>> Thx. >>> >>> >>> >
