geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Plugin versioning problems
Date Fri, 09 Jun 2006 18:15:06 GMT
Sourceforge is kind of slow, which is my main objection.  But perhaps
we can use it as a start.  What's Javaforge?

Thanks,
    Aaron

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