Le 9 nov. 2010 à 13:39, Stefan Bodewig a écrit :
> On 2010-11-09, <hi...@apache.org> wrote:
>
>> Add a task to bind a target to an extension point.
>
> Might be controversial. What is the use-case?
It is helping when some build files are shared between projects.
The use case is that I have some common shared build files.
One is a build file which is taking care of publishing artifacts into a
repository, so have an extension point "ready-to-be-published".
I also have some other build file which is building a jar, and another which is
building the source jar, and yet another one which is about building the
javadoc.
And now I have two different projects.
In the first one I want to build a jar, its source and its javadoc, and publish
all of them. So I my build.xml I import my common-jar.xml, common-src-jar.xml
common-javadoc-jar.xml and common-publish.xml, and "bind" the targets "jar",
"src-jar" and "javadoc-jar" to the extension "ready-to-be-published". So when
calling the target "publish", the 3 jars will be build and published.
In the second project I want to be able to build the jar, its source and its
javadoc, and publish only the jar. So I import my common-jar.xml,
common-src-jar.xml common-javadoc-jar.xml and common-publish.xml, and "bind"
only the target "jar" to the extension "ready-to-be-published". So when calling
the target "publish", only the binary jar will be build and published.
In some sense it is about doing composition of build files.
>
>> public void setTargets(String target) {
>> String[] inputs = target.split(",");
>
> Wouldn't a nested element like <ant>'s nested <target> be the better
> choice?
I found it more simple and concise to be just one attribute, like de "depends"
on the target. Do you think there will be issues with the attribute where there
won't be with a nested element ?
Note: I'll commit the unit test and doc I have wrote about this task. I don't
want to enforce anything, just share the work I have done. It is still up to
debate and can still be reverted.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
