aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Bundle versions in sample assemblies
Date Thu, 17 Nov 2011 17:09:06 GMT
IIUC your idea is to change the parent pom(s) so that the dependencies configured there are
configured with versions defined by properties rather than directly in the dependency/version
element.  Then there's no need to define these properties in samples.

I _think_ this would be OK.  One side effect IIUC is that if some project does redefine the
property value then that redefined version of the dependency will get used in that project.
 I think this might be an easier problem to avoid than the current duplicated information
problem you have run into.

not sure if this is any clearer than what you said :-)  anyway I think what you are proposing
ought to work.

david jencks

On Nov 17, 2011, at 8:05 AM, Holly Cummins wrote:

> Hi all,
> I've just raised (and fixed) ARIES-784, a problem with the pax.logging
> versions in the sample assemblies. I also raised
> to cover the more
> general issue that our blog tests were happily passing while the blog
> sample itself was totally broken. However, I haven't fixed ARIES-785
> yet, because it's harder. :)
> I've had a quick look and I think the root of the problem is that the
> blog assembly uses version numbers set as explicit properties in the
> samples pom.xml:
>    <!-- External Dependencies -->
>         <cmVersion>3.2.0-v20070116</cmVersion>
>         <servicesVersion>3.1.200-v20070605</servicesVersion>
>         <asmVersion>3.2</asmVersion>
>         <paxLoggingApiVersion>1.4.0</paxLoggingApiVersion>
> <---------------------- These numbers were wrong
>         <paxLoggingServiceVersion>1.4.0</paxLoggingServiceVersion>  <----/
> whereas the version used in the for the itests
> comes from parent/default-parent/pom.xml:
>             <dependency>
>                 <groupId>org.ops4j.pax.logging</groupId>
>                 <artifactId>pax-logging-api</artifactId>
>                 <version>1.5.0</version>
> <-------------------------------------------------------- This number
> is the number we wanted
>             </dependency>
> The solution which springs to mind is to move all the version
> declarations from the samples pom.xml to the parent pom.xml so that
> they can be common across the whole project. However, this kind of
> radical innovation is far beyond my (feeble) maven skills, so I'm not
> sure if it's a logical idea or a terrible one. Does anyone with a
> better understanding of our build have any opinions?
> Holly
> ------------
> Want to learn more? Enterprise OSGi in Action:

View raw message