ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: IntrospectionHelper request
Date Mon, 07 Jan 2002 07:55:41 GMT
On Mon, 7 Jan 2002 09:50, Erik Hatcher wrote:
> I've just started trying to wrap my head around aspects. I believe these
> are proposed for Ant2, right?  Could elaborate a bit more on the types of
> aspects you envision?

Well we wont really know what they are useful for until we end up trying 
them. The only over-whelmingly fitting use is for things like GUMP that 
manage the Classpath for a whole build and force the tasks to ignore the 
Classpath specified in the xml file.

Some other things that have been considered include allowing a 
1. universal handling of fail-on-error. So that everytask is can have its 
failure ignored by adding an ant:fail-on-error="false" to it's list of 
attributes. No task would have to do it internally anymore
2. universal handling of logging. ie do you want to squash this 
task/target/whatevers logging, or maybe put it into a file or maybe send it 
to a website or whatever
3. universal handling of standard output/input/error - similar to 2 but 
slight different tact.
4. A way to implement a preferences system (ie always use jikes except when 
otherwise specified)

There has also been some more outlandish suggestions that we could try like
5. files become an aspect and you apply tasks to these files (very lisp-y)
6. task templating be implemented via this (ie think of transforming one task 
into a set of tasks via xsl or similar)

But none of these ideas has really seen enough playing with to see if they 
would be successful.

> I think the ability to just define things more clearly
> (dynamicProp="someval" versus <property name="dynamicProp" value="someval")
> adds a bit of value, 

I would see xdoclet as just another type that participates in the DocletInfo 
role (see other mail lfor further explanation).

>and the dynamic element capability has even more
> dramatic potential to allow a task to be "pluggable".

I don't see the functionality you suggested as supplying this.

> I know you made the
> comparison to a task container here, but a task container still has to have
> all the tasks contained within defined specifically either as
> builtin/optional or as <taskdef>.

Not sure what you mean here.

> I'm not quite sure how this compares/contrasts to what we could do with
> aspects, 

little to compare with each other. In fact an aspect could be used to do the 
validation based on the MetaInfo.

> but it could also do things like specify that certain attributes
> are required, what their meaning is, and other such metadata. Not only
> could documentation be generated, but so could actual Java code.  I'm not
> sure about generating code yet, but the main reason its useful is so that
> metadata is only specified in a single place (in the task itself) which
> then propogates into documentation and anywhere else that is needed.


> Again, I think aspects are probably a viable solution to solve some of
> these issues but I'm not familiar enough with them yet to comment further. 
> I'd love to hear more about how aspects could (or couldn't) apply to Ant2's
> architecture.

See above for partial explanation but if you need more exaplanation feel free 
to ask questions ;)



| Contrary to popular belief, UNIX is user-friendly. It   |
| just happens to be selective on who it makes friendship |
| with.                                                   |
|                       - Richard Cook                    |

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message