Re: Asking for new feature: Self-Discovery of service to make Ant a real extensible system

[Dominique Devienne <dd...@gmail.com>]

> There's no discovery without that xmlns declaration, so ant boot times
> arent hit by a need to scan every JAR on the classpath.

That's one reason, and a very valid one IMHO. Another is to have
things stay explicit in Ant as much as possible. I dispute your point
that auto-discovering of tasks is good for non-developers end users.
My own experience is that less Ant-savvy users don't know where the
non-core tasks are coming from, so can't find out the documentation
for them (when there's doc ;-).

I've very much a proponent of using the AntLibs auto-magic
antlib:<package-name> Namespace URI, because it still forces an
explicit reference to access the tasks, which help in identifying
these tasks' origin, while being simple and short enough.

If auto-loading is ever implemented in Ant, I would want it to be OFF
by default, and be turned ON either by a command line switch or an
attribute in the top-level <project> element of the build file. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Re: Asking for new feature: Self-Discovery of service to make Ant a real extensible system

[Matt Benson <gu...@yahoo.com>]

--- Steve Loughran <st...@apache.org> wrote:
[SNIP]
> I've taken to declaring macros/presets in their own
> ns too.

I envision a world where this is not considered
remarkable.  Macros, presets, and scripts are good for
rapid prototyping, but if a task can be composed of
other tasks in Java, what is less correct about the
composite task being written in "Ant"?  I consider the
following a good example of something cool to do with
ns'd presets:  at my last job we had loads of legacy
stuff using Btrieve databases.  In trademark gross
abuse of Ant I used it for all kinds of utility jobs
in our final conversion away from all that. 
Historically Btrieve has been used a lot through a
command-line utility called BUTIL.  So I created a
BUTIL antlib along the lines of:

<presetdef name="create">
  <apply executable="BUTIL"
         failifexecutionfails="true">
    <arg value="-CREATE" />
    <targetfile />
    <srcfile />
  </apply>
</presetdef>

<presetdef name="copy">
  <apply executable="BUTIL"
         failifexecutionfails="true">
    <arg value="-COPY" />
    <srcfile />
    <targetfile />
  </apply>
</presetdef>

and so on for whichever options I needed...

so what would have been (in a batch file): 
  BUTIL -CREATE merged.btr merged.des
  FOR %%X in (foo.btr bar.btr) do (
    BUTIL -COPY %%X merged.btr
  )

comfortably became (declaring the "butil" ns in the
calling buildfile):

<butil:create>
  <fileset file="merged.des" />
  <mapper type="glob" from="*.des" to="*.btr" />
</butil:create>

<butil:copy>
  <fileset dir="${basedir}" includes="*.btr" />
  <mapper type="merge" to="merged.btr" />
</butil:copy>

i.e. those familiar with the command-line tool would
have no problem understanding what was going on...

anyway...

-Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Re: Asking for new feature: Self-Discovery of service to make Ant a real extensible system

[Steve Loughran <st...@apache.org>]

Dominique Devienne wrote:
 >> There's no discovery without that xmlns declaration, so ant boot times
 >> arent hit by a need to scan every JAR on the classpath.
 >
 >
 > That's one reason, and a very valid one IMHO. Another is to have
 > things stay explicit in Ant as much as possible. I dispute your point
 > that auto-discovering of tasks is good for non-developers end users.
 > My own experience is that less Ant-savvy users don't know where the
 > non-core tasks are coming from, so can't find out the documentation
 > for them (when there's doc ;-).

Or more importantly, who to complain to when they have a support call. 
It's easier to deny knowledge when the task is called <eclipse:compile> 
or <weblogic:jspc>.

 >
 > I've very much a proponent of using the AntLibs auto-magic
 > antlib:<package-name> Namespace URI, because it still forces an
 > explicit reference to access the tasks, which help in identifying
 > these tasks' origin, while being simple and short enough.

I've taken to declaring macros/presets in their own ns too. What is 
confusing is if you declare them in someone else's namespace. There's 
nothing to stop you doing that, but it confuses other people.

steve.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org