geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <>
Subject Re: Where to develop plugins (was: Re: JPA Plugin patch)
Date Fri, 01 Sep 2006 15:25:29 GMT
I think that the plugin architecture is really powerfull and that all core
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
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 <> 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 <> wrote:
> > On 9/1/06, Aaron Mulder <> 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
> >
> >

Guillaume Nodet

View raw message