geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Plugin versioning problems
Date Thu, 08 Jun 2006 13:43:38 GMT
On 6/8/06, Donald Woods <> wrote:
> BTW - How can we add new Plugins to the geronimoplugins website?  Are we
> going to setup a Geronimo subproject (like Daytrader) with the site
> framework checked into svn, along with any scripts needed to build the
> plugins?  It seems convoluted to have samples and plugin builds in the
> main Geronimo tree, which are not shipped with the server or
> automatically pushed to geronimoplugins.  Wouldn't it be easier to
> maintain if we moved all the samples out to /trunk/samples/modules and
> all the equivalent plugin configs to /trunk/samples/plugins?  That way,
> the Samples and plugins can be built, published and enhanced separate
> from the server development....

Currently, to get a plugin added to the web site, you can mail it to
me.  If you want to help out there, it would be great to have a script
that read the plugin.xml files and emitted the various PHP files with
all the plugin info!  Currently it's a little more manual.  :)

We should definitely have a separate are in the SVN tree for the
samples.  There's no reason they should be tied to the Geronimo
release schedule.

We also need a non-Apache space where we can write the plugin wrappers
for various interesting LGPL projects.


> Aaron Mulder wrote:
> > On 6/7/06, Donald Woods <> wrote:
> >
> >> Why shouldn't the Plugin support be as robust as module dependencies and
> >> allow the user providing the plugin to decide if they can support
> >> geronimo_version=*, 1.* or 1.1* ?  Limiting the plugins to only support
> >> predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to
> >> me and doesn't follow previous email threads about not deviating from
> >> Maven2 versioning behavior...
> >
> >
> > But what you've said here is "why shouldn't the plugin support be as
> > robust as A and allow B" where A != B.  Module dependencies let you
> > specify an exact version or no version.  Plugin dependencies also let
> > you specify an exact version or no version.  Neither of these support
> > 1.* or 1.1*.
> >
> >> Just as with the Tomcat JSP/Servlet Examples, you could easily provide a
> >> Plugin which should work on all 1.x releases....
> >
> >
> > My preference it to opt-in supported version, not opt-out unsupported
> > versions.  So I'd like the plugin developer to try a plugin on a
> > Geronimo version and if it works, list that version as supported.  The
> > alternative will most likely lead to Geronimo being willing to install
> > a plugin but the plugin not working.  If we get fancier version
> > dependencies we can consider things like "1.1.*" but I'm not sure I
> > like that.  I'm willing to be convinced, but I'd want to hear from
> > more plugin developers/maintainers.
> >
> > Thanks,
> >    Aaron
> >
> >

View raw message