compile task configuration - set memoryMaximumSize

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

compile task configuration - set memoryMaximumSize

snesbitt
All:

Noob alert.

I am using the java plugin and the project I am evaluating gradle on requires that I up the memoryMaximumSize in order to complete compilation. This does not appear to be a configuration option directly supported by the compile task (according to both source and the API docs)

So is there an indirect way of setting attributes such as memoryMaximumSize?

Thanks!

Steve Nesbitt
Absaroka Technical Consulting
Reply | Threaded
Open this post in threaded view
|

Re: compile task configuration - set memoryMaximumSize

snesbitt

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.

Is there anyway/would it be a good idea to allow one to attach arbitrary attributes to a Gradle task?

-steve
 
Reply | Threaded
Open this post in threaded view
|

Re: compile task configuration - set memoryMaximumSize

hans_d
Administrator
In reply to this post by snesbitt

On Oct 1, 2008, at 7:56 PM, snesbitt wrote:

>
> All:
>
> Noob alert.
>
> I am using the java plugin and the project I am evaluating gradle on
> requires that I up the memoryMaximumSize in order to complete  
> compilation.
> This does not appear to be a configuration option directly  
> supported by the
> compile task (according to both source and the API docs)
>
> So is there an indirect way of setting attributes such as  
> memoryMaximumSize?

The default behavior of Gradle is not to fork javac. This is just  
because it is the same as Ant behave. I'm not sure if this is a good  
default.

Anyway. There are two ways to solve your problem. The first is to  
fork javac and pass proper arguments to the forked JVM:

compile.options.fork(memoryMaximumSize: 512M, memoryInitialSize: 128M)

The second option, if you don't want to fork javac, is to change the  
start up options of the JVM running Gradle. See: http://gradle.org/ 
getting-started.html

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: compile task configuration - set memoryMaximumSize

hans_d
Administrator
In reply to this post by snesbitt

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


Reply | Threaded
Open this post in threaded view
|

Re: compile task configuration - set memoryMaximumSize

snesbitt
>> We definitely have and will have much shorter release cycles.

Shorter release cycles will help, but really can't be guaranteed especially as complexity grows, and the number of plugins - especially thirdparty - supplied grow in number, complexity and usage.

>> 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?

I hadn't really given much thought to implementation, but a namespace would be one way.

The problem that I see now is to do what I suggested requires some iffy assumptions and/or detailed knowledge of the plugin internals. I made the assumption that compile was essentially a call to the ant javac task. In that context my request made sense. Under a different implementation - like direct calls to
javac - my request makes no sense and would be dangerous.

One thing I hated about Maven was the complexity of the plugins and the rigidity in behavior (not to mention bugs).  It wasn't unusual to lose confidence in a plugin and start seriously considering writing one's own - which negated a lot of the value of Maven.

It would be nice if Gradle avoided that "feature" <grin>

Thanks!

-steve

Reply | Threaded
Open this post in threaded view
|

Re: compile task configuration - set memoryMaximumSize

hans_d
Administrator

On Oct 1, 2008, at 10:11 PM, snesbitt wrote:

>
>>> We definitely have and will have much shorter release cycles.
>
> Shorter release cycles will help, but really can't be guaranteed  
> especially
> as complexity grows, and the number of plugins - especially  
> thirdparty -
> supplied grow in number, complexity and usage.

If Eclipse is capable to manage to have a milestone release every 6  
weeks we should also be able to do so. Otherwise something is going  
into a wrong direction.

Third-party plugins have of course their own release cycle.

>
>>> 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?
>
> I hadn't really given much thought to implementation, but a  
> namespace would
> be one way.
>
> The problem that I see now is to do what I suggested requires some  
> iffy
> assumptions and/or detailed knowledge of the plugin internals. I  
> made the
> assumption that compile was essentially a call to the ant javac  
> task. In
> that context my request made sense. Under a different  
> implementation - like
> direct calls to
> javac - my request makes no sense and would be dangerous.

This is transparent. In our case here. 'memoryMaximumSize' is a  
property of the Compile plugin. To be precise of the ForkOptions  
class. This property has the same name as the Ant task property but  
is a property on its own. So if we move from Ant javac to plain javac  
this is an internal implementation change and would not change our  
API. What this internal change would allow though, is to provide an  
'additionalArguments' property. So if Java X would introduce a new  
option for javac you would not have to wait for a new Gradle release  
to use it. The Ant javac task does not provide such a generic property.

>
> One thing I hated about Maven was the complexity of the plugins and  
> the
> rigidity in behavior (not to mention bugs).  It wasn't unusual to lose
> confidence in a plugin and start seriously considering writing  
> one's own -
> which negated a lot of the value of Maven.
>
> It would be nice if Gradle avoided that "feature" <grin>

This is a good point which points to a fundamental problem of Maven  
and the rigidity of XML based build scripts/declarations. You might  
view a plugin/task as a little framework to solve a certain domain.  
Frameworks are rigid by definition. If they are too rigid to solve  
your problem the alternative is to use toolsets instead. But for  
working with toolsets you need a real language to use them, this is  
not possible with XML. The philosophy of Gradle is to provide small  
frameworks for the major usecases. If this does not work out, you can  
fall back to toolsets used with Groovy.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email