David Jencks wrote:
How are we going to name plugins for external apps, such as roller or
apache directory?
There are three versions involved:
1. geronimo version
2. external app version
3. plugin version
I figure if we're developing/releasing it the groupId is going to be
o.a.g.plugins
That leaves us with the artifactId and version to possibly encode this
info into.
Lets assume a version number of x.y.z.
Here are some possibilities:
A. Don't encode anything, just have the plugin version be (3). So,
roller-jetty-1.0 would happen to be for roller 4.0 and geronimo 2.1, and
you'd have to look inside to find that out. I'd suggest in this case
that changes in roller or geronimo versions would bump the major version
x or minor version y whereas releasing an enhanced plugin for the same
app and geronimo versions would bump z.
B. Include the external app version in the artifactId and don't encode
the geronimo version. E.g., roller-4.0-jetty-1.0 would happen to be for
geronimo 2.1 but you could see that it's for roller 4.0 from the
artifactId. This is basically the solution we used for specs. I assume
changing geronimo version would bump the major version x or minor
version y whereas releasing an enhanced plugin for the same app and
geronimo versions would bump z.
C. Include both the external app version and geronimo version in the
artifactId, e.g. roller-4.0-g-2.1-jetty-1.0 would be the first release
of a roller plugin using roller 4.0 and geronimo 2.1.
D. Include the geronimo version but not the external app version, e.g.
roller-g-2.1-jetty-1.0.
I'm inclined to go for (A) but see arguments for everything except D.
Thoughts?
I like (C) because you can easily determine everything from the plugin
name and I think that is the most helpful for a user. Yes, it's long
and ugly ... and you could figure out the other versions in other ways
... but it's very helpful. We could eliminate one more character by
compressing g-2.1 to g2.1.
Joe
