On 19 November 2011 10:44, Holly Cummins <[email protected]> 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 <[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/ >> >
