----- Original Message ----- From: "Jose Alberto Fernandez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 18, 2000 3:19 AM Subject: RE: For 2.0: Ant-Extension Mechanism
> I would prefer if the XML contained <taskdef>s declarations instead of some > other new definition. That would mean that we have one unified mechanism > that is used by everything. I guess that would make <taskdef> the only > predefined > task within ANT itself. I guess my point is that what I can say in a > tasklib.xml > must not be more nor less expressive than declaring tasks in thebuildfile > itself. > It must not, but it could. Think of: - including documentation (or at least a pointer on what files should be build into the docs) into the tasklib.xml (if we someday get there that we can build documentation (or part of) dynamically - AutoUpdate > There should be a way to load a tasklib from the buildfile, do you have > that? > I mean, one should be able to use libraries that have not being installed by > default. > Hmm... you can put every .tsk-file which you get just into %ANT_HOME%/ext, restart ant and the task is available. Is this enough? It should not be a big problem to add something like <taskdef lib="myfile.tsk"/> if this is needed. > Do we really need to have a separate core.tsk file? Why not make ant.jar a > tasklib file by adding a METAINF/tasklib.xml to it. You provided the task. > This would result in the same "problems" as putting all core-tasks in a core.tsk - it would need larger changes to the build-process of ant itself and was just not done at this time because 1. I'm not so experienced with CVS 2. I don't like to have a second workspace around for quite a long time 3. I don't know how to sync two local workspaces 4... But you are right, it should probably done this way.
