On Wednesday 07 April 2010 22:34:03, Adam Murdoch wrote:
> On 5/04/10 1:17 PM, Geronimo M. H. wrote:
> > Am Sunday 04 April 2010 23:44:10 schrieb Adam Murdoch:
> >> On 3/04/10 3:55 AM, Spencer Allain wrote:
> >>> The "<<" form is confusing enough. Having the first hello world
> >>> example state that it's equivalent to doFirst will only lead to later
> >>> confusion once a user learns about doFirst and doLast.
> >>
> >> I think we should look at deprecating the '<<' form after the Gradle 0.9
> >> release. And possibly doFirst() and doLast() too, so that a task has
> >> only 1 action.
> >
> > I vote against reducing the number of (possible) task-actions and against
> > the removal of doFirst() and doLast().
>
> I didn't phrase that very well. I meant that we should replace these
> things with alternatives which are more expressive or more powerful or
> both. So, this time, here's too much detail, rather than too little detail:
Thank you very much for taking the time of that detailed description!
I like the concept of tasks and actions, whereas to me the job of copiing one
or more files is an action, as well as compiling a file, or creating an
archive.
From my point of view, the action has the responsability to determine, whether
it is up-to-date - but it does not know anything about other actions.
The compile-action is something quite special. Here the action can determine,
whether a single file is up-to-date, but the task has to determine the
dependency-graph for compilation units, which means, that the task may
overwrite the result of an actions up-to-date.
If I understand things right, ant uses target-definitions as task-containers,
whereas gradle uses the dependency graph of tasks. The latter is more
flexible, but harder to implement - and of cause needs more evaluation time.
That would be quite acceptable, if the user benefits from the flexibility,
which means, an incremental job, that takes longer than the complete job will
be very little acceptable.
(May be, it would be worth to think about stored dependency graphs for
compilation units. I know this concept from embedded gcc, where the makefile
contains a special target "depends" and executing "make depends" will have
gcc to change the makefile by adding the dependencies for each compilation
unit.)
From the end-users point of view, I like the concept of plugins, that
implement a bunch of task with dependencies.
What I need (no matter how you name it) is:
1. the possibility to attach an action to another action, without having to
care about the tasks, that action is part of. It should be choosable, whether
the new action should be executed before or after the original action.
(Sample: I have a script, that checks my sources for copyright headers. I'd
like that script to be executed before a file is compiled. On the other side
I attached a copy-action to a jarfile-creation, which should be executed
after the jarfile-creation. In incremental szenarios, both attached actions
should follow the up-to-date rules of the original action)
2. Change/overwrite configuration of tasks
3. Change dependency graph of tasks. Adding a new dependency is nice but
trivial. I'd like to additionally change existing dependency graph: supposing
a taskA depending on taskB, I'd like to add a taskAB with dependency to taskB
that breaks the dependency from taskA to taskB and add a dependency of taskA
to taskAB (like an insert operation on a linked list).
I'd also like the possibility to disable a task from a dependency graph:
supposing taskA depends on taskB, which depends on taskC - If I disable taskB,
taskA should depend on taskC (like an delete operation on a linked list)
4. It would be nice to output/print a complete dependency graph (just to
understand things better)
I prefer the declarative style too.
For simple actions, it might be handy to additionally have the possibility to
declare a task as a number of actions:
task mySimpleTask {
incremental = false
copy {
...
}
jar {
...
}
exec {
...
}
}
This way, the user disables the incremental ability of gradle and implements
a "stupid" number-of-action-task in the sense of ant target definition.
In my situation, I would like this kind of definitions to build the
installers. They are build for integration tests or releases only and in that
special case, I'm not interested in incremental build but do a clean build to
verify, that I did not forget any dependency.
kind regards
Geronimo
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
