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 02:52:58 GMT
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