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 15:04:09 GMT
I agree that we could use artifact alias to solve some of the problems, 
but how do we track/manage which artifact aliases are required?

Wouldn't this be a time consuming and error prone task, given we'd have 
to add entries in every new release for all prior releases, like:
Geronimo 2.2 -

But, as soon as we release 2.1.4, we'd have to update the 2.2.x branch 
with another mapping for -

Would we say applications are only guaranteed to be deployable within a 
given major release (2.x) but not on a future major release (like 3.0)?


Joe Bohn wrote:
> Donald Woods wrote:
>> 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.
> I agree with both goals and particularly this second goal.  Can't we 
> just use the artifact alias as a way to manage the compatibility issues 
> until we have a better solution?  Including the major version in the 
> name as David recommends and adding an artifact alias entry when the new 
> component should be compatible with the old seems to achieve both goals.
> We would not include the alias entry in the event that the newer 
> component is incompatible with the older one.   The deploy failure a 
> user would see if they failed to update their deployment plan would 
> perhaps be a good way to alter them to the fact that some changes are 
> necessary if they had not yet prepared for them.
> Joe
>> -Donald
>> 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