ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: External vs. Internal dependencies
Date Sun, 09 Sep 2012 01:30:19 GMT
If A and B and C are all their own Ivy modules with their own ivy.xml
files, then you should look into using the ivy:buildlist Ant task to do the
parent multimodule build. However, even then, you're letting the parent
build build everything unless you state otherwise. Since you're building
from source, you know whether A has changed, so you can tell buildlist to
skip it. See the root and leaf attributes; I always forget which is which.

There are a couple statements of yours that strike me funny.

First: "The reason I'm trying to avoid or at least cut down the situation
where I run an ivy:resolve is due to the amount of time it takes.  If I
have a module with 35 dependencies, it can take over 1 minute in some cases
where the full module build and test time may only be 2 mins."

If the ivy:resolve is taking so long, it sounds like you're not caching
dependencies when you should be.

Second: "As the build process would be run from the top level, as B runs
there very well may have been a rebuild of the A artifact that was pushed
to the local cache on the dev's machine.  So this is where ivy:resolve is
required, it will check if this is the case."

The rebuild of the A artifact should not be pushing to the local cache; it
should be publishing to a local repository (not to be confused with the
cache) on the dev's machine. Because A is something that is constantly
changing, the resolve on B should get A, but it should skip those
transitive dependencies of A that are not changing.

This will have to be it for me on this thread.

On Fri, Sep 7, 2012 at 6:25 AM, wellgoonthen <richcoleuk@googlemail.com>wrote:

>
> Hi Mitch,
>
> Thanks for your response and apologies if my terminology was not accurate.
> Based on your comments I'll try to explain the issue again.  When I talk
> about A, B and C, these are all modules of the same project with a root
> level build.xml calling module level builds + ivy.xml, where A depends on B
> and C can depend on A, B or in fact both.  A, B and C are what I mean by
> internal in the sense I own the code etc.
>
> If I look at the ivy file of B, I may see (pseudo code for sake of the
> email):
>
>  depends on junit
>  depends on log4j
>  depends on A
>
> Based on the simple uptodate logic that can be used from ant I can easily
> remove the need to call ivy:resolve for junit and log4j by checking the
> ivy.xml file for module B.  If it's not newer, I know that someone hasn't
> changed the version of junit etc.
>
> As the build process would be run from the top level, as B runs there very
> well may have been a rebuild of the A artifact that was pushed to the local
> cache on the dev's machine.  So this is where ivy:resolve is required, it
> will check if this is the case.
>
> The reason I'm trying to avoid or at least cut down the situation where I
> run an ivy:resolve is due to the amount of time it takes.  If I have a
> module with 35 dependencies, it can take over 1 minute in some cases where
> the full module build and test time may only be 2 mins.
>
> I hope that's a bit clearer and the purpose of this is really to focus on
> local dev builds speed those up.  I'm not really targeting this from a CI
> build perspective, although I imagine that if I fix the local issue, the CI
> build will also benefit from the same kind of changes.
>
> Richard
>
>

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