ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fernandes, Gerard" <gerard.fernan...@lehman.com>
Subject RE: Ivy:retrieve not picking up new jars
Date Mon, 16 Jun 2008 14:37:08 GMT
I think your problem arises because of the following:

Module-A <depends on> Module-B <depends on> Module C

Now you've changed Module C and rebuilt it and published it to the Ivy
repo.

Following this, you'd expect Module-A to pull in the latest Module-C.
But in reality, Module-A depends on Module-B which has not changed. So
at this point, Ivy decides against fetching "new" stuff from the Ivy
repo and instead uses old stuff from your local cache.

IMO, you'd have to build and publish Module-B as well. And even then,
you'll have to set up Ivy so that it always checks for new versions in
the repository - I think there's a way to make it check by artefact
time-stamp.



-----Original Message-----
From: Dave [mailto:davidcorley@gmail.com] 
Sent: 16 June 2008 15:30
To: ivy-user@ant.apache.org
Subject: Re: Ivy:retrieve not picking up new jars

I'll work around the issue using one of your suggested methods. I can't
understand why I'm able to recursively resolve everything when nothing
is in the cache, but once a revision is in the cache, a dependency on a
newer revision cannot be resolved. It's counter-intuitive (as you say)
and unexpected behaviour surely?
i.e., the first time I resolved Module A, it got everything I needed
down through the dependency tree.
However, once that first resolve is carried out, there's no way to allow
for the fact that a dependency of a dependency will change revision?
Surely that's an Ivy bug?


On Mon, Jun 16, 2008 at 3:01 PM, Colin Fleming
<colin.mailinglist@gmail.com>
wrote:

> Unfortunately, yes - as far as I know there's no way to recursively 
> resolve all dependent modules. This is something I've always found 
> pretty confusing - sometimes it seems counterintuitive. Check out the 
> buildlist task - it will run an action for a list of modules in 
> dependency order, and thus you're guaranteed to always have your 
> dependencies resolved.
>
> Cheers,
> Colin
>
> 2008/6/16 Dave <davidcorley@gmail.com>:
> > I resolved Module A with the refresh attribute set to true.
> > I though this would transitively resolve Module B? Am I wrong?
> >
> > On Mon, Jun 16, 2008 at 2:36 PM, Colin Fleming <
> colin.mailinglist@gmail.com>
> > wrote:
> >
> >> Hey Dave,
> >>
> >> Have you resolved module B after updating its dependencies? 
> >> Resolution will place the resolved ivy file with the updated 
> >> dependencies in the cache, and then module A should pick it up.
> >>
> >> Cheers,
> >> Colin
> >>
> >> 2008/6/16 Dave <davidcorley@gmail.com>:
> >> > Hey all,
> >> > I've got 3 modules which are interdependent Module A depends on 
> >> > Module B which in turn depends on Module C
> revision
> >> N.
> >> >
> >> > I updated Module B's ivy.xml to depend on a newer version of 
> >> > Module C,
> >> but
> >> > the <ivy:retrieve> command keeps using revision N instead of N+1.
> >> > How can I tell Ivy to re-resolve the dependency revisions every 
> >> > time I
> >> call
> >> > a retrieve?
> >> >
> >> > If you need any more info, let me know.
> >> >
> >> >
> >> > Regards,
> >> > Dave
> >> >
> >> > --
> >> > There are 10 types of people in the world.
> >> > Those who understand binary and those who do not.
> >> >
> >>
> >
> >
> >
> > --
> > There are 10 types of people in the world.
> > Those who understand binary and those who do not.
> >
>



--
There are 10 types of people in the world.
Those who understand binary and those who do not.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This message is intended only for the personal and confidential use of the designated recipient(s)
named above.  If you are not the intended recipient of this message you are hereby notified
that any review, dissemination, distribution or copying of this message is strictly prohibited.
 This communication is for information purposes only and should not be regarded as an offer
to sell or as a solicitation of an offer to buy any financial product, an official confirmation
of any transaction, or as an official statement of Lehman Brothers.  Email transmission cannot
be guaranteed to be secure or error-free.  Therefore, we do not represent that this information
is complete or accurate and it should not be relied upon as such.  All information is subject
to change without notice.


Mime
View raw message