Hans Dockter wrote:
I have just committed a fix for Gradle-220 (Provide control to the user
if and how project dependencies should be rebuild).
With -a or --no-rebuild you can now disable that project dependencies
are build at all. Of course this works only if the project dependencies
have been build before and are accessible in the
./gradle/internal-repository cache.
With gradle -Ajavadoc -Atest you can specify additional tasks that
should be run when building project dependencies. For 0.7 we plan to
make our command line smarter and more expressive. Jon Cox and Steve
Appling have made very interesting proposals. So this syntax is likely
to change with 0.7. It is pretty basic anyhow and does not allow for
fine-grained control. But it solves the most urgent pain.
I have run into one rather fundamental issue. Task dependencies are not
ordered. They are not a LinkedHashSet or a List.
With Gradle-220 I have the following use case: Let's say you want that
project-dependencies are build with a clean:
Project A (has a compile dependency on Project B)
gradle -Aclean compile
The problem is that clean is not necessarily executed as the first task
when building B. Which of course leads to a failing build. For other
tasks (e.g. javadoc) this is not an issue, as it has no side-effects.
I'm wondering what to do here. This also relates to:
http://jira.codehaus.org/browse/GRADLE-427 dependsOn doesn't respect
dependency order
One approach would be to have an ordered set for dependsOn tasks and
they are executed in this order (of course only as long as they are not
part of other dependsOn relations).
Thoughts?
- Hans
GREAT!!! - the '-a' option really helps with a multi-module system. I have
updated our fork to include this change and tried it out. It seems to work great.
I think that having an ordered set of dependencies will solve GRADLE-427 and
that is how I would like (and expect) multiple dependencies to work (this is
similar to how ant works).
Is the intent for -A to always add the dependency to the start of the list?
That is what you would like for "-A clean", but I'm not sure if that is always
the case.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
