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.
- 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.
- we should get rid of init. There are plenty of other points in the build lifecycle where you can do this.






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

    http://xircles.codehaus.org/manage_email
  

Reply via email to