defaultTasks incompatible with '--refresh dependencies'


(Matias Bjarland) #1

it seems that if you have a:

defaultTasks 'foo', 'bar'

defined in gradle 1.0-milestone-8 and you execute:

gradle --refresh dependencies

gradle does not sem consider ‘dependencies’ to be a task and goes on to execute the default tasks anyway.

Due to the dependency cache issues in m8 in m8 we need to execute a ‘–refresh dependencies’ before each build for every project on our CI server…otherwise the builds reported dependencies missing. We have now removed the defaultTasks declarations but I think this behavior is a bit unintuitive.


(Matias Bjarland) #2

I’ll answer my own post. I now understand that the ‘–refresh dependencies’ is a command line switch followed by a command line switch argument. Thus executing “gradle --refresh dependencies” is equivalent to just executing “gradle” with no tasks (as far as task execution is concerned).

Not sure if this is the most intuitive interface as there is an actual “dependencies” task so you could potentially execute “gradle --refresh dependencies dependencies” where the two dependencies strings have totally different meanings. I think this is a potential source of confusion.

My immediate issue is however resolved so we can close this thread.


#3

You have a good point; I’ve been thinking the same thing. We’ll likely replace ‘–refresh dependencies’ with ‘–refresh-dependencies’ (or something similar) for 1.0. We’d simply deprecate the ‘–refresh’ switch.

PS We’re planning to release a bugfix milestone-8a very soon, which will address the serious cache issues in milestone-8.


(Matias Bjarland) #4

Very glad to hear that a bug fix release is on its way! Excellent! We just had a day of mayhem with a structure of dependent projects on our CI server where all the builds were failing to resolve dependencies built by other jobs on the CI server due to the cache issue. We moved to -SNAPSHOT versions of all the projects involved which seemed to solve the issue. We lost a day to insanity but did come away with a better understanding of the gradle cache so not a total loss.

As a side note, I have an additional question which never really got an answer on a previous thread:

is a dependency which has a -SNAPSHOT version already implicitly “{ changing = true }” or are these concepts orthogonal and have nothing to do with each other? I know “changing = true” can be used to force snapshotness for ivy dependencies where as far as I understand ivy does not really support the snapshot concept and we can force the behavior with this setting. Is that the only time we should use “changing = true”? The user guide and dsl docs are a bit thin on this specific setting.


(Luke Daley) #5

It’s better to keep related stuff on the same thread. If this happens again, just put another comment on the original thread and someone should pick it up.


(Matias Bjarland) #6

duly noted, I’ll better my ways.


(Luke Daley) #7

No stress, just trying to keep things neat around here.


#8

The fix is out as a release candidate - can you confirm that it fixes your problem? http://forums.gradle.org/gradle/topics/gradle_1_0_milestone_8a_snapshot_available


(Matias Bjarland) #9

After losing a day and switching to snapshot releases it might take some time before we switch back. We are still in the middle of a long internal release cycle on the projects in question so we might opt for “not fixing it if it aint broke” for a while. We are using the new 8a release and have no other issues so far.


#10

That’s actually what I meant - we have a new m8a release candidate. It’s likely to become an official m8a release early next week.