On Oct 1, 2008, at 8:48 PM, snesbitt wrote:
Ok - I found one answer - not sure if it is the simplest.
compile.getOptions().fork([memoryMaximumSize:"256m"])
One things concerns me here - the fact that there appears to be a
direct,
explicitly defined mapping between the javac attributes defined by
Ant and
the options supported by the the java plugin compile task. My
concern here
is that this means that any new release of Ant will require that
all plugins
be updated to reflect removed/new attributes.
For example, if in Ant 1.7.+ the javac Ant task adds a new
attribute will I
have to wait for someone to update the plugin to support the new
attribute?
If this is so, then IMHO gradle has a "heavy wrapper" problem
similar to
what I saw in Maven 1.0 where it could take months (actually years)
between
the time of a new Ant release and Maven support of the new features.
We definitely have and will have much shorter release cycles. But you
still make a valid point. In the not too distant future we plan to
get rid of our Ant dependency here and the Gradle task will call
javac directly.
Is there anyway/would it be a good idea to allow one to attach
arbitrary
attributes to a Gradle task?
If definitely would make sense to be able to assign arbitrary
attributes for the forked JVM and the call to javac. In general I'm
not sure. The feature you are proposing would simply create a
namespace for each task, right?
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
