Cool - I have looked at the discussion over antlib descriptors and I see how
that fixes my issues with optional.jar being 'special'.
It strikes me that if you get the antlib descriptor right, then the
'Registry' would be little more than an XML document of antlib descriptors.
I think some additional nodes would be required. For example,
if the antlib xml file stored in the META-INF/antlib.xml has been proposed
as something like :
(The discussion over the exact nodes aren't important here).
If you extended that to be something like:
Then your "Registry" would need to be little more than
...
...
...
...
Furthermore, you could set the default location to read this registry as,
say, http://plugins.apache.org/antlib.xml, but allow it to be overridden as
a property. That way if I have some tasks that are useful internally to my
developers, I can set their installation to point to a different location
where my plugins are stored. Thus I could have my developers machines set to
automagically update themselves on each run..
I think you need to be careful over versioning of code, both for the
versions of ANT that the tasks can run against and of updates to the task
itself..
---
> >Actually, when I was reworking the tasks overview page, I was
thinking
> >of adding a section for Unsupported (or External, Contributed,
whatever)
> >Tasks, and listing the links in the doc. Would something like that
> >suffice? (See the tasksoverview.html file in ...docs/manual in CVS to
> >see what I'm referring to.)
I think this would get cumbersome to manage, but in general somehow we
(ant-dev) should come up with a "registry" of tasks so that its easy to
find. Kinda like jEdit plugins, for example. Perhaps we need a simple
manager UI (via WebStart?) that can query our registry and pull down the
latest greatest versions of tasks.
We're a ways from that, but something we should aim for probably. And
with
the antlib initiatives I'm sure we're getting closer.
> Thinking about it, what would be even nicer is something such as the
> following:
>
> * Tasks can be in jar files dropped in the lib directory
They already can be. And if the JAR files contain a properties file
that
has this:
taskname=fully.qualified.classname
Then you can simply:
> * Tasks can be added merely by dropping new jar files into the lib
directory
Not automagically yet, but see above.
> This does mean that the task 'namespace' is controlled by jakarta by
> default, but that sounds like no bad thing...
I don't think we want to get that tight with it, but certainly this is
an
area where we need substantial improvement in the future.
Erik
--
To unsubscribe, e-mail:
For additional commands, e-mail:
--
To unsubscribe, e-mail:
For additional commands, e-mail: