ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: [xdocs] Feature Requests
Date Wed, 06 Mar 2002 23:22:53 GMT
----- Original Message -----
From: "Bill Burton" <>

> A while ago when I went hunting for the XDoclet stuff in myrmidon, I had
> no idea that the files with .template were related to XDoclet.  On the
> other hand if they were .j,  I wouldn't have known either because I didn't
> know anything about XDoclet :) . Although .j may not be a very good
> convention, it is a convention nonetheless.

It is indeed a convention, but one I feel worthy of breaking because .j ->

Maybe we should make them be .x files!  :)

> What I'd really like is a way of specfying how tasks are classified into
> categories at the Ant task level much the way the <group> element works
> for javadoc or in an XML file.

You mean -group?  What is <group>?  I didn't know about -group but just
looked it up, and it certainly seems reasonable to be able to recategorize
things after the XML has been generated.

> I think getting the dependency checking working well under most cases is
> rather important.  If committers have to regenerate all the XML because of
> a little change to one task, it won't go over well.  Initially, the task
> could handle dependency checking like the <style> or <dvsl> tasks where a
> newer source causes the respective target XML to be regenerated.  But if
> the XDoclet template is newer, then everything is regenerated.  Handling
> other dependencies such as changes to datatypes or source XML's could be
> done with <uptodate>.

I think you and Peter are missing something (or I am!).  If we only feed into XDoclet because only that file changed, then how would
we enumerate the elements for FormatterElement (addFormat)?  You can't
(again, unless I'm missing something major here).

I don't currently know a solution for this except to wait the minute and a
half that it takes to generate all of those files for the current Ant
codebase.  Its not like you'd need to run that process for every build, only
if you wanted to regenerate docs or

Or we could just keep bugging Ara to get xjavadoc finished!  :)  (which
promises multiple times improvement in speed)

> Yes, I'd considered that as well.  The problem is both the <dvsl> and
> <style> tasks don't have a way to use a fileset is input with only a
> single file as output.  I was considering fixing this in the <dvsl> task
> or even implementing support for a merge mapper.  However, XDoclet already
> has all info for the classes loaded in memory so it's really quick to run
> another template to generate a single file like

Yes - agreed.  Adding more and more templates won't affect our processing
speed much - its the initial javadoc load of the source code that is slow -
and with the above mentioned issue I'm not sure there is a way around doing
that full load.


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

View raw message