geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Naming conventions for our adapter code and plugins for external projects
Date Wed, 10 Dec 2008 01:17:27 GMT
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