Accessing the DAG

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

Accessing the DAG

Adam Murdoch-2
Hi,

I'm looking at adding a public interface for DAG in org.gradle.api.**,
so that it can be documented (and grown). I have some questions about
which DAG methods we want to make public, and how build files should get
at it.

At this stage, the only methods on DAG which look public to me are:
boolean hasTask(path)
Set<Task> getAllTasks()

I'd like to add some events as well, so that one can listen for the
start and end of execution of a task. I would start with a
TaskExecutionListener interface, and possibly add Closure based
convenience methods later. For example:

interface TaskExecutionListener {
    void beforeExecute(Task task)
    void afterExecute(Task task)
}

And later, something like

taskGraph.beforeTask { task -> do something }
taskGraph.afterTask { task -> do something }

It might be interesting to add some DAG mutation methods at some point.
For example, I'd like to be able to request the execution of a task from
another task.

As far as access from build files goes, I think we are missing a good
place to hang this from. It would make sense to attach the DAG to the
object which represents the build execution as a whole, but we don't
really have such a concept. Settings plays this role for the
initialisation phase. Build is possibly the right place, but it lacks a
public api, and build files can't access it.

I think we should add an interface to the public api which wraps up the
whole build execution, called something like GradleInstance or Build. It
would be reachable from Project, using, for example,
Project.getGradleInstance()

This interface would have methods something like:

getTaskExecutionGraph()
getRootProject()
addBuildListener(BuildListener)

Some other things that could live here are gradle version, gradle home,
user home, and methods for executing a new build.

The DAG is currently passed as a method to TaskAction.execute() and is
also reachable from Task. Should we remove it from TaskAction.execute()?
If we do the above, should we remove it from Task as well? If not,
should we add it to Project and ProjectAction for consistency?


Adam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Accessing the DAG

hans_d
Administrator

On Sep 13, 2008, at 8:51 AM, Adam Murdoch wrote:

> Hi,
>
> I'm looking at adding a public interface for DAG in  
> org.gradle.api.**, so that it can be documented (and grown). I have  
> some questions about which DAG methods we want to make public, and  
> how build files should get at it.

This is important. I have been slack in regard to this.

>
> At this stage, the only methods on DAG which look public to me are:
> boolean hasTask(path)
> Set<Task> getAllTasks()
>
> I'd like to add some events as well, so that one can listen for the  
> start and end of execution of a task. I would start with a  
> TaskExecutionListener interface, and possibly add Closure based  
> convenience methods later. For example:
>
> interface TaskExecutionListener {
>    void beforeExecute(Task task)
>    void afterExecute(Task task)
> }
>
> And later, something like
>
> taskGraph.beforeTask { task -> do something }
> taskGraph.afterTask { task -> do something }

Our future IDE's will happily use this to start and stop a rolling  
wheel for a task :)

>
> It might be interesting to add some DAG mutation methods at some  
> point. For example, I'd like to be able to request the execution of  
> a task from another task.

Do you see this as a solution for the doFinally?

>
> As far as access from build files goes, I think we are missing a  
> good place to hang this from. It would make sense to attach the DAG  
> to the object which represents the build execution as a whole, but  
> we don't really have such a concept. Settings plays this role for  
> the initialisation phase. Build is possibly the right place, but it  
> lacks a public api, and build files can't access it.
>
> I think we should add an interface to the public api which wraps up  
> the whole build execution, called something like GradleInstance or  
> Build. It would be reachable from Project, using, for example,  
> Project.getGradleInstance()
>
> This interface would have methods something like:
>
> getTaskExecutionGraph()
> getRootProject()
> addBuildListener(BuildListener)

I like this.

>
> Some other things that could live here are gradle version, gradle  
> home, user home, and methods for executing a new build.
>
> The DAG is currently passed as a method to TaskAction.execute() and  
> is also reachable from Task. Should we remove it from  
> TaskAction.execute()? If we do the above, should we remove it from  
> Task as well? If not, should we add it to Project and ProjectAction  
> for consistency?

