ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: For 2.0: Ant-Extension Mechanism
Date Wed, 18 Oct 2000 20:42:28 GMT
> From: Nico Seessle [mailto:Nico.Seessle@epost.de]
> 
> 
> ----- Original Message -----
> From: "Jose Alberto Fernandez" <JFernandez@viquity.com>
> To: <ant-dev@jakarta.apache.org>
> 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
> 

I have no problem on (a) adding more optional stuff to <taskdef>
to include this information; or (b) having some additional else
within the tasklib declarations to add the additional information.

(a) is self explanatory, in case of (b) we could assume that documentation
is for the entire tasklib as a whole and not for individual tasks,
for example. My point here is that we should be able to say the
same things about tasks, whether they are defines in a library
or they are defined local to a build file.

For example, the tasks for JUnit require junit.jar which is an
external product. One should be able to specify, when describing 
the tasks that their classpath must include this external JAR.
That capability already exists in <taskdef>.

> > 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.
> 

Remember, not every user of ANT works on a single user environment.
If the ANT installation is centrally maintained (e.g. UNIX), one still needs
ways to load their own version of libraries. You may have situations
where different users require different versions of a library, and in
a centralize situation that may be a problem.

I like the idea of using <taskdef> for this. Using my suggestions above,
it would also allow things like a tasklib declaring that some other
tasklib is required, by this one. 

> > 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.
> 
> 

My point here was to have as few required files as possible for CORE.
After all a large part of ANT is the task themselves.

Jose Alberto

Mime
View raw message