You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2008/12/10 02:17:27 UTC
Naming conventions for our adapter code and plugins for external projects
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
Re: Naming conventions for our adapter code and plugins for external
projects
Posted by Donald Woods <dw...@apache.org>.
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
>>>
>>>
>>>
>>>
>>
>
>
Re: Naming conventions for our adapter code and plugins for external
projects
Posted by Joe Bohn <jo...@earthlink.net>.
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
>>
>>
>>
>>
>
Re: Naming conventions for our adapter code and plugins for external
projects
Posted by Donald Woods <dw...@apache.org>.
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.
-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
>
>
>
>
Re: Naming conventions for our adapter code and plugins for external
projects
Posted by Donald Woods <dw...@apache.org>.
David Jencks wrote:
>
> 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
>
> ?
If 2.5 webapps work on Jetty7 unmodified, then I'd propose -
artifactId = jetty
version = geronimoVersion
BUT, since we already use artifactId=jetty6, then we should bump it up
to jetty7.
Again, this scenario doesn't work for Tomcat/Jetty, as we already have
the project's major version as part of the artifactId, but for something
like openejb, openjpa, axis, axis2, pluto, activemq, .... where we don't
already have the project's major version number included in the
artifactId, then I wouldn't add it moving forward, unless a major
upgrade required users to change their application code.
>
> 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
>>>
>
>
Re: Naming conventions for our adapter code and plugins for external projects
Posted by David Jencks <da...@yahoo.com>.
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
>>
Re: Naming conventions for our adapter code and plugins for external
projects
Posted by Donald Woods <dw...@apache.org>.
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.
> 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
>
>
>
>