I was thinking about making the DAG accessible from the project. But  
I thought this might be not such a good idea, as the hasTask and  
getAllTasks methods only have a meaning at execution time. The fact  
that the DAG is a member of the BaseTask is an internal  
implementation detail. So the only public way of accessing the DAG  
right now is via the argument we pass to the TaskAction. If we  
introduce listeners we have to make them of course accessible from  
the project (in a way you described above). The question is whether  
we should expose 'execution time only' methods via this interface.

One limitation of the current solution is that you can only access  
the dag in a task. For example in the Gradle build we access the DAG  
in the init task to decide if we attach a timestamp to the version or  
nor. Every task now has to depends on init if it wants to use the  
version (e.g. userguide creation). This is not nice. See http://
jira.codehaus.org/browse/GRADLE-163. A method for the taskGraph like  
beforeGraphExecution would solve this I think.

I think those listeners are great stuff and with a little bit of work  
towards embaddibility they will make it very easy to write a Gradle  
IDE plugin. Jayson Minard had already a look into writing an IDE  
plugin in 0.2. But our design wasn't ready then.

What we would additionally need in the Build class is:

- a method that returns the task map.
- some filtering of the task map based on projectDir and project.
- exposing the taskGraph object to add listeners.

- 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: Accessing the DAG

Adam Murdoch-2


Hans Dockter wrote:

>
> On Sep 13, 2008, at 8:51 AM, Adam Murdoch wrote:
>
>>
>> It might be interesting to add some DAG mutation methods at some
>> point. For example, I'd like to be able to request the execution of a
>> task from another task.
>
> Do you see this as a solution for the doFinally?
>

Not really, I hadn't really considered that (though it is an interesting
idea). I just wanted it for putting together canned builds coded up as
tasks, eg run 'clean', then 'assemble' with 'test' disabled. And as a
mechanism to allow different ways of arranging the execution of tasks
which we haven't foreseen.

>>
>> The DAG is currently passed as a method to TaskAction.execute() and
>> is also reachable from Task. Should we remove it from
>> TaskAction.execute()? If we do the above, should we remove it from
>> Task as well? If not, should we add it to Project and ProjectAction
>> for consistency?
>
> I was thinking about making the DAG accessible from the project. But I
> thought this might be not such a good idea, as the hasTask and
> getAllTasks methods only have a meaning at execution time. The fact
> that the DAG is a member of the BaseTask is an internal implementation
> detail. So the only public way of accessing the DAG right now is via
> the argument we pass to the TaskAction. If we introduce listeners we
> have to make them of course accessible from the project (in a way you
> described above). The question is whether we should expose 'execution
> time only' methods via this interface.
>

I did wonder about this. Even though some information makes sense only
at execution time, it doesn't really make sense to me that you get at
this information via a parameter on a TaskAction. It's not really
something particular to a Task. It's information about the build as a
whole, so it feels to me like something that should hang off an object
that represents the build.

I was thinking of having the methods visible from Project, but have them
throw an exception of some kind when used before the graph had been
assembled.

> One limitation of the current solution is that you can only access the
> dag in a task. For example in the Gradle build we access the DAG in
> the init task to decide if we attach a timestamp to the version or
> nor. Every task now has to depends on init if it wants to use the
> version (e.g. userguide creation). This is not nice. See
> http://jira.codehaus.org/browse/GRADLE-163. A method for the taskGraph
> like beforeGraphExecution would solve this I think.
>
> I think those listeners are great stuff and with a little bit of work
> towards embaddibility they will make it very easy to write a Gradle
> IDE plugin. Jayson Minard had already a look into writing an IDE
> plugin in 0.2. But our design wasn't ready then.
>
> What we would additionally need in the Build class is:
>
> - a method that returns the task map.
> - some filtering of the task map based on projectDir and project.
> - exposing the taskGraph object to add listeners.
>

