geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
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 -
   From:
     org.apache.geronimo.modules.geronimo-activemq-ra/2.0/car
     org.apache.geronimo.modules.geronimo-activemq-ra/2.0.1/car
     org.apache.geronimo.modules.geronimo-activemq-ra/2.0.2/car
     org.apache.geronimo.modules.geronimo-activemq-ra/2.1/car
     org.apache.geronimo.modules.geronimo-activemq-ra/2.1.1/car
     org.apache.geronimo.modules.geronimo-activemq-ra/2.1.2/car
     org.apache.geronimo.modules.geronimo-activemq-ra/2.1.3/car
   To:
     org.apache.geronimo.modules.geronimo-activemq5-ra//car

But, as soon as we release 2.1.4, we'd have to update the 2.2.x branch 
with another mapping for -
   From:
     org.apache.geronimo.modules.geronimo-activemq-ra/2.1.4/car

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)?


-Donald



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 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
>>>
>>>  
>>>  
>>>
>>
> 
> 

Mime
View raw message