ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: XDoclet status update
Date Sun, 03 Mar 2002 12:46:04 GMT
From: "Erik Hatcher" <jakarta-ant@ehatchersolutions.com>

> I've enhanced the proposal/xdocs a bit to detect Ant tasks a lot better. It
> climbs the hierarchy looking for a parent class with an execute() method
> (except if it hits org.apache.tools.ant.Task it quits and doesn't count that
> as a task).
> 

Great!

> I'm using the generation of defaults.properties as the "litmus test" to how
> good the generation is working, and it just about matches our currently hand
> maintained defaults.properties.  

This is fine, but notice that defaults.properties lumps together all classes, no matter
if they are part of CORE (ant.jar) or of optonal.jar. When and if we moved to
an <antlib> model, we will need to be able to segregate things. I just spend an
entire day tracking a failure on the testcases when using <antlib> proposal
and the reason was that org.apache.tools.ant.taskdefs.Get goes into optional.jar
instead of ant.jar (mind you its inner-classes are still in ant.jar). Because the declaration
was in a diferent place than the code, it was not loaded by any of them.

So the docklet has to be able to put things in the right place.

> Overall, it looks like its right on track with only a few minor issues.
> Here are a few issues/ideas:
> 
> - Can a class with a method 'void execute() throws Exception' be a task?
> 
> - It seems that we have a few exceptions that will require an 'ant.task
> ignore="true"' kinda thing so that it gets skipped over for processing even
> though it could really be used as a task.  Thoughts?
> 

I think we need this for maintainability. We may want to control which 
classes are exposed as tasks in a particular release. We may want to 
provide a new implementation for the XML task, but still need to leave
the old class in there in case someone extended it. But we just do not
expose it as available.

> - There are several tasks that point to Expand, and right now there are
> additional 'name="..."' in the class, but the template is not coded such
> that it picks that up when building defaults.properties.  This should be an
> easy thing to add.  But how would multiple names play out in the XML created
> for a task?  Should it create multiple XML files?  Or just note the multiple
> names as aliases in one XML file somehow?
> 

You mean the documentation? I think each should have its own documentation,
the fact that the task in implemented by the same code is just an implementation
detail and users should not rely on that fact. We may decide to change the implementation
of one and not the rest.

> - Categorization - should we restrict a task to a single category?  Or allow
> it to be in multiple?  Or do we need a few different "bucket" types to drop
> tasks into?  I've been thinking we should have a "vendor" bucket so that we
> could create groupings in documentation for all Weblogic tasks (wljspc,
> wlrun, wlstop) for example.  There are lots of ways we could go with this!
> So start the brainstorming, and let me know.

Ok, here I am not clear what you mean by cathegories. Certaintly it would
be nice if you could provide means to use these for roles (as on ANT2 or <antlib>
proposals) among other things.

Jose Alberto



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