Using ivy to resolve in-build tools

[Benjamin Damm <bd...@silverspringnet.com>]

Hello,

  I'm looking for help with resolving dependencies for tools found in a build 
file but that are not dependencies for the project being built.

  My company has started a strong effort to migrating our builds to 
incorporate ivy mostly for dependency management as part of getting control 
on an otherwise unwieldy collection of build.xmls.  We've made good progress 
but many details remain.

One detail is how to resolve the dependencies of tools that are required in 
the build itself.  We have a build.xml that is included in a number of other 
projects (build-tools.xml) and some in-house tools that are invoked by 
targets in the build-tools.xml.  The jars required for these tools are not 
required by the projects being built but they are required for these targets 
to perform specific actions.

I could refer to the jars statically, as we already do, but part of this 
effort is to move away from doing that.

It seems that what we need is an ivy.xml just for these tools that is separate 
from the ivy.xml of the project that is being compiled.  Any help here?

Thank you,
-Ben

-- 
Benjamin Damm
Silver Spring Networks
650-298-4200 x201

Re: Using ivy to resolve in-build tools

[Niklas Matthies <ml...@nmhq.net>]

On Tue 2008-10-28 at 14:18h, Maarten Coene wrote on ivy-user:
> Ivy itself uses tools like emma and checkstyle in it's own build.xml.
> We don't add them into our ivy.xml file, but we use them directly in our build.xml like this:
> 
>         <ivy:cachepath organisation="checkstyle" module="checkstyle" revision="4.3"
>                 inline="true" conf="default" pathid="checkstyle.classpath" transitive="true" 
>                 log="download-only"/>
>         <taskdef resource="checkstyletask.properties" classpathref="checkstyle.classpath" />
>         <checkstyle ... />

The following just occurred to me: Is the implicit resolution that is
done by ivy:cachepath here performed in its own context, or is it done
as if it was a declared dependency of the "current" module (if there
is such a thing)?

If it is the former, wouldn't this solve Scott Goldstein's problem
with the self-dependent module?

-- Niklas Matthies

Re: Using ivy to resolve in-build tools

[Niklas Matthies <ml...@nmhq.net>]

On Tue 2008-10-28 at 12:08h, Benjamin Damm wrote on ivy-user:
:
>   I'm looking for help with resolving dependencies for tools found in a build 
> file but that are not dependencies for the project being built.
:
> It seems that what we need is an ivy.xml just for these tools that is separate 
> from the ivy.xml of the project that is being compiled.  Any help here?

The usual solution is to use different configurations. See here:

    http://ant.apache.org/ivy/history/trunk/terminology.html#configurations
    http://ant.apache.org/ivy/history/trunk/concept.html
    http://ant.apache.org/ivy/history/trunk/tutorial/conf.html
    http://ant.apache.org/ivy/history/trunk/ivyfile/configurations.html

In addition, you might want to turn the shared build-tools.xml into a
module of its own, so that its tool jar dependencies can be maintained
in one place, as dependencies of this new "build-tools" module. Then
the individual project modules can simply depend on the build-tools
module in their private "build" configuratione. If not all projects
use all tools, again you can use configurations, this time on the
build-tools module, to define different tool sets.

-- Niklas Matthies