ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jay Handfield <>
Subject Re: [PATCH]: Added maxmemory option to javadoc task
Date Thu, 23 Mar 2000 15:17:29 GMT

Thomas Haas wrote:

> How about putting it into the Java task and let Javadoc extend Java (with fork=true by
> default), so the feature would be available to other java tasks, which run in VM on their

I think you can already increase the memory of a forked javadoc task by
doing something like:

<java fork=true class=Main jvmargs="-Xmx32m">

Mmmm, I guess the current jvmargs option does the have the disadvantage
that your build file must contain knowledge about which version of Java
you are using, i.e. for a Java 1 you  would need to write

<java fork=true class=Main jvmargs="-mx32m">


Possible solutions:

1) The quick fix is for me to add my maxmemory option to the
java task as well.

2) More uniformly, we could add options to the java task for more (all?)
of the java command line options.  For example, maybe there should be an
option for minimum heap size also?  We may want to split the in-process
and out-of-process java tasks if we do this?

3) Another uniform solution would be to add a resolveJvmArgs method to
the Java task that rewrites the JVM args to take the Java version into
account (Much like translatePath takes the OS dependencies into

What do other people think?  I would be happy to implement any changes
people think we need.

Your idea of having the Javadoc task inherit from the Java task also
seems like a good idea.  My only concern is how should we handle someone
turning fork off in the Javadoc task?  Is this legal or do we prevent it
in the code?

Again, I would be happy to make this change if people think it is a good

> (like the JUnit task I submitted and my metamata task, which will be sent to this list
> and others we are about to create).

I am looking forward to giving your Junit task a test drive.

Jay Handfield

View raw message