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: Newbie Setup open for review
Date Tue, 16 Nov 2010 17:11:57 GMT
I would recommend using ivy:cachepath over ivy:retrieve. With retrieve,
you're doing an extra copy of the dependencies, which leaves you vulnerable
to the files getting out of sync. Without seeing your Ivy settings, I can't
say why things are slower on cachepath or retrieve. If I understand
correctly, you're encountering this 11-second cost every time you do a
compile. If that's the case, it would mean that Ivy is not trusting your
cache at all and forcing a download every time. Just for sanity's sake, you
might want to look in the default cache location, .ivy2/cache under your
user home, and check if the files are indeed being downloaded and if they're
being downloaded every time.

I'm sure someone out there might be able to identify what this is a symptom
of.

Regarding your other question, I would say it's generally regarded as a bad
practice to place your confs and dependencies for the build in the same
ivy.xml as the confs and dependencies for the current project. What you'll
find is that the confs for the build almost never change across projects
while the project confs do change. Even if you use standard project confs
(core, compile, etc.), you'll find that the build dependencies never change
from project to project while the project-proper dependencies do.

The two alternatives I've seen out there to putting build dependencies in
the ivy.xml are:
* Give the build its own ivy.xml.
* Define each build dependency inline in the ivy:resolve as it's needed. Do
inline="true".

On Tue, Nov 16, 2010 at 4:45 AM, <neurolabs.de@gmail.com> wrote:

> Hi,
>
> we are using ivy in our project. Now I want to see if I understood the
> concepts correctly and am using it as designed.
>
> First I had it set up so that all libs used were provided by cachepath
> calls. That lead to a lot of ant output and a minimal compile turnaround
> of 11 seconds.
>
> Now I am using a retrieve target that only gets triggered on changes to
> the ivy.xml file. This is way fast, compile turnaround is down to 4
> seconds. The downside is that dynamic revisions will not be picked up
> automatically until you explicitly run the clean target.
>
> In a perfect world I would like a fast build with dynamic revisions. Is
> this possible?
>
> Can anything else be improved with this setup?
>
>
>
> Another question: libs that we use for ant targets only are organized in
> confs. Is this the way it's supposed to be? This is an excerpt from our
> ivy.xml:
>
>    <configurations>
>
>        <conf name="ant-checkstyle" visibility="private"
> description="Abhängigkeiten für ant checkstyle task"/>
>        <conf name="ant-cobertura" visibility="private"
> description="Abhängigkeiten für ant cobertura tasks"/>
>        [....]
>
>        <conf name="core" visibility="private" description="Generelle
> Abhängigkeiten der Software"/>
>        <conf name="compile" extends="core" visibility="private"
> description="Compilezeit-Abhängigkeiten der Software"/>
>        <conf name="runtime" extends="core"
> description="Laufzeit-Abhängigkeiten der Software"/>
>        <conf name="test-runtime" extends="runtime" visibility="private"
> description="Abhängigkeiten für Tests der Software"/>
>        <conf name="test-compile" extends="compile" visibility="private"
> description="Abhängigkeiten für Tests der Software"/>
>
>    </configurations>
>
>    <dependencies>
>
>        <dependency org="com.puppycrawl.tools" name="checkstyle" rev="5.3"
> conf="ant-checkstyle->default"/>
>        <dependency org="cobertura" name="cobertura" rev="1.9.4.1"
> conf="ant-cobertura->default"/>
>
>        <!-- core -->
>        <dependency org="org.hibernate" name="hibernate-core"
> rev="3.6.0.Final" conf="core->default"/>
>        [....]
>
>    </dependencies>
>
> Regards,
>
> Ole
>

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