ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Asking for new feature: Self-Discovery of service to make Ant a real extensible system
Date Sun, 30 Apr 2006 17:56:56 GMT
Huxi LI wrote:
> On 4/28/06, Steve Loughran <> wrote:
>> Which is precisely why it is in Ant1.6. You add a new JAR to the system,
>> all datatypes and tasks will be exported in a namespace of your choosing
>> via an xmlns:mytasks="antlib:org.example.package" declaration.
>> We deal with conflicts and resolution by requiring antlib libraries to
>> be imported into separate namespaces, thus the act of declaring the
>> namespace not only forces the loading of the new tasks, it gives you the
>> separation
>> -Steve
> I know the existence of Antlib; anyway, thanks a lot for your detailed
> explanation.
> But what I am talking about here is to completely mask the taskdef from
> final user.
> It is often not a problem for someone who know Ant well to use custom 
> tasks.
> The problem is that most Ant users are not developers of Ant tasks. They
> just
> download some optional tasks from the Internet and then try to apply 
> them to
> their
> projects. Why should they know what is the task definition in order to use
> them?
> All the final user should know is the tagName and its attributes, but not
> other low-level
> things. That is my concern.

Yes, and by declaring the namespace of a task via an antlib url, you 
dont need a taskdef declaration: The act of identifying the namespace 
for tasks is sufficient to force loading of the tasks and types. That 
is, something like

<target xmlns:sf="antlib:org.smartfrog.extras.ant">
  <sf:functionaltest> ... </sf:functionaltest>

is all you need to force load a library into a build file. No taskdef, 
no typedef. You do need to know about xml namespaces and use them in a 
build file, but that gives you automatic isolation from clashing task 

There's no discovery without that xmlns declaration, so ant boot times 
arent hit by a need to scan every JAR on the classpath. You can also do 
some fancy things with custom logic in your antlib; the set of things 
you can declare in an antlib.xml file is extensible, if you want some 
serious fun.

What ant doesnt have is any maven style auto-download of libraries, and 
its not something on the roadmap. You'd need a security model that 
security people trust yet is still OSS compatible (e.g. PGP signed 
JARs), and a radically reworked classloader model. you can't really do 
that without breaking everything.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message