On Jun 8, 2006, at 9:12 AM, Aaron Mulder wrote:
Well, if you're going to submit that patch, you need to include a
change in the annotation in the plugin schema along with it -- it
specifically says that field is an exact match.
I'm still not sure I'm on board with this, though. I don't feel like
we can say with confidence that a plugin that works in 1.1 will work
in all 1.1.x releases. Perhaps if we can articulate the rules for
what changes are acceptable for 1.1, and that implies that plugins
shouldn't break, then I'd feel more comfortable with this. We'd also
have to release 1.1 as 1.1.0 so that if you *wanted* to limit it to
the initial 1.1 release, you could.
I'm not sure I'm on board with the plugins claiming knowledge of who
can use it and what versions they are -- seems backwards to me. I'd
rather see each new Geronimo or Geronimo-based platform version
maintain a list of plugins and their versions known to work (and that
list should be updatable post-release). In other words, why not have
the platform track the compatiable plugins rather than the plugins
tracking the compatible platforms?
In either case, a user should be able to say "I don't care, just do
it" if versions don't match up.
It's somewhat a "half a dozen of one" or "six of the other" type of
problem, but in the end i'd opt for making things as easy as possible
for plugin developers even if it makes things more complicated for
us. Ideally, users would make plugins out of everything and go
plugin crazy.
For now, I'd be fine with non-exact matching in the manner proposed.
Maybe with the addition of a wiki page for each plugin where people
can document known compatibility issues.
My $0.02
-David
Thanks,
Aaron
On 6/8/06, Paul McMahan <[EMAIL PROTECTED]> 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
> >
>
