Transient dependency or specified dependency?

[Alex Foreman <Al...@morganstanley.com>]

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

Re: Transient dependency or specified dependency?

[Alex Foreman <Al...@morganstanley.com>]

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 <mg...@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.Foreman@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

Re: Transient dependency or specified dependency?

[Mitch Gitman <mg...@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.Foreman@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
>