On Dec 9, 2008, at 5:36 PM, Donald Woods wrote:
In-line below.
David Jencks wrote:
Both Donald and I seem to feel the answer to this is obvious but we
have diametrically opposed points of view so maybe its time for
discussion.
After endless discussion we answered a related question for our
specs with the following principal:
The artifactId will contain the version number of the spec
The version will only contain the geronimo version.
I'm happy with this decision for specs.
We include a lot of other projects in geronimo, such as activemq,
axis, cxf, jetty, tomcat, etc etc. These projects evolve over the
years and when they get to a fairly incompatible change level they
generally change the major version number, such as jetty 6 to jetty
7, activemq 4 to activemq 5, etc etc.
1. Do we want to give our users a clue about which version of the
external project they are using? If so, it has to be in the maven
id for our plugin that, through dependencies, installs the external
project.
Depends. If existing user apps need to be migrated, then YES.
Otherwise, no.
For example, if a 2.4 webapp that worked on Tomcat v5.5 still works
as-is on Tomcat 6.0, then we shouldn't force users to update their
plans just because our modules/configs have a project dependent
version in it.
2. If so, how? We get groupId, artifactId, version. I don't see a
plausible way to use the groupId, leaving us with artifactId and
version.
If the newer project is not compatible with the previous, then we
should use an updated artifactId.
2.a. If so, how much detail? E.g. do we want to tell users they
are getting some flavor of jetty 6 or do we want to tell them they
are getting jetty 6.1.14?
Just the major version number, which would be jetty6 in your example.
Otherwise, as we pickup new Tomcat 6.0.x and Jetty 6.1.x levels due
to bug or security fixes, we would be breaking existing user apps
within a Geronimo maintenance stream.
2.b should the version numbering relate to the external project
integration or to the geronimo version it fits with?
External project.
So if I understand you correctly, as an example, the jetty 7
integration for geronimo 3.0 should be:
groupId: o.a.g.configs
artifactId: jetty
version: 7.3.0
type: car
?
thanks
david jencks
My answers to these questions:
(1) definitely YES. We may want to offer support for more than one
level of the external project, and I don't think concealing major
changes in an external code base is a good idea.
(2)
- Putting the first digit of the external version in the artifact
Id clearly indicates the general level of external project support
while allowing easy upgrades to later external versions within that
major version. These are likely to be fairly compatible so may work
find with artifact-aliases support rather than recompiling. This
also clearly separates the geronimo portion of the version from the
external project version since the external project version is not
part of the maven version.
- Changing major version of an external project may well require
changes in code that uses the project. It's almost certain to
require repackaging of plugins that run against the project; e.g.
the jetty gbean wrappers changed dramatically from jetty 5 to 6 and
are changing again from 6 to 7.
- using the external project version would result in something like
a version of 5.2.2.2-SNAPSHOT for our current amq 5 integration.
However, there are some bugs so we'll need amq 5.3 or at least
5.2.1 before we release. So we'll need 5.3.2.2-SNAPSHOT even
though our integration code didn't change. I guess we could use
5.2.2-SNAPSHOT although this seems very confusing compared to the
amq version.
So I'm having a lot of trouble seeing how any scheme other than
stuff like activemq5 for the artifactId is remotely plausible.
Thoughts?
david jencks
