On Sunday, January 5, 2003, at 11:17 AM, Aslak Hellesoy wrote
I'm sorry, but it looks like you're reinventing the wheel here. TheAfter an IM session with Aslak we've agreed to let me proceed with what I'm doing. My code does some things a bit differently (and more accurately) with Java analysis. Here are a few features of mine that are not in Aslak's implementation:
AntDocSubTask and AntDocTagsHandler (in the xdoclet module) already
implement that kind of functionality. It's being used to generate XDoclet's
task documentation, and is also used (by extension) to generate the Maven
plugin.
This is basically code that introspects Ant tasks, looks at @ant tags and
builds a nice model you can use from the template. I think you'd be better
off writing a new template (the current task_xml.xdt template produces xdoc
docs) that uses the same technique. And of course add any functionality you
might need to the existing classes.
- A Java class that simply has "public void execute()" is all it takes to be an Ant task. It does not have to extend from o.a.t.a.Task. This makes it harder to determine whether a class is really a task or not. The @ant.task ignore="true" is used to flag classes that appear to be Ant tasks but are
not really to be ignored.
- It takes Ant's own IntrospectionHelper logic into consideration for determining 100% accurately what attributes/sub-elements are supported. This makes it necessary to have the binary and Java code being processed available when running my <antdoclet>.
- EnumeratedAttribute values are provided to the template for including. This is very important for Ant task documentation. This is another reason why the binary .class is needed during processing.
There are likely some other feature differentials.
While I won't be able to move as fast with this as you other XDoclet committers, I'll do my best to keep progress going and to have my <antdoclet> be capable of generating what AntdocSubTask currently does and then combine efforts and centralize all Ant-specific subtasks/tags under the apache.ant module and let the "ownership" of the @ant* tags be with that module.
Thanks, Aslak, for keeping me on my toes and ensuring I was aware of the potential duplication going on. I think my efforts are sufficiently different and richer to warrant the effort. The idea is for <antdoclet> to be able to generate Ant task/datatype documentation, <taskdef> properties files, and descriptors making Antlib possible (see ant-dev e-mail list for details on these efforts actively underway), and also hopefully to allow IDE's and tools to get rich Ant metadata about tasks so that WYSIWYG editors can have all the info it needs to effectively do what XDocletGUI can do for XDoclet tags for Ant build files.
Erik
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
