ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: External vs. Internal dependencies
Date Fri, 07 Sep 2012 02:08:30 GMT
Your question is a bit ambiguous, so let me not so much answer it as make
two points to get the terminology and concepts straight.

When you talk about skipping the resolution of the external artifacts, what
you really should be saying is that you're still doing an ivy:resolve, just
you're trusting the modules in the Ivy cache are up-to-date and Ivy doesn't
have to check the remote repository again. This is the default behavior,
and the natural behavior for external libraries and released versions of
internal libraries.

For internal libraries still under development, you want to override this
so that Ivy always checks the repo. Typically, this is done on the resolver
in ivysettings.xml, and I can think of three criteria you can pass to the
resolver to say that it's an "integration" version:

   - The publication status in the ivy.xml is "integration" or something
   - There's a special suffix in the version, like -SNAPSHOT or a
   buildnumber or timestamp.
   - The modules are in a special integration repository directory.

It's not a bad idea to do all three in combination, although any one will
do. See:

When you talk about using Ivy resolve to tell if A has been rebuilt
triggering a new build of B, you're applying concepts that apply not to a
dependency manager like Ivy but rather to a continuous integration server
like Jenkins. Forgive me if I'm stating something you're already well aware
of, but the way that a change in A triggers a build of B is to have the CI
server monitor for check-ins to the different projects. If someone commits
a change to A, it triggers a build of A, and if that build is succeeding, a
new version of the A artifact gets published to the repository. From here,
the CI server should be configured (whether manually or through an Ivy
integration) to have a successful build of A trigger a build of B. From
here, B is assured to get the latest A that was just published.

Your question implies CI builds as opposed to developer builds, since the
developer knows what projects they've changed or have incoming changes from
source control.

On Thu, Sep 6, 2012 at 4:12 AM, wellgoonthen <>wrote:

> Hi,
> I'm currently doing some build doctor work on our system build.  I've done
> quite a lot of work to implement a java incremental set up using uptodate
> etc.  This is great and saves a lot of time/work.  The biggest issue is now
> the ivy resolution.  To summarise we have two types dependencies that I
> call:
> - External - junit, log4j etc.
> - Internal - intra build module artifacts
> Now I can easily skip the resolution of the external artifacts by checking
> the "uptodateness" of the modules ivy.xml file to see if the version of
> junit has been changed, or a new 3rd party lib added to that module.  The
> issue I have is with the internal dependencies.
> For example if my build consists of modules A -> B -> C, built in that
> order.  I currently have to rely on ivy resolve to know if A's artifact has
> been rebuilt which would therefore trigger a rebuild of B.
> To summarise I'm using ivy:resolve to do this and for one module that takes
> a total of 11 seconds, 8 seconds is spent resolving stuff.
> Does anyone have any ideas on this?
> Many thanks
> Richard Cole
> --
> View this message in context:
> Sent from the ivy-user mailing list archive at

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