I was thinking of adding an accessor to Build to get at the
GradleInstance interface (or whatever it is called), so that the same
stuff is available to the thing embedding Gradle as to the build files.
Which I think also includes all the stuff above. We should perhaps split
Build.run() into an initialisation method and an execution method, so
that a plugin could load up the settings once, do stuff with the
GradleInstance, then run tasks a bunch of times.


Adam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Accessing the DAG

hans_d
Administrator

On Sep 14, 2008, at 1:01 PM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>>
>> On Sep 13, 2008, at 8:51 AM, Adam Murdoch wrote:
>>
>>>
>>> It might be interesting to add some DAG mutation methods at some  
>>> point. For example, I'd like to be able to request the execution  
>>> of a task from another task.
>>
>> Do you see this as a solution for the doFinally?
>>
>
> Not really, I hadn't really considered that (though it is an  
> interesting idea). I just wanted it for putting together canned  
> builds coded up as tasks, eg run 'clean', then 'assemble' with  
> 'test' disabled. And as a mechanism to allow different ways of  
> arranging the execution of tasks which we haven't foreseen.

Sound really interesting. I have to think about this more deeply.

>
>>>
>>> The DAG is currently passed as a method to TaskAction.execute()  
>>> and is also reachable from Task. Should we remove it from  
>>> TaskAction.execute()? If we do the above, should we remove it  
>>> from Task as well? If not, should we add it to Project and  
>>> ProjectAction for consistency?
>>
>> I was thinking about making the DAG accessible from the project.  
>> But I thought this might be not such a good idea, as the hasTask  
>> and getAllTasks methods only have a meaning at execution time. The  
>> fact that the DAG is a member of the BaseTask is an internal  
>> implementation detail. So the only public way of accessing the DAG  
>> right now is via the argument we pass to the TaskAction. If we  
>> introduce listeners we have to make them of course accessible from  
>> the project (in a way you described above). The question is  
>> whether we should expose 'execution time only' methods via this  
>> interface.
>>
>
> I did wonder about this. Even though some information makes sense  
> only at execution time, it doesn't really make sense to me that you  
> get at this information via a parameter on a TaskAction. It's not  
> really something particular to a Task. It's information about the  
> build as a whole, so it feels to me like something that should hang  
> off an object that represents the build.
>
> I was thinking of having the methods visible from Project, but have  
> them throw an exception of some kind when used before the graph had  
> been assembled.

I don't feel strong about this. An exception would definitely make  
sense. We should also throw an exception if dependsOn is called  
during execution time.

>
>> One limitation of the current solution is that you can only access  
>> the dag in a task. For example in the Gradle build we access the  
>> DAG in the init task to decide if we attach a timestamp to the  
>> version or nor. Every task now has to depends on init if it wants  
>> to use the version (e.g. userguide creation). This is not nice.  
>> See http://jira.codehaus.org/browse/GRADLE-163. A method for the  
>> taskGraph like beforeGraphExecution would solve this I think.
>>
>> I think those listeners are great stuff and with a little bit of  
>> work towards embaddibility they will make it very easy to write a  
>> Gradle IDE plugin. Jayson Minard had already a look into writing  
>> an IDE plugin in 0.2. But our design wasn't ready then.
>>
>> What we would additionally need in the Build class is:
>>
>> - a method that returns the task map.
>> - some filtering of the task map based on projectDir and project.
>> - exposing the taskGraph object to add listeners.
>>
>
> I was thinking of adding an accessor to Build to get at the  
> GradleInstance interface (or whatever it is called), so that the  
> same stuff is available to the thing embedding Gradle as to the  
> build files. Which I think also includes all the stuff above. We  
> should perhaps split Build.run() into an initialisation method and  
> an execution method, so that a plugin could load up the settings  
> once, do stuff with the GradleInstance, then run tasks a bunch of  
> times.

