You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-dev@incubator.apache.org by Matthew Inger <ma...@yahoo.com> on 2007/10/15 16:02:08 UTC
Ivy task to import common build tasks
As part of the ant-contrib project, I had written a task which, underneath the covers,
used the ivy library to resolve a jar file, extract it locally in the ivy cache, and import an
ant build script.
<ac:importurl org="org" name="name" rev="latest.release" />
The following actions would be performed:
1. Resolve the requested module using ivy's inline resolution capabilities
2. Expand the resolved .jar/.zip file to the ivy cache
3. Import the "build.xml" contained in the jar file (the imported filename is
overridable via the "resource" attribute on the task).
In theory, it's a wrapper for 3 operations:
<ivy:resolve />
<unjar />
<import />
This gave me the capability to build re-usable build components which could
be shared amongst different projects. The components live in the ivy repository.
As a result, it became very easy for me to have one common set of build tasks,
which could be updated across the board for all projects simply by publishing a
version of the dependency.
I realize that this is typically accomplished using an ant <import> task. However, that
has several drawback, which i won't go into here, unless someone really wants me to.
With the pending release of Ivy 2.0, this task will no longer work without code changes
to account for the changes to the API from 1.4.1 to 2.0.
I'm wondering if this task might be better suited to being owned by the Ivy project itself.
I am more than willing to donate the code to the Ivy project. As the ant-contrib project
is published under the Apache 2.0 license, i don't see any issues with this.
Any thoughts from the dev team?
----
mattinger@yahoo.com
"Once you start down the dark path, forever will it
dominate your destiny. Consume you it will " - Yoda
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/
Re: Ivy task to import common build tasks
Posted by Dominique Devienne <dd...@gmail.com>.
On 10/15/07, Gilles Scokart <gs...@gmail.com> wrote:
> What you want to do also make me thing to an idea that I have to creates
> ".bar" files (like we have war, ear, ...): build archive file that contains
> some reusable build script, some tasks and possibly some antlibs.
http://www.file-extensions.org lists 3 usages of .bar, while 0 for
.aar, which could stand for Ant ARchive (maybe no one uses it because
you can't really pronounce it ;-)
But unless there's a pre-defined layout of the content of a .bar, a
.jar or .zip would probably do just fine. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy task to import common build tasks
Posted by Steve Loughran <st...@apache.org>.
Gilles Scokart wrote:
> I have also seen something similar in the plan for ant 1.8 [1]:
> - import improvements (url support, searchpath support)
>
> I don't know if it includes also searching build file into a jar. But I
> think that if you combine this futur demand with the ressources of 1.7, it
> should.
> [1] http://wiki.apache.org/ant/Ant18/Planning
the main thing I'd thought of there was resource enabling <import>, so
it would pull in a file from any resource, rather than just the filesystem.
<import >
<zipentry archive="build/lib/something.zip" name="myproject/build.xml" />
</import>
or
<import >
<url url="http://example.org/build.xml" />
</import>
with the obvious security risks in the latter. (maybe I should extend
url with an md5sum option)
One change we'd have to make to the resources is to allow resources to
implement a relative-resource-source interface, so that when I import a
URL, I can then do a relative resolution on its nested <import>
statements to pull down other artifacts. zipentries would get at other
zips, etc. We'd have to extend every ant project to track the resource
it came from, instead of just its base dir.
I like the idea of pulling down specific versions of a library via ivy.
If we made the resource enhancements to Ant, Ivy would have to match
this with a resource that let you declare group/artifact/ entry
<import >
<ivyentry org="org.apache" name="example"
version="${example.version}" name="org/apache/example/build.xml" />
</import>
or, to load in files from a set of JARs:
<import >
<ivyentry ivyconf="main" conf="test"
name="org/apache/example/build.xml" />
</import>
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
Re: Ivy task to import common build tasks
Posted by Steve Loughran <st...@apache.org>.
Gilles Scokart wrote:
> I have also seen something similar in the plan for ant 1.8 [1]:
> - import improvements (url support, searchpath support)
>
> I don't know if it includes also searching build file into a jar. But I
> think that if you combine this futur demand with the ressources of 1.7, it
> should.
> [1] http://wiki.apache.org/ant/Ant18/Planning
the main thing I'd thought of there was resource enabling <import>, so
it would pull in a file from any resource, rather than just the filesystem.
<import >
<zipentry archive="build/lib/something.zip" name="myproject/build.xml" />
</import>
or
<import >
<url url="http://example.org/build.xml" />
</import>
with the obvious security risks in the latter. (maybe I should extend
url with an md5sum option)
One change we'd have to make to the resources is to allow resources to
implement a relative-resource-source interface, so that when I import a
URL, I can then do a relative resolution on its nested <import>
statements to pull down other artifacts. zipentries would get at other
zips, etc. We'd have to extend every ant project to track the resource
it came from, instead of just its base dir.
I like the idea of pulling down specific versions of a library via ivy.
If we made the resource enhancements to Ant, Ivy would have to match
this with a resource that let you declare group/artifact/ entry
<import >
<ivyentry org="org.apache" name="example"
version="${example.version}" name="org/apache/example/build.xml" />
</import>
or, to load in files from a set of JARs:
<import >
<ivyentry ivyconf="main" conf="test"
name="org/apache/example/build.xml" />
</import>
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy task to import common build tasks
Posted by Gilles Scokart <gs...@gmail.com>.
I have also seen something similar in the plan for ant 1.8 [1]:
- import improvements (url support, searchpath support)
I don't know if it includes also searching build file into a jar. But I
think that if you combine this futur demand with the ressources of 1.7, it
should.
What you want to do also make me thing to an idea that I have to creates
".bar" files (like we have war, ear, ...): build archive file that contains
some reusable build script, some tasks and possibly some antlibs.
PS: I put ant-dev in CC in order to have more info on the plan for 1.8.
Sorry for the cross-post. I think it will be solved soon.
[1] http://wiki.apache.org/ant/Ant18/Planning
Gilles
2007/10/15, Xavier Hanin <xa...@gmail.com>:
>
> On 10/15/07, Matthew Inger <ma...@yahoo.com> wrote:
> >
> > As part of the ant-contrib project, I had written a task which,
> underneath
> > the covers,
> > used the ivy library to resolve a jar file, extract it locally in the
> ivy
> > cache, and import an
> > ant build script.
> >
> > <ac:importurl org="org" name="name" rev="latest.release" />
> >
> > The following actions would be performed:
> > 1. Resolve the requested module using ivy's inline resolution
> > capabilities
> > 2. Expand the resolved .jar/.zip file to the ivy cache
> > 3. Import the "build.xml" contained in the jar file (the imported
> > filename is
> > overridable via the "resource" attribute on the task).
> >
> > In theory, it's a wrapper for 3 operations:
> >
> > <ivy:resolve />
> > <unjar />
> > <import />
> >
> > This gave me the capability to build re-usable build components which
> > could
> > be shared amongst different projects. The components live in the ivy
> > repository.
> > As a result, it became very easy for me to have one common set of build
> > tasks,
> > which could be updated across the board for all projects simply by
> > publishing a
> > version of the dependency.
> >
> > I realize that this is typically accomplished using an ant <import>
> > task. However, that
> > has several drawback, which i won't go into here, unless someone really
> > wants me to.
> >
> > With the pending release of Ivy 2.0, this task will no longer work
> without
> > code changes
> > to account for the changes to the API from 1.4.1 to 2.0.
> >
> > I'm wondering if this task might be better suited to being owned by the
> > Ivy project itself.
> > I am more than willing to donate the code to the Ivy project. As the
> > ant-contrib project
> > is published under the Apache 2.0 license, i don't see any issues with
> > this.
> >
> > Any thoughts from the dev team?
>
>
> I like the idea behind this task, and think it could fit in the picture of
> Ivy. So I think moving this to the Ivy project can be nice. We have to
> think
> about several things though:
> - since you are not a committer on Ivy (yet), you will have to submit
> patches if you later want to improve the task. Is this ok for you?
> - do you have documentation and unit test for this task? Documentation is
> mandatory, and unit test are highly appreciated :-)
>
> Thoughts?
>
> Xavier
>
> ----
> > mattinger@yahoo.com
> > "Once you start down the dark path, forever will it
> > dominate your destiny. Consume you it will " - Yoda
> >
> >
> >
> >
> >
> >
> >
> ____________________________________________________________________________________
> > Need a vacation? Get great deals
> > to amazing places on Yahoo! Travel.
> > http://travel.yahoo.com/
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://incubator.apache.org/ivy/
> http://www.xoocode.org/
>
--
Gilles SCOKART
Re: Ivy task to import common build tasks
Posted by Gilles Scokart <gs...@gmail.com>.
I have also seen something similar in the plan for ant 1.8 [1]:
- import improvements (url support, searchpath support)
I don't know if it includes also searching build file into a jar. But I
think that if you combine this futur demand with the ressources of 1.7, it
should.
What you want to do also make me thing to an idea that I have to creates
".bar" files (like we have war, ear, ...): build archive file that contains
some reusable build script, some tasks and possibly some antlibs.
PS: I put ant-dev in CC in order to have more info on the plan for 1.8.
Sorry for the cross-post. I think it will be solved soon.
[1] http://wiki.apache.org/ant/Ant18/Planning
Gilles
2007/10/15, Xavier Hanin <xa...@gmail.com>:
>
> On 10/15/07, Matthew Inger <ma...@yahoo.com> wrote:
> >
> > As part of the ant-contrib project, I had written a task which,
> underneath
> > the covers,
> > used the ivy library to resolve a jar file, extract it locally in the
> ivy
> > cache, and import an
> > ant build script.
> >
> > <ac:importurl org="org" name="name" rev="latest.release" />
> >
> > The following actions would be performed:
> > 1. Resolve the requested module using ivy's inline resolution
> > capabilities
> > 2. Expand the resolved .jar/.zip file to the ivy cache
> > 3. Import the "build.xml" contained in the jar file (the imported
> > filename is
> > overridable via the "resource" attribute on the task).
> >
> > In theory, it's a wrapper for 3 operations:
> >
> > <ivy:resolve />
> > <unjar />
> > <import />
> >
> > This gave me the capability to build re-usable build components which
> > could
> > be shared amongst different projects. The components live in the ivy
> > repository.
> > As a result, it became very easy for me to have one common set of build
> > tasks,
> > which could be updated across the board for all projects simply by
> > publishing a
> > version of the dependency.
> >
> > I realize that this is typically accomplished using an ant <import>
> > task. However, that
> > has several drawback, which i won't go into here, unless someone really
> > wants me to.
> >
> > With the pending release of Ivy 2.0, this task will no longer work
> without
> > code changes
> > to account for the changes to the API from 1.4.1 to 2.0.
> >
> > I'm wondering if this task might be better suited to being owned by the
> > Ivy project itself.
> > I am more than willing to donate the code to the Ivy project. As the
> > ant-contrib project
> > is published under the Apache 2.0 license, i don't see any issues with
> > this.
> >
> > Any thoughts from the dev team?
>
>
> I like the idea behind this task, and think it could fit in the picture of
> Ivy. So I think moving this to the Ivy project can be nice. We have to
> think
> about several things though:
> - since you are not a committer on Ivy (yet), you will have to submit
> patches if you later want to improve the task. Is this ok for you?
> - do you have documentation and unit test for this task? Documentation is
> mandatory, and unit test are highly appreciated :-)
>
> Thoughts?
>
> Xavier
>
> ----
> > mattinger@yahoo.com
> > "Once you start down the dark path, forever will it
> > dominate your destiny. Consume you it will " - Yoda
> >
> >
> >
> >
> >
> >
> >
> ____________________________________________________________________________________
> > Need a vacation? Get great deals
> > to amazing places on Yahoo! Travel.
> > http://travel.yahoo.com/
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://incubator.apache.org/ivy/
> http://www.xoocode.org/
>
--
Gilles SCOKART
Re: Ivy task to import common build tasks
Posted by Xavier Hanin <xa...@gmail.com>.
On 10/15/07, Matthew Inger <ma...@yahoo.com> wrote:
>
> As part of the ant-contrib project, I had written a task which, underneath
> the covers,
> used the ivy library to resolve a jar file, extract it locally in the ivy
> cache, and import an
> ant build script.
>
> <ac:importurl org="org" name="name" rev="latest.release" />
>
> The following actions would be performed:
> 1. Resolve the requested module using ivy's inline resolution
> capabilities
> 2. Expand the resolved .jar/.zip file to the ivy cache
> 3. Import the "build.xml" contained in the jar file (the imported
> filename is
> overridable via the "resource" attribute on the task).
>
> In theory, it's a wrapper for 3 operations:
>
> <ivy:resolve />
> <unjar />
> <import />
>
> This gave me the capability to build re-usable build components which
> could
> be shared amongst different projects. The components live in the ivy
> repository.
> As a result, it became very easy for me to have one common set of build
> tasks,
> which could be updated across the board for all projects simply by
> publishing a
> version of the dependency.
>
> I realize that this is typically accomplished using an ant <import>
> task. However, that
> has several drawback, which i won't go into here, unless someone really
> wants me to.
>
> With the pending release of Ivy 2.0, this task will no longer work without
> code changes
> to account for the changes to the API from 1.4.1 to 2.0.
>
> I'm wondering if this task might be better suited to being owned by the
> Ivy project itself.
> I am more than willing to donate the code to the Ivy project. As the
> ant-contrib project
> is published under the Apache 2.0 license, i don't see any issues with
> this.
>
> Any thoughts from the dev team?
I like the idea behind this task, and think it could fit in the picture of
Ivy. So I think moving this to the Ivy project can be nice. We have to think
about several things though:
- since you are not a committer on Ivy (yet), you will have to submit
patches if you later want to improve the task. Is this ok for you?
- do you have documentation and unit test for this task? Documentation is
mandatory, and unit test are highly appreciated :-)
Thoughts?
Xavier
----
> mattinger@yahoo.com
> "Once you start down the dark path, forever will it
> dominate your destiny. Consume you it will " - Yoda
>
>
>
>
>
>
> ____________________________________________________________________________________
> Need a vacation? Get great deals
> to amazing places on Yahoo! Travel.
> http://travel.yahoo.com/
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/