What I meant by 1.1.* was the Maven behavior of private builds like 1.1-1 being taken as newer than 1.1. Also, being able to use the behavior of 1.1-<starting with any alpha> is less than 1.1. Basically, I should be able to specify 1.1 in the plugin and have it work on 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1, then I'd argue that we broke something in 1.1.1, given it should only be a maintenance release and app/plan breaking changes should only go into 1.2.

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....

-Donald


Aaron Mulder wrote:
On 6/7/06, Donald Woods <[EMAIL PROTECTED]> 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


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to