geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: Naming conventions for our adapter code and plugins for external projects
Date Wed, 10 Dec 2008 13:37:37 GMT
I guess the ral problem, is that we have two competing goals:

1) Custom Server Assemblies via car-maven-plugin - To provide multiple 
levels of modules/plugins to allow users to choose the level of 
components hey need, like Jetty6 vs. Jetty7.  This is sort of what 
ServiceMix allows, by starting with the SMX4 Kernel and adding which 
features or individual OSGi plugins you want.  It would be a great goal 
to finally implement in Geronimo 3.0, so users could choose between JEE5 
and JEE6 components.

2) Preserving application compatibility on newer servers - If a user has 
an app working on Geronimo 2.0.x or 2.1.x, then we shouldn't require 
them to modify the app (source or plans) for it to work on future releases.

Scenario #2 is the one I'm trying to preserve, as users expect this of us.


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.
> 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.
> 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?
> 2.b should the version numbering relate to the external project 
> integration or to the geronimo version it fits with?
> 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 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 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

View raw message