See URL for documentation. Probably nothing
special needs to be done to support use of antlibs
contained in $nbhome/ant/lib/*.jar, since these
will be in Ant's own classpath. (Same for
user-configured Additional Classpath.) However it
would be nice if IDE-specific tasks installed in
$nbhome/ant/nblib/*.jar also worked this way.

For example, consider ant/nblib/nbbrowse.jar,
which currently has a META-INF/taskdefs.properties
containing:

nbbrowse=org.netbeans.modules.ant.browsetask.NbBrowse

Note that the format of this JAR is NB-specific,
i.e. the path "META-INF/taskdefs.properties" is
defined by the Ant module API.

The task name needs to use the prefix "nb" to
prevent clashes with possible unrelated tasks.
This is a little messy, and antlibs might be better.

So consider permitting the JAR to contain just
org/netbeans/modules/ant/browsetask/antlib.xml:

<antlib>
  <tasklib name="browse"
classname="org.netbeans.modules.ant.browsetask.NbBrowse"/>
</antlib>

Now a script could explicitly ask for this task to
be used as follows:

<project ...
xmlns:b="antlib:org.netbeans.modules.ant.browsetask">
  <target name="display">
    <b:browse file="foo.html"/>
  </>
</>

So requested changes:

1. Recommend as a matter of convention that all
task libs supplied in $nbhome/ant/lib/ (or
$nbhome/ant/extra/) use the <antlib> notation so
that there is a well-defined namespace for them.
This should avoid possible naming conflicts.

Note that scripts using such tasks can be run from
command-line Ant (1.6) just fine so long as the
appropriate libs are in Ant's classpath, and there
is no need to use <taskdef>. Or, if the user
prefers to store the libs in a well-known location
for SCM purposes, this is still easy:

<taskdef resource="org/foo/tasks/antlib.xml"
classpath=".../footasks.jar"
uri="antlib:org.foo.tasks"/>

Note that it would be possible for the IDE to
generate the above taskdef at a user request. It
can preinitialize the classpath with the location
of the JAR in the IDE installation, and the user
could modify this as needed to point to a
project-versioned lib etc.

2. For IDE-internal tasks in
$nbhome/ant/nblib/*.jar, deprecate
META-INF/{task,type}defs.properties in favor of
the antlib style. Thus all IDE-internal tasks
would need to be namespaced, which is probably not
a bad thing. Code completion etc. can continue to
work just by scanning for any **/antlib.xml in
these JARs.

Since these JARs are not in the default classpath,
I presume that the Ant module would need to
predefine all such namespaced defs in the Project
before running it (there is no apparent callback
to hook into ComponentHelper.checkNamespace so it
probably can't be done lazily).

Also issue #36702 might be solved nicely by
enabling only those antlib: namespaces whose
package names correspond to the code name bases of
enabled modules.

(Note:
http://issues.apache.org/bugzilla/show_bug.cgi?id=24024)