ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <Shawn.Castria...@halliburton.com>
Subject RE: Resolver or dependency
Date Fri, 14 Nov 2008 10:45:35 GMT
That is when you combine the power of a chained resolver and the relatively new "force" feature
of a resolver.  You create a local repository resolver in your setting file that has force="true".
 You then create a chained resolver where the first one is the local repository resolver followed
by your main repository resolver.  You create an ANT target called publish.local (or whatever)
that publishes A locally using the local resolver, then when you go to B and do a resolve/retrieve,
the local A is grabbed because of the "force" instead of the published one in the ivy repo.
 Now in this particular example, force="true" is not actually needed.  But you will need it
with a more complex example like:  C->B->A where you are trying to build C with the
published B and a local A.  Without force="true", the A retrieved will be the transitive dependency
of the version of B found in the main repo and not your local A.

---
Shawn Castrianni

-----Original Message-----
From: Viktor Sadovnikov [mailto:vl_sadovnikov@yahoo.com]
Sent: Friday, November 14, 2008 2:24 AM
To: ivy-user@ant.apache.org
Subject: Re: Resolver or dependency

Yes, it works great with CI server. However I am aiming to help developers to test their code
changes in both projects locally.
Changed project A is not published yet (even locally), but developer is executing "ant test"
of project B. Now it fails.


----- Original Message ----
From: Mitch Gitman <mgitman@gmail.com>
To: ivy-user@ant.apache.org
Sent: Thursday, November 13, 2008 3:44:10 PM
Subject: Re: Resolver or dependency

If project B depends on project A, then the only knowledge B has of the
latest version of A is what's in the Ivy repository that the Ivy resolver is
using.

When you get right down to it, the extra functionality you're looking for is
really the work of a continuous integration system. The sequence would go
like this:

   1. You check in changes to project A to source control.
   2. A CI system like Hudson detects the change to A and proceeds to build
   the project itself.
   3. At this end of a successful build, Hudson publishes A.jar (or whatever
   the artifacts are) to the Ivy repository in use.
   4. If you're using something like the Hudson Ivy plugin, then a change to
   project A will trigger a rebuild of its dependent project, B.

By the way, does anyone know the current state of the Hudson Ivy plugin when
it comes to Ivy 2.0?

On Thu, Nov 13, 2008 at 4:49 AM, Viktor Sadovnikov
<vl_sadovnikov@yahoo.com>wrote:

> Hi everyone,
>
> Seems I am either making fundamental mistake in understanding Ivy or
> missing
> something. How should I setup compilation when I have two projects: A and
> B,
> the last one depends on the latest version of A.
> My setup is based on "multi-project" example, which comes
> with Ivy. Code of both projects is changed locally and I want to test
> compilation of B. Both "compile" of B and "compile-all" fail until A is
> published. I would expect something in either "dependencies" of B or
> resolvers
> to tell Ivy that A needs to be rebuild.
>
> Could anyone point me to my mistake?
>
> Thanks a lot,
> Viktor
>
>
>
>





Mime
View raw message