ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Problems with ivy:install
Date Wed, 29 Aug 2007 14:09:04 GMT
On 8/29/07, Andy Piper <> wrote:
> At 13:38 29/08/2007, Xavier Hanin wrote:
> >I think there's a problem of vocabulary. In Ivy terminology, you always
> >install from a repository *to* another one. Here you're talking about
> >installing from A and B. But to which repository?
> >
> >1. Without ivy:retrieve, nothing from B gets installed.
> >
> >
> >If install means copied from one repo to another, this is possible to do
> >with the install task. But you need to specify a chain of A and B as
> source
> >and another repo as destination.
> This is exactly what I have. A chain of A and B, but still nothing
> gets installed from B to my taregt. I am trying to install to shared
> (if it matters).

It should work if you have the module and its dependencies in your chain,
and specify the chain as source repo, Ivy should be able to install your
module and dependencies into your target repo.

>2. With ivy:retrieve everything gets installed from both A and B (but
> > > A is the repo I specified in the install task)
> >
> >Retrieve is used to copy artifacts to a loca destination (which can later
> be
> >used as a repository, but it's unknown by Ivy at the moment of the
> retrieve
> >call).
> ? I think this is my point. I understand what ivy:retrieve does, I
> don't understand why it has _any affect at all_ on what ivy:install
> does. The two are not conceptually related and yet clearly, based on
> my experiments, there are side effects of one to the other.

There shouldn't be too much side effects between the two except that the two
download files to your cache at one moment so if you use the same cache for
both operations, it will speed up the second one. It may even make the
second one work while without it wouldn't if a module is made available in
your cache by the first while it isn't accessible for the second operation.

>3. If I specify B as the repo in the install task then the build
> > > fails and nothing is installed.
> >
> >
> >Maybe it's because is lacking information about where to find information
> >about your modules, because B is not enough. The install task is very
> >similar to an inline resolve using only one repository, followed by a
> >publish of bunch of modules. If the resolve with only one repository does
> >not work, the install won't work.
> So you are saying that it should work, assuming my repositories and
> specification are correct?

Yes !

>For consistency I would expect either:
> > >
> > > a. For (2) only transitive modules in A to be installed
> > >
> > > or
> > >
> > > b. (3) to succeed and the source repo to be ignored when transitive
> > > is set to true.
> > >
> > > But, for the record, I don't want (a), I want (b). (2) is close
> > > enough, except that I would expect there to be an implicit retrieve.
> >
> >
> >I think you're confusing what install and retrieve are meant for. I don't
> >say they're obvious, but I think that by combining the resolve, retrieve
> and
> >install tasks you have a pretty flexible set of tools, with which you
> should
> I agree, but what is their relationship? I cannot find any
> documentation on how retrieve affects install. I think if I
> understood that then all would become clear.

They affect each other because they use the same cache. If you use a
different cache for each, they shouldn't  have any side effects (except that
install make some modules available in one repo that may then be used by



>be able to do what you want. Maybe if you explained what you want to do, we
> >could help by explaining which tasks are better suited?
> andy
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and
> have received this message in error, please immediately return this by email
> and then delete it.

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message