Hey Mitch. Thanks for the reply. A bit more background. We have an enterprise repository which we release to a readonly filesystem. All ivy files in this repo have non-dynamic Major.Minor.Patch releases specified for F/OSS projects.
We also have the concept of a Bundle where we specify all the org/module releases that that bundle was built and tested against. These are in a propertyfile which our build knows about. Each build specifies a bundle version and we use a dynamic version matcher called 'default' which loads these values. E.g. if revision="default" then match the version the bundle property file for that org/module from the property list. The problem we get is when we move bundle versions. Eg. BundleVersion 1.0 constains these properties: junit.junit.version=4.7.0 hamcrest.hamcrest=1.1.0 And BundleVersion 1.1 contains these properties; junit.junit.version=4.7.0 hamcrest.hamcrest=1.2.0 If someone goes from 1.0 to 1.1 and _only_ asks for junit in its ivy file then the hamcrest version is picked up as a transitive dependency from the junit ivy file which will be 1.1.0. However we want this to pick up the latest bundle version if it is later. So if you specify a dependency and it has transitive dependencies then if they are not specified in the ivy file we want to pick up the default value from the bundle file in this case 1.2.0 of hamcrest which is later than the one which junit 4.7.0 originally got released with. So in our default version matcher we need to have some logic that can work out if the dependency was specified in the projects ivy file, in which case we would use that. However if it was Gathered transitively then check to see if the default version is later and if so use that. Does that explain my problem better? This way people upgrading from bundle to bundle only need to care about the bundle version and not every single dependency as we guarentee that all the default values for a bundle were tested and built together. I hope there is a way of checking this. :) Many thanks, 2010/1/18 Mitch Gitman <mgit...@gmail.com>: > Alex, it sounds like you're getting JUnit 4.7 from a public repository and > on that public repo JUnit 4.7 depends on the 1.1 version of Hamcrest > matchers. > > If you always want to get Hamcrest 1.2, one thing you can do is specify an > override as a sibling of the JUnit dependency: > http://ant.apache.org/ivy/history/latest-milestone/ivyfile/override.html > > On Mon, Jan 18, 2010 at 9:02 AM, Alex Foreman < > alexander.fore...@morganstanley.com> wrote: > >> Hi, >> Imagine this scenario. >> >> I have Junit 4.7.0 which depends on Hamcrest 1.1.0. >> I specify the two numbers in properties in a file which can be updated. >> >> If i specify Both dependencies then I get the new version if the file >> is update to Hamcrest 1.2.0. >> >> If i only specify Junit in my ivy.xml then when the file updates I >> will still pickup the 1.1.0 dependency not the later 1.2.0 release as >> it is found via the junit ivy file. >> >> In my version matcher is there any meta data that I can use to >> discover if the module asked for was brought in transitively or if it >> was directly specified? If there is then I can use this to make sure >> that any non-specifed transitive dependencies can be forced to later >> revisions automatically. >> >> Thanks, >> >> -- >> Alex Foreman >> > -- Alex Foreman
