Re: cleanup weblog entries plugins

[Craig L Russell]

Hi Allen,

On Sep 4, 2006, at 4:28 PM, Allen Gilliland wrote:

Craig L Russell wrote:

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?

My concern may be a little premature, but the potential problem I see is that if all the plugins are part of the core build then we are 1) bloating the core application with code that may never be used

good point

and 2) since plugins are not part of core functionality it is much easier for people to neglect them over time and not maintain them

good point

and thus 3) the core developers feel obligated to maintain the plugin code which makes things harder on us.

I understand.

I don't really care if we allow people to develop plugins directly in the core project, but I don't see why we would want *all* plugins to be built and packaged with the core build. That defeats the purpose of a plugin.

It seems that there might be a "core" set of plugins that make sense to develop in the core, but I understand the issues with the other plugins. Especially since over time, the plugin interface that we expose will likely change, and obsolete plugins will have to be fixed before we evolve the interface.

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.

We have started a roller_support project at java.net specifically for this

seems like a good idea especially if it is well advertised.

Craig

so that users who are only interested in themes, plugins, and custom editors can easily work on those things and download them separately.

-- Allen

I agree that we want to build community, but in my opinion pushing these addons out of the core application does just that. It places the responsibility in the hands of the community instead of leaving it like it is now, where us core developers are the only ones really working on the them.

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!

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