Adam Murdoch wrote:
Steve Appling wrote:
My confusion over how to determine the dependencies for optimizing
tasks was not actually a problem with the API to determine
dependencies, but a misunderstanding of how the dependencies were
declared. I do think, however, that it may be a good idea to make
some changes in the dependency relationships.
The current dependency chain established by the java plugin does not
really specify which tasks need as their input, the output of another
task. The current dependency chain is just establishes a "lifecycle"
of tasks that will be executed in a particular order. For example,
processTestResources currently depends on compile, not because the
processTestResources task is really dependent on compile, but just to
fit the task in a lifecycle order.
I would rather see a task A really only depend on task B if task A
will consume the the output of task B in some manner. I think that
this does really help with automatic optimization. This also fits in
nicely with Adam's ideas about a dependency chain based off of
input/output artifacts.
With that in mind, I would like to see the dependencies for the java
plugin tasks changed as shown in the attached image.
This is a good idea, with a few tweaks:
- jar should depend on compile as well as processResources.
You're right, that's what I intended, but that line didn't make it from my white
board to the drawing :(
- jar should probably not depend on test. I'm not sure what we should do
with it. Perhaps libs or upload* should depend on test instead.
I'm not sure what your intent is here. I think you still want to run tests as
part of making the artifact. What would be accomplished by moving the test
dependency up to libs? Currently the uploadDefaultInternal task used to resolve
dependencies on other projects is associated with the jar (not the libs) task,
so moving the dependency up to libs would keep tests from running in other
dependent projects. Is this your intent?
Thinking through this is helping me understand some of your original ideas for
more of a I/O centered dependency declaration. I actually see two different
types of dependencies here. One is a producer/consumer type of dependency where
a task consumes the output of another task. The other is just a task ordering
type of dependency. For example, jar has a producer/consumer dependency on both
processResources and compile, but has an ordering dependency on test. We simply
want the tests to run successfully before the jar is made, but there are no
outputs or side effects from the test task that are consumed by the jar task.
This distinction helps with the optimization. You want to run a task if any of
it's producer/consumer dependencies didWork. You don't really care if the
ordering dependencies didWork.
I will make a patch with the changes to dependency as shown in the diagram (with
Adam's correction). I would, however, like to see more work on this other way
of expressing task dependencies in a future version (perhaps 0.8). I can
visualize this a little better now - a ProducerConsumer dependency is more like
a new specialized type of configuration.
- we should get rid of init. There are plenty of other points in the
build lifecycle where you can do this.
Great.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
