Re: Java Plugin Task Dependencies

>
>
> 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).