ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
Subject Re: IntrospectionHelper request
Date Sun, 06 Jan 2002 22:50:54 GMT
----- Original Message -----
From: "Peter Donald" <peter@apache.org>

> Theres plenty of things - will have a look and tell you if I don't like.
> However the main reason I would -1 is because it is only a workaround for
a
> limitation of ant and I don't want to be supporting more ugly hack
> workarounds into the future ;)

Neither do I.  :)

I'll ensure it won't be ugly.

> We already have oodles more "join points" (ie places where we are
flexible)
> than we actually need if it had designed it properly from the start.

No argument there.

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?

> > > When these limitations are removed there would be no need for
DynaTask.
> > > So besides the specified case have you got another example ?
> >
> > The XDoclet use-case is the only use-case I have in mind now.
>
> That makes me less inclined to support it if anything ;)

I think the ability to just define things more clearly
(dynamicProp="someval" versus <property name="dynamicProp" value="someval")
adds a bit of value, and the dynamic element capability has even more
dramatic potential to allow a task to be "pluggable".  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>.

> > Keep in mind that I'm of the opinion that Ant probably should be using
> > XDoclet in the future to allow a lot of a tasks configuration to be
> > specified in meta-data allowing documentation to be generated as well as
> > any other artifacts needed (configurator Java classes perhaps?).
>
> Sounds kool Could you give us an example of what something like that would
> look like? and have you played with any of it yet?

Yes, I've been playing with XDoclet a bit.  Its to-do list generator is a
great way to get introduced to it, but here's a different simple example:

/**
 * ant:taskname mytask
 */
public class MyCustomTask extends Task...

Running XDoclet can build a properties file:

    mytask=com.foobar.MyCustomTask

And then load with <taskdef>.  The advantage is that many tasks can be
defined in one properties file and defined in a build file all at once.
Ant's own tasks could use this to build the embedded task definition
properties file.  I'd be willing to demonstrate that more explicitly if it
is deemed useful by putting a target into Ant's build that does this, and
modifying a handful of tasks to have that Javadoc comment.

I'm not quite sure how this compares/contrasts to what we could do with
aspects, 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.

    Erik



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message