Re: Plugin versioning problems

[Dain Sundstrom]

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