Hi Allen, On Sep 1, 2006, at 9:14 AM, Allen Gilliland wrote:
for the current set of plugins I think that's fine, we can just move all the current plugins in to the core src tree and then modify the config to only enable a subset of them. i'll go ahead and take this approach since it really is the easiest in our current situation.
It sounds like you've chosen the right approach.
the main reason i proposed this though is that i believe very strongly that moving forward it's not our job to maintain all the plugins directly in the src tree. we don't have many people who do this right now, but eventually we want to build a user community that really does create and share plugins and that has to happen outside of the core project. we already have 10 plugins, what happens if the list grows to 20, 50, etc?
I'd like to understand your concern better. Simply developing a plugin doesn't require core knowledge of Roller, just the interfaces exposed by the callbacks. If someone wants to develop a plugin, under the current regime, a committer would have to test and commit the plugin to the src tree. So do we *not* want "plugin developers" to eventually become part of the committer list for Roller?
as long as we make it easy for people to add in a plugin then i think it's best that they be developed and maintained outside of the core src.
If this is the case, perhaps it makes sense to create a new project just for plugins. But this might be construed as anti-community- building ("core developers" versus "plugin developers").
Personally, I think that building the community is a good thing, and a developer starting out developing plugins is a good thing. Once the number of quality contributions of plugins and patches by a contributor is significant, the contributor should be considered for committer status even though they don't work in the core. Just my two cents.
Craig
-- Allen Sean Gilligan wrote:Anil Gangolli wrote:Sorry for entering this conversation a bit late.How about shipping these plugins but not enabling them by default. For example, I'd rather they ship as part of the normal install but we just comment them out in roller.properties.Or we could have an admin page to enable them like for editor pages. -- Sean
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
