On Feb 25, 2010, at 10:00 AM, Gilles Scokart wrote:

That's indeed quiet controversial. It moves ant from a declarative style to
a more algorithmique language.

What I dislike is that a target can have some side effect on datatype.
Because id's are global, that will means that when you are using an id into a task, you have to look at its definition to know what it is about, and you will have to search in all other targets in all build files included if
there is no augmentation of the datatype.

Did you have any example to demonstrates the benefits of such task ?


Hi Gilles,
My recent motivation for this regards builds that are composed of multiple files. Say I have a target in a project "jar" that creates a jar archive:

<target name="jar">
  <jar destfile="foo.jar" basedir="${classes.dir}" />
</target>

That's all well and good for many projects, but let's say we want to always catch non-Java resources from our source directory as well. We'd modify this to:

<target name="jar">
  <jar destfile="foo.jar">
    <fileset dir="${classes.dir}" />
    <fileset dir="${src.dir}" excludes="**/*.java" />
  </jar>
</target>

But what if we have another project that is very similar to our basic to-be-archived-as-a-jar Java project, but has one or more extra resource directories? We could provide a hook:

<target name="-setupJarContents" description="Set reference jar.contents">
  <resources id="jar.contents">
    <fileset dir="${classes.dir}" />
    <fileset dir="${src.dir}" excludes="**/*.java" />
  </resources>
</target>

<target name="jar" depends="-setupJarContents">
  <jar destfile="foo.jar">
    <resources refid="jar.contents" />
  </jar>
</target>

And our special extending project would redeclare:

<target name="-setupJarContents">
  <resources id="jar.contents">
    <fileset dir="${classes.dir}" />
    <fileset dir="${src.dir}" excludes="**/*.java" />
    <fileset dir="${resources.dir}" />
  </resources>
</target>

This all works. But I am of the opinion that it is unnecessary that we should have to repeat what was done by the parent. I'd rather depend on jar.-setupJarContents and then somehow extend its default notion of jar.contents . There is not a good declarative way to do this in Ant today. My problem would be solved if I could do this:

<target name="-setupJarContents" depends="jar.-setupJarContents">
  <augment id="jar.contents">
    <fileset dir="${resources.dir}" />
  </augment>
</target>

Does that make sense?

-Matt

Gilles Scokart


On 25 February 2010 05:39, Matt Benson <gudnabr...@gmail.com> wrote:

I'd like to direct the Ant developers' attention to https://
issues.apache.org/bugzilla/show_bug.cgi?id=48798 for discussion.  I'm
hesitant to commit this outright because I anticipate this being somewhat controversial. If noone responds I'll just assume it's not controversial
and act accordingly.  ;)

Thanks,
Matt

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Reply via email to