aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <>
Subject Re: Bundle versions in sample assemblies
Date Tue, 22 Nov 2011 14:15:46 GMT
On 19 November 2011 10:44, Holly Cummins <> wrote:
> Thanks for the confirmation it wasn't a totally silly plan, David. Your
> reading of my suggestion was exactly right. :)
>  I was about to go off and make the changes when I realised consolidating
> the versions would only catch the case when we change a dependency's
> version, not when we add a new one. So we could still easily end up breaking
> the samples and not noticing. I think the solutions are to generate the
> whole bundle list part of the config.ini from the, or
> persuade pax to run from the config.ini file.

I think having one place with all the dependencies with versions would
be ideal. I can't help thinking there's a better way of using the
various pax projects. For instance it looks like pax runner can take a
Maven pom file as input.

> On 17 Nov 2011, at 17:09, David Jencks <> wrote:
>> 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.
>> thanks
>> 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