geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <paulmcma...@gmail.com>
Subject Re: Plugin versioning problems
Date Thu, 08 Jun 2006 16:06:16 GMT
I definitely agree that a full fledged solution for version ranges is
out of scope for G 1.1.x.  I was thinking that a minor change to the
plugin installer's version checking could at least partially address
Donald's concerns and also avoid the version mismatch problem Dave C.
found in the candidate build.  Here's a patch that makes the plugin
installer only check the digits of geronimo's version that the
plugin's xml specifies.  So if the plugin specifies
<geronimo-version>1.1</geronimo-version> then it can be installed into
1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...

Best wishes,
Paul

Index: modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
===================================================================
--- modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java	(revision
412744)
+++ modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java	(working
copy)
@@ -1409,7 +1409,7 @@
             if(gerVersion == null || gerVersion.equals("")) {
                 throw new IllegalStateException("geronimo-version
should not be empty!");
             }
-            if(gerVersion.equals(version)) {
+            if(version.startsWith(gerVersion)) {
                 match = true;
                 break;
             }


On 6/8/06, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
> Perhaps I was unclear; I didn't mean to say this was a bad idea, only
> that our code doesn't currently support it.  I expect version ranges
> are on the road map, but if you want to work on them, you're more than
> welcome to.  :)
>
> I don't think this is a G 1.1.x discussion, since AFAIK it would
> require kernel changes.
>
> Thanks,
>      Aaron
>
> On 6/8/06, Paul McMahan <paulmcmahan@gmail.com> wrote:
> > On 6/8/06, Donald Woods <drw_web@yahoo.com> wrote:
> > > 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.
> >
> > +1   This approach is similar to how eclipse plugin versioning works.
> >
> > From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
> > "How to specify plug-in requirements
> > Plug-ins that require other plug-ins must qualify their requirements
> > with a version range since the absence of a version range means that
> > any version can satisfy the dependency. Given that all the changes
> > between the version x.0.0 and the version x+1.0.0 excluded must be
> > compatible (given the previous guidelines); the recommended range
> > includes the minimal required version up-to but not including the next
> > major release."
> >
> > IMHO geronimo should adopt eclipse's strategy for plugin versioning
> > where possible since the two sets of base requirements are quite
> > similar and eclipse is a few years ahead in this area.  The document
> > referenced above spells out their  strategy in detail.
> >
> > Best wishes,
> > Paul
> >
>

Mime
View raw message