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 21:13:44 GMT
My main objection to that is then there's no way to say "1.1 only".
We would have to call 1.1 "1.1.0" so that "1.1" and "1.1.*" would be
different.  Or, I suppose, change your patch to gerVersion.length()-1
and encourage "1.1*" not "1.1.*"

Thanks,
    Aaron

On 6/9/06, Dain Sundstrom <dain@iq80.com> wrote:
> If we really need it, I think the syntax 1.1.* would be ok since it
> would easily be parseable and translated to [1.1-1.2) in a formal
> version syntax.  For the patch, I'm thinking of something like
>
> if (version.equals(gerVersion) ||
>          (gerVersion.endsWith(".*" &&
>          version.startsWith(gerVersion.substring(0, gerVersion.length
> () - 2))) {
>
>      match = true;
>      break;
> }
>
> Don't trust that code; I free styled it in this email, but you get
> the idea.
>
> I do think this is too risky for 1.1 since this code could easily
> have unintended consequences.
>
> -dain
>
> On Jun 9, 2006, at 5:59 AM, Paul McMahan wrote:
>
> > That's a good idea and it would be pretty straightforward.  But now
> > that Dain has brought our attention to GERONIMO-1637 I'm concerned
> > about deviating from the G 1.2 activities where the full syntax of
> > maven version ranges will be introduced.  I don't know much about
> > maven version ranges - there may be some subset that can be
> > implemented during G 1.1.x that addresses our specific concerns about
> > forcing plugins to continually update their geronimo-plugin.xml.
> >
> > Best wishes,
> > Paul
> >
> > On 6/8/06, Donald Woods <drw_web@yahoo.com> wrote:
> >> Paul, what if we tweaked your proposed patch and allowed the
> >> plugin to
> >> provide an optional attribute of exactVersion=required, which would
> >> control the behavior?
> >>
> >> -Donald
> >>
> >> Paul McMahan wrote:
> >> > 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