ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cortexebusiness.com.au>
Subject Introspection Change comments
Date Tue, 31 Jul 2001 15:19:50 GMT
I would like to get some feedback on a change I am considering. With the
current Introspection nested element support, the task's method
corresponding to the nested element is called before the nested element is
configured. I would like to add a mechanism to support the calling of this
method after the element is configured. This will only work for addXXX
style methods since for those methods the object creation can occur without
involving the task.

I have implemented this (the diff is attached), by checking for a method
addConfiguredXXX, rather than simply addXXX. The diff includes changes to
the Jar task to allow a manifest to be specified in the build file directly

    <jar jarfile="taskjar2.jar" basedir=".">
      <include name="src/**/*"/>
      <manifest>
        <attribute name="created-by" value="me"/>
        <section name="foobar">
          <attribute name="Sealed" value="True"/>
        </section>
      </manifest>
    </jar>

Now, my main concern is with the use of addConfigured. It is potentially a
compatibility issue if some custom task has a nested element
<configured...>. I guess that is pretty low risk. The alternative would be
to use a different prefix, such as putXXX() or configXXX(). That should be
backward compatible, although it may expose methods to the buildfile as
nested elements which were not intended.

So, what do you think? It makes some tasks easier to write if the element
is configured before it is added to the task. Certainly this was the case
for manifests. If you think this is worthwhile, what about the naming of
the methods eligible for this?

Let me know your thoughts?

Conor







Mime
View raw message