Project changes artifact details after resolved as a project dependency

[lptr]

This test fails, and Daz put it on @Ignore for now. We need to fix it before we can merge:

// TODO:PREZI This exposes a bug in our new early-resolve strategy for configurations: project b produces 'b-late.jar', but this isn't included in the configuration
// This means that we're resolving the artifacts for the project dependency early, but not coping with modification to these later
// Need to either detect the change and re-resolve, or delay the artifact resolution

[lptr]

Delaying the resolution looks really messy, as it would require a lazy ID resolution in many places. There's also the serialization of resolved artifacts that would make this even more complicated.

Tracking the modification of project version (and group, as these both influence conflict resolution, too) is also complicated. This particular test case can be fixed by tracking only the dependency project. It's harder to fix this in the transitive case, though, as we need to track changes of transitively dependent projects.

There's a solution for the modification tracking option in dadd43d1b6e4293b204bce864bd550cc98b017a0.

[lptr]

However, this solution with the re-entry check is really ugly. Let's discuss how it can be solved better.

[bigdaz]

I think we might need to have a discussion with Adam to sort this out. My understanding of the underlying problem is that we're resolving the artifact names too early, and that the right approach might be to delay artifact resolution (some parts of it, anyway).

I'll take a deeper look tomorrow and see if I can make more sense of that.

[lptr]

@bigdaz:

I think that tracking changes to the project and re-resolving is not the way to go here. As you mentioned, it's very ugly, and probably not possible to track all cases.

Instead @adammurdoch mentioned that we might need to start to separate the resolution of the dependency graph from the resolution of the artifacts, so that we can resolve the dependencies early but the artifacts late. I'm not sure how this would work, since we'd need the tasks that build the artifacts to be resolved early, so that we have the tasks to create these artifacts.

This is something I might try to tackle on my long-haul flight to San Fran tomorrow night, but I'd need some pointers on how it might look. Adam?

[adammurdoch]

So we are talking about 3 kinds of resolution:

1. Determine the graph
2. Determine the set of task dependencies
3. Determine the set of artefacts.

Both #2 and #3 require #1 first.

To implement #2, we'd simply collect up the set of PublishArtifact instances for the configuration. We don't query anything about them, just collect them and use them (they are Buildable) later.

To implement #3, we do more or less what we do now.

Then, we simply need to detect changes to the set of artefacts and dependencies (which we do already).