You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Holly Cummins <ho...@googlemail.com> on 2011/11/17 17:05:13 UTC
Bundle versions in sample assemblies
Hi all,
I've just raised (and fixed) ARIES-784, a problem with the pax.logging
versions in the sample assemblies. I also raised
https://issues.apache.org/jira/browse/ARIES-785 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 dependencies.properties 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: http://www.manning.com/cummins/
Re: Bundle versions in sample assemblies
Posted by Jeremy Hughes <hu...@apache.org>.
On 19 November 2011 10:44, Holly Cummins <ho...@googlemail.com> 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 depencies.properties, 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 <da...@yahoo.com> 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
>>> https://issues.apache.org/jira/browse/ARIES-785 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 dependencies.properties 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:
>>> http://www.manning.com/cummins/
>>
>
Re: Bundle versions in sample assemblies
Posted by Holly Cummins <ho...@googlemail.com>.
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 depencies.properties, or persuade pax to run from the
config.ini file.
On 17 Nov 2011, at 17:09, David Jencks <da...@yahoo.com> 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
>> https://issues.apache.org/jira/browse/ARIES-785 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 dependencies.properties 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: http://www.manning.com/cummins/
>
Re: Bundle versions in sample assemblies
Posted by David Jencks <da...@yahoo.com>.
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
> https://issues.apache.org/jira/browse/ARIES-785 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 dependencies.properties 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: http://www.manning.com/cummins/