This kind of embedded usage is already of interest. For example we  
could provide a Gradle UI console then. By using this console you  
would avoid the constant startup time penalty of Groovy. An  
interesting question is whether you can reuse a evaluated project  
tree. It is possible to modify this tree at execution time (although  
probably rather unlikely). If this happens the tree can't be reused.  
Right now we have this dagNeutral task property, where the task can  
declare if it modifies the tree at execution time or not. Right now  
the default is false, we might change it to true.

It would be cool if it were possible to persist the evaluated tree.  
That way we could cache it also for normal console usage. But Groovy  
1.5 does not allow to serialize closures. And even if, in many cases  
not all objects in the project tree would be seralizable. And I don't  
see any other means for persisting the tree than serialization.

- 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: Accessing the DAG

Adam Murdoch-2


Hans Dockter wrote:

>
> On Sep 14, 2008, at 1:01 PM, Adam Murdoch wrote:
>
>>
>>
>> Hans Dockter wrote:
>>>
>>> On Sep 13, 2008, at 8:51 AM, Adam Murdoch wrote:
>>>
>>>>
>>>> It might be interesting to add some DAG mutation methods at some
>>>> point. For example, I'd like to be able to request the execution of
>>>> a task from another task.
>>>
>>> Do you see this as a solution for the doFinally?
>>>
>>
>> Not really, I hadn't really considered that (though it is an
>> interesting idea). I just wanted it for putting together canned
>> builds coded up as tasks, eg run 'clean', then 'assemble' with 'test'
>> disabled.

This is really the 'build type' concept which I described (vaguely) in
another email. I'm not sure of the semantics yet, but basically I want
to code up canned builds which are variations of the build as declared
in the build file.

>>
>>>>
>>>> The DAG is currently passed as a method to TaskAction.execute() and
>>>> is also reachable from Task. Should we remove it from
>>>> TaskAction.execute()? If we do the above, should we remove it from
>>>> Task as well? If not, should we add it to Project and ProjectAction
>>>> for consistency?
>>>
>>> I was thinking about making the DAG accessible from the project. But
>>> I thought this might be not such a good idea, as the hasTask and
>>> getAllTasks methods only have a meaning at execution time. The fact
>>> that the DAG is a member of the BaseTask is an internal
>>> implementation detail. So the only public way of accessing the DAG
>>> right now is via the argument we pass to the TaskAction. If we
>>> introduce listeners we have to make them of course accessible from
>>> the project (in a way you described above). The question is whether
>>> we should expose 'execution time only' methods via this interface.
>>>
>>
>> I did wonder about this. Even though some information makes sense
>> only at execution time, it doesn't really make sense to me that you
>> get at this information via a parameter on a TaskAction. It's not
>> really something particular to a Task. It's information about the
>> build as a whole, so it feels to me like something that should hang
>> off an object that represents the build.
>>
>> I was thinking of having the methods visible from Project, but have
>> them throw an exception of some kind when used before the graph had
>> been assembled.
>
> I don't feel strong about this. An exception would definitely make
> sense. We should also throw an exception if dependsOn is called during
> execution time.
>

Or handle it. It's only a problem if the task has already executed or is
currently executing (or introduces a cycle).

