I think that the plugin architecture is really powerfull and that all core features
that are part of J2EE should be available as plugins from Geronimo.

For other plugins, I think a single open source community
"a la" mojo is the best way to go.  It will encourage users to develop
open source plugins and to build a community. 

Let's say we build that as a subproject of Geronimo.  It would imply that
that the geronimo community need to maintain all the plugins.  This means
that either the current geronimo committers will have a lot of additional
burden, or that we need to grow the community with each plugin which
has a dedicated maintainer. Is that what we want ?

The other point is about plugins with LGPL dependencies.  What if
someone has a plugin for jBPM integration inside G ? We would
have to refuse the donation.  So we could start another community
elsewhere, but having two different communities is,
imho, not the best way, as it will be more confusing for users than
a single broad community containing all non-core plugins.

Last, I think it' s unfair to tell that Aaron is not playing by the Geronimo rules.
I am also developing a plugin for ServiceMix, and I don't think it should
be hosted in Geronimo, should I ?  I think there is big decision to take,
and we should discuss it in a peaceful manner.  Throwing arguments
like this one will not help much ;) 

On 9/1/06, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
There are several issues here:

1) Do I think we were wrong to develop the JPA plugin outside
Geronimo?  No.  We can argue about this as long as you like.  Do Maven
committers work on Mojo plugins?  I'd be surprised if none of them
did.  Are you saying that nothing but server/* is RTC?  ("I'd merely
point out that any activity done outside the trunk or bug fixes don't
have to be RTCed.")  That wasn't my understanding -- doesn't RTC cover
devtools and xbean?  Still, it's irrelevant, because Cliff and Roberto
are not committers and could not have worked easily in the sandbox
either.  Cheer up -- Chariot could have tried to make this
proprietary.

2) Should the code be merged into Geronimo?  We're happy to donate the
code if Geronimo wants it.  I wouldn't want to do that until G 1.1.1
and the first installable version of the plugin is released, but
hopefully that will be quite soon.  If you want to start the wheels
turning for a donation, be my guest.  Is it enough to post code to a
Jira with the Apache flag on?

3) You must not understand the plugin system very well to make
statements like "It's also disruptive to the community as they need to
look it up in their notes where the plugin comes from rather than
download it from a Geronimo space.".  A user doesn't need to know
where a plugin was built -- all plugins can be included in the plugin
repository and this one certainly will be.  So the same console
screens or command-line tools that show the list of Geronimo-source
plugins will shows the SourceForge-source or Elsewhere-source
(presently I'm thinking of Liferay) plugins.  And further, if a user
wants to see where a plugin comes from, the console screens include
the plugin's home URL.


I think your comments show that we have a fundamental disagreement
over the purpose of the Geronimo project.  I believe Geronimo should
hold the essential glue that ties a J2EE server together.  I do not
believe that it should hold more than that.  XBean is used standalone,
so while I'd like Geronimo to adopt it, I think it should be a TLP.  I
think OpenEJB and ActiveMQ should be TLPs.  I don't think Jetty or
Tomcat or HOWL or Axis should be rolled into Geronimo.  It would be
great if the Transaction and Connector core code were split off and
maintained as part of Jencks.  What's left for Geronimo?  The
configuration and deployment system, the console, the module
configuration, the deployment plan syntax, the DConfigBeans,
everything that ties all those critical components of a J2EE server
together, and gives the developer a consistent experience across
module types.

Certainly I would like to see more plugins developed, and I really
don't feel any particular urge for that to be done within the Geronimo
project.  I think we should let go and encourage all plugin
development no matter who or where.  But as I said, if the community
wants to take over the development of certain plugins, that's OK too
-- I just don't think it's necessary.  And I certainly object to being
told that I have a responsibility to do plugin development *only*
within the Geronimo project, because I don't think that's what the
project is about.

Thanks,
    Aaron

On 8/31/06, Jacek Laskowski < jacek@laskowski.net.pl> wrote:
> On 9/1/06, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
>
> > The main developers who produced the plugin were not Geronimo
> > committers, and I had the space available.
>
> You still have here, in the Geronimo repo. You're a Geronimo committer
> and you can get as much "as you wish"[*] No need to go outside in this
> particular case.
>
> > The TopLink and Hibernate
> > implementation plugins could not be developed at Apache, but the core
> > JPA plugin could otherwise have been.
>
> That's what I've been asking to be moved here. Also, Dave B's asked
> about a similar thing.
>
> > However, I'm not convinced that
> > the sandbox is the right place to develop plugins in any case, because
> > I plan to actually release them, and I would be skeptical about
> > releasing anything from the sandbox -- seems like that would be a
> > cheesy end run around RTC.
>
> So, let's create a Geronimo subproject - plugins - and have them
> released under the very same rules as devtools is - at the time
> plugins wished to.
>
> > Also, recall that the main point of plugins is to facilitate the
> > development of value-added features outside the Geronimo community.
> > There's little point to creating a plugin architecture and then
> > insisting that everyone working on plugins do so in the Geronimo
> > sandbox.
>
> Noone's said so (or I've been misunderstood because of my (copy of) English).
>
> You're *a Geronimo committer* and you ought to keep development of
> Geronimo bits as close as possible. How can we explain our users that
> Geronimo committers develop their code outside when it's permissible
> to do so in the Geronimo tree? You can't simply wear Geronimo hat and
> do things as Aaron wished to (I hope I've got it right). You're a
> teammate and as a Geronimo committer you're supposed to play by
> Geronimo nor your rules.
>
> It's also disruptive to the community as they need to look it up in
> their notes where the plugin comes from rather than download it from a
> Geronimo space. More troublesome. Another factor to take into account.
>
> Jacek
>
> [*] Remember the movie - "The Pricess Bride" you had told me in this
> semi-Italian and semi-Polish restaurant in Barcelona? ;-) I could
> watch and love it!
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
>



--
Cheers,
Guillaume Nodet