ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Takashi Okamoto <>
Subject Re: [PROPOSAL] javadoc refactoring and supporting gjdoc
Date Sat, 27 Sep 2003 02:52:02 GMT
Hi Stefan,

From: Stefan Bodewig <>
Subject: Re: [PROPOSAL] javadoc refactoring and supporting gjdoc
Date: 26 Sep 2003 11:40:12 +0200
> > In the past, I refactored rmic for other than SUN's rmic
> > implementation.
> Yes, I remember that.  

I remeber you take some of my patches too, thanks. 

> But <rmic> is a lot easier to find a common interface for, I'm
> afraid.  How many of javadocs attributes or nested elements would be
> supported by gjdoc?  50%, 80% or all?

In gjdoc case, less than 50%. You are right, I should write <gjdoc>
task independent. But main problem remains.

This is not ant problem but I would like to explain why I propose
supporting gjdoc. If I hear good idea to resolve this problem, I'm

I maint java oss packages for Debian. Debian have 'main' and 'contrib'
section. 'main' group is official debian package which mean it's
compiled and run opensource platform(e.g. kaffe/gcj) 'contrib' group
is non-official which mean it's opensource but can't be built nor run
with opensource platform.

So, most of opensource java software create javadoc document with
javadoc task. This means I can't put such a package into main
section beacuse javadoc depend on SUN's implentation which is not
oss. I would like to increase official package for Debian. Most of
javadoc task in build file seems not to use special option. If it use,
I can igonore to obtain javadoc in most case. Then ,if gjdoc task
is separated, I must modify build.xml file for all javadoc generation
to create Debian package. I won't like to modify build.xml for each
package and I propose JavadocAdapter.

> javadoc1 and javadoc4 are flags.  There are certain attributes that
> can not be used for the javadoc version of JDK 1.1 as they've been
> added later.  Likewise the javadoc for JDK 1.4 added new stuff.
> You'd rather need SunJavadoc1.1, SunJavadoc1.2 and SunJavadoc1.4 where
> SunJavadoc1.1 would only use the attributes and nested elements that
> now get used if javadoc1 is true.  SunJavadoc1.2 all that will be used
> if both flags are false and SunJavadoc1.4 all those where javadoc4 is
> true.
I see. If I refactor it, Sun's implementation should be splited into
each Javadoc.

Ok. Currently, I suspend supporting gjdoc. But when gjdoc grown up or
I found other javadoc compatible tool, I'll try again.

BTW, I already send the patch in bugzilla.

Please close it.


Takashi Okamoto

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

View raw message