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: Ant2 and <script>
Date Fri, 15 Dec 2000 21:24:39 GMT
This is the best example of why we should keep
IDEs and everything else away from the project/target/task
instances. Here we have, a redesign for ANT that will
screw up something that was counting or a fix internal datastructure.

I always thought that it was bad for script to be able to mingle with
the actual internal representation instead or doing it via some 
well defined functional API isolated from the internal representation.

This is way I keep on insisting that IDEs may use DOM, JDOM, GUIDOM,
PEEWEEDOM or whatever. Is the IDE responsability, at the end of the day,
when asking ANT for execution, to convert this representation in a stream
of SAX events THAT CORRESPONDS TO A WELL DEFINED XML ANT FILE FORMAT.
The only guarantee ANT should provide is that the ANT XML syntax will not
change (too much) :-)

Jose Alberto


> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Friday, December 15, 2000 7:24 AM
> To: ant-dev@jakarta.apache.org
> Subject: Ant2 and <script>
> 
> 
> Both Myrmidon and AntEater instantiate tasks at execution time, unlike
> Ant 1.x. This will have some impact on what you can do with scripts.
> 
> Then both proposals don't have a execute method in target anymore,
> this will limit scripts further - but this shouldn't be a big deal as
> execute could simply invoke project.executeTarget(getName()) and we'd
> be done - guess this is against the IOC pattern, Pete.
> 
> AntEater doesn't have an executeTarget yet, but will sure get
> something similar once it cares for dependencies.
> 
> If you take a look at the two examples in the Ant documentation,
> neither of both would work in Myrmidon or AntEater.
> 
> The problems for Example 1:
> 
> It is no longer Project that creates task instances - no big deal,
> both proposals have factories for this, just make them available to
> scripts as well.
> 
> The second point is that Target doesn't know how to deal with complete
> task instances - in both proposals Target has become a store for task
> placeholders not for real tasks. Likewise, when the targets get
> executed, project doesn't know how to deal with already configured
> tasks.
> 
> The problems for Example 2:
> 
> There is no instance of an Echo task theEcho at all when the scripts
> get executed. 
> 
> In AntEater we'd have a Task and maybe giving it a setAttribute(String
> name, Object value) could help us here. In Myrmidon we'd have a
> Configuration Object, that we could use to set the attribute.
> 
> Anyway, we'd be accessing placeholders here - no tasks. We lose the
> simple bean pattern that could allow us to write 
> 
> theEcho.message = "message"
> 
> And then there might be scripts - valid in Ant 1.x - that invoke
> Task.execute directly. No way to do this in one of the two proposals.
> 
> To summarize:
> 
> (1) Target doesn't have an execute method - could and should be
> changed IMHO.
> 
> (2) Scripts don't have access to the factory that creates tasks -
> dito.
> 
> (3) There is no way to add a completely configured task to a target
> and execute that target after that. There are two options around that
> (a) don't allow a script to instantiate a task directly but make it
> create a placeholder instead (b) build special cases into Target and
> Project to deal either with placeholders or with concrete tasks. Not
> sure which I'd prefer.
> 
> (4) Scripts cannot access attributes of tasks defined in the same
> build file. Possible workaround is to add generic
> getAttribute/setAttribute methods to the placeholders.
> 
> (5) Scripts cannot execute tasks. Hmm, we could provide some
> Project.executeTask(placeholder) method.
> 
> I'd be willing to drop (4) and (5) completely, while we should take
> care of (1), (2) and (3). If we chose solution (3a) we'd have to solve
> (4) as well.
> 
> Stefan
> 

Mime
View raw message