ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Haas <thomas.h...@softwired-inc.com>
Subject Re: [PATCH]: Added maxmemory option to javadoc task
Date Thu, 23 Mar 2000 19:34:07 GMT


Jay Handfield wrote:

> 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
> account.)
>
> What do other people think?  I would be happy to implement any changes
> people think we need.

Solution 2) and 3) look both very promising. As Sam Ruby pointed out in another email, disabling
the call to fork can be done in the subclass.
If you are going to hack on the Exec/Java task, I have other suggestions (and I am willing
to help
implementing):

   * Implement the funcionality of Exec/Java in a seperate class not inheriting from Taskdef
so it
     can be used in others. Rational: The Javac and Jikes tasks reimplement features of  Java,
     because they extend MatchingTask and multiple inhertiance is not possible.
   * Exec should use Runtime.exec(String[]) instead of Runtime.exec(String), which would eliminate
     the need for the runAnt shell script and ease using arguments with spaces.
   * Subtaskes should be able to put filters on the output/inputstream to/from the spawned
     processes. Jikes could profit from this.

- tom





Mime
View raw message