geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Naming conventions for our adapter code and plugins for external projects
Date Wed, 10 Dec 2008 02:16:49 GMT

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


Mime
View raw message