ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: [Ant2] Tasks as siblings of <target>
Date Mon, 22 Oct 2001 10:56:21 GMT
From: "Peter Donald" <>

> On Mon, 22 Oct 2001 17:42, Stefan Bodewig wrote:
> > Declaring TaskContexts (whatever that will be), declaring and
> > attaching build listeners from within a build file, configuring
> > aspects (do we fail on error and all that, this probably is the
> > taskcontext stuff).
> those examples work. For these things to be implemented as tasks we are 
> definetly going to need the "privlidged" tasks I have talked about in past 
> where the container provides specialized services that allows them to do all 
> manipulation stuff.

I do not have a problem with the concept of priviledge tasks. However, I do not
think we should assume we can identify all of them today, nor that such privileged 
tasks should be confined to CORE code, by using some secret API or
some other hidden means.
That is what are for. That means that external code
can be given permission to interact more tighter with the container if necessary.

The API itself should be public and published.

> I suspect we are going to have to define a set of runtime tasks that are much 
> more coupled to container that access all the runtime data. We should somehow 
> mark these aas special and any that are not developed by ant-dev group should 
> be considered unsupported and possibly break in future. Not sure really. I 
> started to do this in myrmidon but there was a number of issues that arose 
> aout of how granular the services are. Fine grain services allow tasks to do 
> more interesting stuff but also could be a maintanence nightmare and overly 
> constraining as we evolve. Large interfaces can be inflexible.

One thing that puzzles me on this debate is how much enphasis should be given
to "security of the container" in the sense being discussed above. I can understand
the need for high levels of security if the ANT container were designed to execute 
code outside the control of the ANT user (like it is the case with applets or servlets)
but in the case of ANT I do not see this as an escenario in the forseeable future.

Having said that, I would agree with the need of having separate APIs providing this 
different levels of access to the container, and requiring tasks that want to perform
tighter operation to first request access to the tighter API "controler". But whether
we actually forbid tasks from gaining such access may be left out until we really
see a need for it (like for example, if we allowed the usage ANT libraries or buildfiles
directly from the web).

Jose Alberto

View raw message