geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <drw_...@yahoo.com>
Subject Re: Plugin versioning problems
Date Fri, 09 Jun 2006 18:12:42 GMT
Inline below.

Aaron Mulder wrote:
> On 6/8/06, Donald Woods <drw_web@yahoo.com> 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.

If you create a project on Sourceforge or Javaforge, I'll come and help.
How about project=geronimoplugins to match the website name?

-Donald


> 
> Thanks,
>    Aaron
> 
>> Aaron Mulder wrote:
>> > On 6/7/06, Donald Woods <drw_web@yahoo.com> 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
>> >
>> >
>>
>>
>>
> 
> 

Mime
View raw message