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 <[email protected]> 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/
