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 <[EMAIL PROTECTED]> 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 <[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
>> >> >
>> >>
>> >
>> >
>>
>>
>>