>>> One limitation of the current solution is that you can only access
>>> the dag in a task. For example in the Gradle build we access the DAG
>>> in the init task to decide if we attach a timestamp to the version
>>> or nor. Every task now has to depends on init if it wants to use the
>>> version (e.g. userguide creation). This is not nice. See
>>> http://jira.codehaus.org/browse/GRADLE-163. A method for the
>>> taskGraph like beforeGraphExecution would solve this I think.
>>>
>>> I think those listeners are great stuff and with a little bit of
>>> work towards embaddibility they will make it very easy to write a
>>> Gradle IDE plugin. Jayson Minard had already a look into writing an
>>> IDE plugin in 0.2. But our design wasn't ready then.
>>>
>>> What we would additionally need in the Build class is:
>>>
>>> - a method that returns the task map.
>>> - some filtering of the task map based on projectDir and project.
>>> - exposing the taskGraph object to add listeners.
>>>
>>
>> I was thinking of adding an accessor to Build to get at the
>> GradleInstance interface (or whatever it is called), so that the same
>> stuff is available to the thing embedding Gradle as to the build
>> files. Which I think also includes all the stuff above. We should
>> perhaps split Build.run() into an initialisation method and an
>> execution method, so that a plugin could load up the settings once,
>> do stuff with the GradleInstance, then run tasks a bunch of times.
>
> This kind of embedded usage is already of interest. For example we
> could provide a Gradle UI console then. By using this console you
> would avoid the constant startup time penalty of Groovy. An
> interesting question is whether you can reuse a evaluated project
> tree. It is possible to modify this tree at execution time (although
> probably rather unlikely). If this happens the tree can't be reused.

Hmm, good point. Strictly speaking we can't even reuse the settings
object. We can certainly have the scripts compiled up and classes loaded
ready to evaluate.

I'm not sure if the actual evaluation time is that big a deal, relative
to the total build time. I'm more interested in gradle not building
things that haven't changed since last time I ran the build, and for
robustly detecting things that have changed, so that I don't have to do
a clean before I build.


Adam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Accessing the DAG

hans_d
Administrator

On Sep 15, 2008, at 11:02 PM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>>
>> On Sep 14, 2008, at 1:01 PM, Adam Murdoch wrote:
>>
>>>
>>>
>>> Hans Dockter wrote:
>>>>
>>>> On Sep 13, 2008, at 8:51 AM, Adam Murdoch wrote:
>>>>
>>>>>
>>>>> It might be interesting to add some DAG mutation methods at  
>>>>> some point. For example, I'd like to be able to request the  
>>>>> execution of a task from another task.
>>>>
>>>> Do you see this as a solution for the doFinally?
>>>>
>>>
>>> Not really, I hadn't really considered that (though it is an  
>>> interesting idea). I just wanted it for putting together canned  
>>> builds coded up as tasks, eg run 'clean', then 'assemble' with  
>>> 'test' disabled.
>
> This is really the 'build type' concept which I described (vaguely)  
> in another email. I'm not sure of the semantics yet, but basically  
> I want to code up canned builds which are variations of the build  
> as declared in the build file.
>
>>>
>>>>>
>>>>> The DAG is currently passed as a method to TaskAction.execute()  
>>>>> and is also reachable from Task. Should we remove it from  
>>>>> TaskAction.execute()? If we do the above, should we remove it  
>>>>> from Task as well? If not, should we add it to Project and  
>>>>> ProjectAction for consistency?
>>>>
>>>> I was thinking about making the DAG accessible from the project.  
>>>> But I thought this might be not such a good idea, as the hasTask  
>>>> and getAllTasks methods only have a meaning at execution time.  
>>>> The fact that the DAG is a member of the BaseTask is an internal  
>>>> implementation detail. So the only public way of accessing the  
>>>> DAG right now is via the argument we pass to the TaskAction. If  
>>>> we introduce listeners we have to make them of course accessible  
>>>> from the project (in a way you described above). The question is  
>>>> whether we should expose 'execution time only' methods via this  
>>>> interface.
>>>>
>>>
>>> I did wonder about this. Even though some information makes sense  
>>> only at execution time, it doesn't really make sense to me that  
>>> you get at this information via a parameter on a TaskAction. It's  
>>> not really something particular to a Task. It's information about  
>>> the build as a whole, so it feels to me like something that  
>>> should hang off an object that represents the build.
>>>
>>> I was thinking of having the methods visible from Project, but  
>>> have them throw an exception of some kind when used before the  
>>> graph had been assembled.
>>
>> I don't feel strong about this. An exception would definitely make  
>> sense. We should also throw an exception if dependsOn is called  
>> during execution time.
>>
>
> Or handle it. It's only a problem if the task has already executed  
> or is currently executing (or introduces a cycle).
>
>>>> One limitation of the current solution is that you can only  
>>>> access the dag in a task. For example in the Gradle build we  
>>>> access the DAG in the init task to decide if we attach a  
>>>> timestamp to the version or nor. Every task now has to depends  
>>>> on init if it wants to use the version (e.g. userguide  
>>>> creation). This is not nice. See http://jira.codehaus.org/browse/ 
>>>> GRADLE-163. A method for the taskGraph like beforeGraphExecution  
>>>> would solve this I think.
>>>>
>>>> I think those listeners are great stuff and with a little bit of  
>>>> work towards embaddibility they will make it very easy to write  
>>>> a Gradle IDE plugin. Jayson Minard had already a look into  
>>>> writing an IDE plugin in 0.2. But our design wasn't ready then.
>>>>
>>>> What we would additionally need in the Build class is:
>>>>
>>>> - a method that returns the task map.
>>>> - some filtering of the task map based on projectDir and project.
>>>> - exposing the taskGraph object to add listeners.
>>>>
>>>
>>> I was thinking of adding an accessor to Build to get at the  
>>> GradleInstance interface (or whatever it is called), so that the  
>>> same stuff is available to the thing embedding Gradle as to the  
>>> build files. Which I think also includes all the stuff above. We  
>>> should perhaps split Build.run() into an initialisation method  
>>> and an execution method, so that a plugin could load up the  
>>> settings once, do stuff with the GradleInstance, then run tasks a  
>>> bunch of times.
>>
>> This kind of embedded usage is already of interest. For example we  
>> could provide a Gradle UI console then. By using this console you  
>> would avoid the constant startup time penalty of Groovy. An  
>> interesting question is whether you can reuse a evaluated project  
>> tree. It is possible to modify this tree at execution time  
>> (although probably rather unlikely). If this happens the tree  
>> can't be reused.
>
> Hmm, good point. Strictly speaking we can't even reuse the settings  
> object.

