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