ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
Subject Re: XDoclet status update
Date Sun, 03 Mar 2002 15:53:53 GMT
From: "Jose Alberto Fernandez" <j_a_fernandez@yahoo.com>
>> 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.

Well, I'm all about XP, so *when* (not if :) we get to the antlib deal we'll
implement the segregation.  Perhaps we should go ahead and start tagging the
classes with a library identifier also?  @ant.task library="..."?  We
already segregate by category for documentation purposes, so having multiple
defaults.properties generated (or whatever type of file that should morph
into in the antlib model) won't be a problem.

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

Right now several tasks 'names' point to Expand, and the XDoclet stuff is
not handling that at the moment.  So it is only generating one entry into
defaults.properties for it, and one XML file. It won't be difficult, I don't
think, to have it corrected so that Expand would create multiple entries in
defaults.properties (unjar, unwar, unzip, etc) and that a unique XML file
for each is generated also.  We'll just have this:

    @ant.task name="unjar" name="unwar" name="unzip"

(or some such construct) in Expand.java.

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

Currently the "category" (@ant.task category="...") defines the grouping it
gets in the directory structure for the XML and documentation generated.
This is a high-level grouping of, for example, jar/zip/war/ear/tar into a
"packaging" category.

Peter and Adam are already discussing stealing this stuff for myrmidon - so
I'm sure they'll be merging it together with the previous prototype role
metadata generation that I did for them originally there.

If we need some kind of mapping to antlib roles that won't be difficult to
add either.  At this point I'm tossing it out there as-is and will do the
best I can to improve it, but thanks to Bill's nice work I encourage you to
give it a shot (just run 'ant docs' in proposal/xdocs directory) and see the
output (build/gen & build/docs) for yourself and then suggest improvements.
Its amazing how close we are with this thing, especially with the ability to
merge in external files with the merge points giving us the ability to pull
in the description and examples from the existing documentation.  I am
considering writing a little JTidy-based tool that will convert the HTML
docs into the XML format Bill mocked up for a few tasks.  I'm not sure if
this is worthy of my time just yet, so I think I'll hold off and find out
what else shakes out from all this.

    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