Why?

> We can certainly have the scripts compiled up and classes loaded  
> ready to evaluate.

We have them already compiled in the cache on disk. But keeping them  
in memory would be another optimization.

>
> I'm not sure if the actual evaluation time is that big a deal,  
> relative to the total build time.

In most cases not. In particular as I'm pretty sure that we could  
still do significant performance tuning for this evaluation. The only  
big performance issue I would like to resolve soon is that the build  
source jar is not cached.

> I'm more interested in gradle not building things that haven't  
> changed since last time I ran the build, and for robustly detecting  
> things that have changed, so that I don't have to do a clean before  
> I build.

This would definitely be a real time saver.

What do you think about this issue in this context? http://
jira.codehaus.org/browse/GRADLE-66

- 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: Accessing the DAG

Adam Murdoch-2


Hans Dockter wrote:

>
>>>>
>>>> I was thinking of adding an accessor to Build to get at the
>>>> GradleInstance interface (or whatever it is called), so that the
>>>> same stuff is available to the thing embedding Gradle as to the
>>>> build files. Which I think also includes all the stuff above. We
>>>> should perhaps split Build.run() into an initialisation method and
>>>> an execution method, so that a plugin could load up the settings
>>>> once, do stuff with the GradleInstance, then run tasks a bunch of
>>>> times.
>>>
>>> This kind of embedded usage is already of interest. For example we
>>> could provide a Gradle UI console then. By using this console you
>>> would avoid the constant startup time penalty of Groovy. An
>>> interesting question is whether you can reuse a evaluated project
>>> tree. It is possible to modify this tree at execution time (although
>>> probably rather unlikely). If this happens the tree can't be reused.
>>
>> Hmm, good point. Strictly speaking we can't even reuse the settings
>> object.
>
> Why?
>

