Huxi LI wrote:
On 4/28/06, Steve Loughran <[EMAIL PROTECTED]> 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.
http://ant.apache.org/manual/index.html
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>
</target>
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
names.
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.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
