You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by marcdb <md...@gmail.com> on 2010/03/10 15:26:38 UTC
Use ivy-dependencies to create ant-tasks
Hello,
We are using an ant-task called wsimport to create java-classes from xml.
This wsimport task is defined as follows in our build-file:
<taskdef name="wsimport" classname="com.sun.tools.ws.ant.WsImport">
<classpath refid="jaxws.classpath"/>
</taskdef>
Where classpath points to the appropriate jaxb and jaxws jars which are
checked-in in our version control system.
To control the version of jaxb and jaxws jars that we are using for making
our builds, we were thinking about using the ivy-dependency mechanism: via
an ivy.xml file for the build-system, the appropriate versions of these jars
would be retrieved, which could then be used in the classpath when making
the taskdef.
Has somebody already done this or knows a better solution to manage the
versions of the jars that are used in taskdefs of build.xml files.
Thanks,
Marc
--
View this message in context: http://old.nabble.com/Use-ivy-dependencies-to-create-ant-tasks-tp27850372p27850372.html
Sent from the ivy-user mailing list archive at Nabble.com.
Re: Use ivy-dependencies to create ant-tasks
Posted by marcdb <md...@gmail.com>.
Mitch, Maarten,
These are indeed interesting ideas. For what I want to do now, I think the
best choice will be what Mitch suggested by creating build-configurations in
an ivy.xml file.
The reason why I prefer not to resolve inline, is that I would like to
separate the build-logic from the version (revision) control. So I would
like to control the version of my jaxws and jaxb jars via the ivy.xml file,
and the build-logic via my build.xml file.
Thanks,
Marc
--
View this message in context: http://old.nabble.com/Use-ivy-dependencies-to-create-ant-tasks-tp27850372p27860296.html
Sent from the ivy-user mailing list archive at Nabble.com.
Re: Use ivy-dependencies to create ant-tasks
Posted by Mitch Gitman <mg...@gmail.com>.
Maarten, great point. The wonderful thing about Ivy as a framework is that
it is accommodating of so many different philosophies towards using it.
Certainly, there's no absolute justification for having a special Ivy module
as a wrapper around your build dependencies. In some sense, declaring those
dependencies inline, as you show, is just cutting out the middleman.
The thing I like about having a special Ivy module for build dependencies
(whether it's actually published out on the Ivy repo or it's treated as a
reused source build.ivy or the like) is that it makes for a somewhat more
succinct ivy:resolve in your build script and, more important, it separates
the specifics of your build dependencies, in particular the version, from
your build scripts. In other words, your build Ivy module provides an
abstraction layer. Plus, it's helpful for a team to know there's one place
to go, a mediator of sorts, where they can look up all the build
dependencies, with versions, that the team's suite of projects is using.
To be fair (for Marc's sake), someone should only use the build Ivy module
approach for the potential advantages it provides over establishing build
dependencies inline, not because one is not aware of the latter.
On Wed, Mar 10, 2010 at 2:13 PM, Maarten Coene <ma...@yahoo.com>wrote:
> It's not required to create an ivy.xml for you build-dependencies, you can
> resolve them inline in your build.xml.
> The build.xml of Ivy uses this approach, for instance to load the emma
> taskdef:
>
> <target name="emma" depends="jar" unless="skip.test">
> <ivy:cachepath organisation="emma" module="emma" revision="2.0.5312"
> inline="true" conf="default" pathid="emma.classpath"
> log="download-only" />
> <ivy:cachepath organisation="emma" module="emma_ant"
> revision="2.0.5312"
> inline="true" conf="default"
> pathid="emma.ant.classpath" transitive="false"
> log="download-only" />
> <taskdef resource="emma_ant.properties">
> <classpath refid="emma.classpath" />
> <classpath refid="emma.ant.classpath" />
> </taskdef>
> ...
> </target>
> Cfr. https://svn.apache.org/repos/asf/ant/ivy/core/trunk/build.xml
>
> regards,
> Maarten
>
>
Re: Use ivy-dependencies to create ant-tasks
Posted by Maarten Coene <ma...@yahoo.com>.
It's not required to create an ivy.xml for you build-dependencies, you can resolve them inline in your build.xml.
The build.xml of Ivy uses this approach, for instance to load the emma taskdef:
<target name="emma" depends="jar" unless="skip.test">
<ivy:cachepath organisation="emma" module="emma" revision="2.0.5312"
inline="true" conf="default" pathid="emma.classpath"
log="download-only" />
<ivy:cachepath organisation="emma" module="emma_ant" revision="2.0.5312"
inline="true" conf="default" pathid="emma.ant.classpath" transitive="false"
log="download-only" />
<taskdef resource="emma_ant.properties">
<classpath refid="emma.classpath" />
<classpath refid="emma.ant.classpath" />
</taskdef>
...
</target>
Cfr. https://svn.apache.org/repos/asf/ant/ivy/core/trunk/build.xml
regards,
Maarten
----- Original Message ----
From: Mitch Gitman <mg...@gmail.com>
To: ivy-user@ant.apache.org
Sent: Wed, March 10, 2010 10:02:56 PM
Subject: Re: Use ivy-dependencies to create ant-tasks
Marc, doing everything at once at init sounds a bit heavyweight and
monolithic. Imagine you're resolving and retrieving 15 different task
libraries when all you need for a given build is two or three.
Instead, I would obtain tasks on an as-needed basis. So for example, the
moment you need a particular task is the moment you do:
1. ivy:resolve
2. ivy:retrieve
3. taskdef
But this approach also presumes that you've created more fine-grained Ivy
confs that correspond to your different optional tasks.
BTW, when you're using two different Ivy module descriptors in a build, make
sure to specify the file attribute on the ivy:resolve each time so Ivy
doesn't use the wrong one. Good habit anyway, as far as I'm concerned.
On Wed, Mar 10, 2010 at 12:46 PM, marcdb <md...@gmail.com> wrote:
>
> Hi Mitch,
>
> Thanks for your suggestion. I'll try to do the following:
> In my central build file (used for building all projects), I will create an
> init-target which will:
> * execute an ivy:init
> * do an ivy:retrieve using that common ivy.xml file for the dependencies of
> my build-system itself. The appropriate versions of the jars that I need to
> create my ant-tasks will then be retrieved in an appropriate directory for
> my build-system.
> * call the <taskdef> task in ant, to create/define the additional ant-tasks
> that I need.
>
> I hope this will work. It actually seems simplier than I first thought
> :thinking:
>
> Regards,
> Marc
>
>
> --
> View this message in context:
> http://old.nabble.com/Use-ivy-dependencies-to-create-ant-tasks-tp27850372p27855533.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>
Re: Use ivy-dependencies to create ant-tasks
Posted by Mitch Gitman <mg...@gmail.com>.
Marc, doing everything at once at init sounds a bit heavyweight and
monolithic. Imagine you're resolving and retrieving 15 different task
libraries when all you need for a given build is two or three.
Instead, I would obtain tasks on an as-needed basis. So for example, the
moment you need a particular task is the moment you do:
1. ivy:resolve
2. ivy:retrieve
3. taskdef
But this approach also presumes that you've created more fine-grained Ivy
confs that correspond to your different optional tasks.
BTW, when you're using two different Ivy module descriptors in a build, make
sure to specify the file attribute on the ivy:resolve each time so Ivy
doesn't use the wrong one. Good habit anyway, as far as I'm concerned.
On Wed, Mar 10, 2010 at 12:46 PM, marcdb <md...@gmail.com> wrote:
>
> Hi Mitch,
>
> Thanks for your suggestion. I'll try to do the following:
> In my central build file (used for building all projects), I will create an
> init-target which will:
> * execute an ivy:init
> * do an ivy:retrieve using that common ivy.xml file for the dependencies of
> my build-system itself. The appropriate versions of the jars that I need to
> create my ant-tasks will then be retrieved in an appropriate directory for
> my build-system.
> * call the <taskdef> task in ant, to create/define the additional ant-tasks
> that I need.
>
> I hope this will work. It actually seems simplier than I first thought
> :thinking:
>
> Regards,
> Marc
>
>
> --
> View this message in context:
> http://old.nabble.com/Use-ivy-dependencies-to-create-ant-tasks-tp27850372p27855533.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>
Re: Use ivy-dependencies to create ant-tasks
Posted by marcdb <md...@gmail.com>.
Hi Mitch,
Thanks for your suggestion. I'll try to do the following:
In my central build file (used for building all projects), I will create an
init-target which will:
* execute an ivy:init
* do an ivy:retrieve using that common ivy.xml file for the dependencies of
my build-system itself. The appropriate versions of the jars that I need to
create my ant-tasks will then be retrieved in an appropriate directory for
my build-system.
* call the <taskdef> task in ant, to create/define the additional ant-tasks
that I need.
I hope this will work. It actually seems simplier than I first thought
:thinking:
Regards,
Marc
--
View this message in context: http://old.nabble.com/Use-ivy-dependencies-to-create-ant-tasks-tp27850372p27855533.html
Sent from the ivy-user mailing list archive at Nabble.com.
Re: Use ivy-dependencies to create ant-tasks
Posted by Mitch Gitman <mg...@gmail.com>.
Marc:
The approach I've seen and I like is to use one Ivy module descriptor for
the project proper and another one for the build. So, if you're just calling
your ivy.xml ivy.xml, you might have:
* ivy.xml: project-proper dependencies
* build-ivy.xml: build dependencies
To me, the really compelling reason for creating this separation is that
you'll probably find that your build dependencies rarely vary between
projects while your project dependencies are very much project-specific. So
you're better off copying a common build-ivy.xml or build.ivy into each
project--or better yet, consuming a single copy from a common location--than
you are always copying those build dependencies into your ivy.xml.
And what you'll find happening too if you put your build dependencies in
your project ivy.xml is that the former could end up swamping the latter
since there are many projects that just don't need a lot of dependencies.
And for those projects that do, having all those build dependencies in there
too makes the module descriptor that much more complicated, even though you
can follow conventions to clearly state which dependencies belong to the
build.
There are various nice things you can do to further enforce this separation
between project and build dependencies. Anyway, this should get you going...
On Wed, Mar 10, 2010 at 6:26 AM, marcdb <md...@gmail.com> wrote:
>
> Hello,
>
> We are using an ant-task called wsimport to create java-classes from xml.
> This wsimport task is defined as follows in our build-file:
> <taskdef name="wsimport" classname="com.sun.tools.ws.ant.WsImport">
> <classpath refid="jaxws.classpath"/>
> </taskdef>
> Where classpath points to the appropriate jaxb and jaxws jars which are
> checked-in in our version control system.
>
> To control the version of jaxb and jaxws jars that we are using for making
> our builds, we were thinking about using the ivy-dependency mechanism: via
> an ivy.xml file for the build-system, the appropriate versions of these
> jars
> would be retrieved, which could then be used in the classpath when making
> the taskdef.
> Has somebody already done this or knows a better solution to manage the
> versions of the jars that are used in taskdefs of build.xml files.
>
> Thanks,
> Marc
> --
> View this message in context:
> http://old.nabble.com/Use-ivy-dependencies-to-create-ant-tasks-tp27850372p27850372.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>