It depends on the timeframe of the reuse. Strictly speaking, we
shouldn't reuse if the settings script depends on something
environmental that is likely to have changed since we evaluated the
script. For example, if the script includes all projects in a directory
and one is added or removed. Or, if it declares a dependency on
'latest.integration' of some custom plugin and a new version becomes
available.

The question is whether we care about such use cases in a Gradle UI. For
a long running UI such as an ide plugin, I think we do. Though, again, I
don't think it's really a bit hit to re-evaluate the settings given the
script has been compiled and cached.

>>
>> I'm not sure if the actual evaluation time is that big a deal,
>> relative to the total build time.
>
> In most cases not. In particular as I'm pretty sure that we could
> still do significant performance tuning for this evaluation. The only
> big performance issue I would like to resolve soon is that the build
> source jar is not cached.
>

Yes, a good idea.

>> I'm more interested in gradle not building things that haven't
>> changed since last time I ran the build, and for robustly detecting
>> things that have changed, so that I don't have to do a clean before I
>> build.
>
> This would definitely be a real time saver.
>
> What do you think about this issue in this context?
> http://jira.codehaus.org/browse/GRADLE-66
>

I think having a reliable compile task would be excellent.


Adam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Accessing the DAG

hans_d
Administrator

On Sep 17, 2008, at 11:56 AM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>>
>>>>>
>>>>> I was thinking of adding an accessor to Build to get at the  
>>>>> GradleInstance interface (or whatever it is called), so that  
>>>>> the same stuff is available to the thing embedding Gradle as to  
>>>>> the build files. Which I think also includes all the stuff  
>>>>> above. We should perhaps split Build.run() into an  
>>>>> initialisation method and an execution method, so that a plugin  
>>>>> could load up the settings once, do stuff with the  
>>>>> GradleInstance, then run tasks a bunch of times.
>>>>
>>>> This kind of embedded usage is already of interest. For example  
>>>> we could provide a Gradle UI console then. By using this console  
>>>> you would avoid the constant startup time penalty of Groovy. An  
>>>> interesting question is whether you can reuse a evaluated  
>>>> project tree. It is possible to modify this tree at execution  
>>>> time (although probably rather unlikely). If this happens the  
>>>> tree can't be reused.
>>>
>>> Hmm, good point. Strictly speaking we can't even reuse the  
>>> settings object.
>>
>> Why?
>>
>
> It depends on the timeframe of the reuse. Strictly speaking, we  
> shouldn't reuse if the settings script depends on something  
> environmental that is likely to have changed since we evaluated the  
> script. For example, if the script includes all projects in a  
> directory and one is added or removed. Or, if it declares a  
> dependency on 'latest.integration' of some custom plugin and a new  
> version becomes available.

Of course. That makes sense.

>
> The question is whether we care about such use cases in a Gradle  
> UI. For a long running UI such as an ide plugin, I think we do.  
> Though, again, I don't think it's really a bit hit to re-evaluate  
> the settings given the script has been compiled and cached.
>
>>>
>>> I'm not sure if the actual evaluation time is that big a deal,  
>>> relative to the total build time.
>>
>> In most cases not. In particular as I'm pretty sure that we could  
>> still do significant performance tuning for this evaluation. The  
>> only big performance issue I would like to resolve soon is that  
>> the build source jar is not cached.
>>
>
> Yes, a good idea.
>
>>> I'm more interested in gradle not building things that haven't  
>>> changed since last time I ran the build, and for robustly  
>>> detecting things that have changed, so that I don't have to do a  
>>> clean before I build.
>>
>> This would definitely be a real time saver.
>>
>> What do you think about this issue in this context? http://
>> jira.codehaus.org/browse/GRADLE-66
>>
>
> I think having a reliable compile task would be excellent.

There is a new comment on the issue: http://jira.codehaus.org/browse/ 
GRADLE-66

- Hans

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





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

    http://xircles.codehaus.org/manage_email