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 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 and thus 3) the
core developers feel obligated to maintain the plugin code which makes
things harder on us.
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.
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 so that users who are only interested in themes, plugins, and
custom editors can easily work on those things and download them separately.
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.
-- Allen
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!
