You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Jan Vissers <Ja...@cumquat.nl> on 2008/03/06 16:26:22 UTC

Problem with resolve (ivy.deps.changed) and timestamp of ivy.xml

Wondering anyone has seen this before.

I use ANT to process a built via subant that calls dependent project in
the right order. This looks a bit like this:


  start built 'reusable library'
              => code has changed, so
              => eventually a publish call is done to the local repository,
                 this is done in order for the dependent project to pick up
                 the changed artifact.

  start built 'higher level project'
              => call 'resolve', so by using ivy.deps.changed
              => we call 'retrieve' conditionally, and
                 this way create updated version of the higher level artifact

This isn't working however ... ivy.deps.changed is always false.

First question: when is ivy.deps.changed?
Only when there are actually new dependencies declared or existing ones
removed, or whenever the 'ivy.xml' timestamp has been changed. i.e. what's
in the cache is older that what's in the repository?

Second question: why is it that after the publication to local repository
of the 'reusable library' all files have a new timestamp (.jar, .md5, ...)
that is all *but ivy.xml* which keeps its 'old' timestamp. If resolve is
checking the timestamp of the ivy.xml in the local repository I can
imagine why ivy.deps.changed remains at false.

Hope somebody has an idea?

-J.


Re: Problem with resolve (ivy.deps.changed) and timestamp of ivy.xml

Posted by Jan Vissers <Ja...@cumquat.nl>.
Just to inform you when ivy.xml timestamp is changed as a result of 
'forcedeliver=true' this doesn't mean that performing
ivy:resolve will set ivy.deps.changed to true. So apparently I'm 
misinterpreting ivy.deps.changed - it isn't set to true when the 
timestamp of the ivy.xml is changed (as a result of a changed jar artifact).

I will try to get around this issue by introducing my own 'uptodate' check.

-J.

Jan Vissers wrote:
> The ivy.xml in my local repository only gets updated when I add
>
> forcedeliver="true"
>
> to the publish task. I would have though that setting 'changing=true' 
> would have picked up changes of the .jar artefact and update the 
> ivy.xml accordingly.
> Again w/o forcedeliver="true" I'm seeing .jar gets updates as well as 
> the .md5/.sha1 file for that jar, but also the .md5/.sha1 file for the 
> ivy.xml - but not ivy.xml itself.
>
> I think this is a bug in Ivy.
> -J
>
> Jan Vissers wrote:
>> Wondering anyone has seen this before.
>>
>> I use ANT to process a built via subant that calls dependent project in
>> the right order. This looks a bit like this:
>>
>>
>>   start built 'reusable library'
>>               => code has changed, so
>>               => eventually a publish call is done to the local 
>> repository,
>>                  this is done in order for the dependent project to 
>> pick up
>>                  the changed artifact.
>>
>>   start built 'higher level project'
>>               => call 'resolve', so by using ivy.deps.changed
>>               => we call 'retrieve' conditionally, and
>>                  this way create updated version of the higher level 
>> artifact
>>
>> This isn't working however ... ivy.deps.changed is always false.
>>
>> First question: when is ivy.deps.changed?
>> Only when there are actually new dependencies declared or existing ones
>> removed, or whenever the 'ivy.xml' timestamp has been changed. i.e. 
>> what's
>> in the cache is older that what's in the repository?
>>
>> Second question: why is it that after the publication to local 
>> repository
>> of the 'reusable library' all files have a new timestamp (.jar, .md5, 
>> ...)
>> that is all *but ivy.xml* which keeps its 'old' timestamp. If resolve is
>> checking the timestamp of the ivy.xml in the local repository I can
>> imagine why ivy.deps.changed remains at false.
>>
>> Hope somebody has an idea?
>>
>> -J.
>>
>>
>>
>>
>>   
>


Re: Problem with resolve (ivy.deps.changed) and timestamp of ivy.xml

Posted by Jan Vissers <Ja...@cumquat.nl>.
The ivy.xml in my local repository only gets updated when I add

forcedeliver="true"

to the publish task. I would have though that setting 'changing=true' 
would have picked up changes of the .jar artefact and update the ivy.xml 
accordingly.
Again w/o forcedeliver="true" I'm seeing .jar gets updates as well as 
the .md5/.sha1 file for that jar, but also the .md5/.sha1 file for the 
ivy.xml - but not ivy.xml itself.

I think this is a bug in Ivy.
-J

Jan Vissers wrote:
> Wondering anyone has seen this before.
>
> I use ANT to process a built via subant that calls dependent project in
> the right order. This looks a bit like this:
>
>
>   start built 'reusable library'
>               => code has changed, so
>               => eventually a publish call is done to the local repository,
>                  this is done in order for the dependent project to pick up
>                  the changed artifact.
>
>   start built 'higher level project'
>               => call 'resolve', so by using ivy.deps.changed
>               => we call 'retrieve' conditionally, and
>                  this way create updated version of the higher level artifact
>
> This isn't working however ... ivy.deps.changed is always false.
>
> First question: when is ivy.deps.changed?
> Only when there are actually new dependencies declared or existing ones
> removed, or whenever the 'ivy.xml' timestamp has been changed. i.e. what's
> in the cache is older that what's in the repository?
>
> Second question: why is it that after the publication to local repository
> of the 'reusable library' all files have a new timestamp (.jar, .md5, ...)
> that is all *but ivy.xml* which keeps its 'old' timestamp. If resolve is
> checking the timestamp of the ivy.xml in the local repository I can
> imagine why ivy.deps.changed remains at false.
>
> Hope somebody has an idea?
>
> -J.
>
>
>
>
>   

-- 
Cumquat Information Technology
De Dreef 19
3706 BR Zeist
T +31 (0)30 - 6940490
F +31 (0)30 - 6940499
W http://www.cumquat.nl

E Jan.Vissers@cumquat.nl
M +31 6 51 169 556
B http://www.cumquat.nl/technology_atom10.xml