On 09/11/2011, at 2:16 AM, Szczepan Faber wrote:
> On Tue, Nov 8, 2011 at 6:26 AM, Adam Murdoch <[email protected]>
> wrote:
> Hi,
>
> 1. Should the forced version be applied to the parent pom of a given pom? For
> example, if someGroup:someArtifact:1.2 declares a parent pom of
> someGroup:someParent:72, and we force someGroup:someParent:80, which version
> of someParent should be used?
>
> I would think we should use the parent declared in the pom in this instance.
>
> I'm assuming the rationale is that parent poms are different than regular
> classpath dependencies, e.g. do not incur traditional version conflicts?
It's more a correctness issue. You can think of our dependency resolution
pipeline has having 3 broad stages:
meta-data mutation (forcing, exclusions, etc) -> meta-data cache -> repository
We want the cache to contain the original meta-data, so that if the mutations
change (or the cache is used in another project), we use the correct meta-data.
Parent poms are special, in that the meta-data for a module version is smeared
across the pom and all its ancestors. If we were to force an ancestor pom
version, we would be caching the wrong stuff. If we can avoid doing this,
everything is much simpler.
>
> I don't see why forcing pom version would be harmful. Adding extra code to
> block this functionality feels 'frameworkish' and I probably wouldn't do it
> unless there is a use case. (Similarly, I wouldn't add extra code to enable
> this functionality).
It's the other way around. I believe things currently work the way we want, and
we'd have to add extra code to allow you to force the parent pom. I think we
just need an integration test to make sure this is the case, and to lock it
down until a use-case comes along.
> If someone does not want to force resolving particular pom version he simply
> doesn't have to do it :)
>
> Chance is I don't understand the use case well enough - can you elaborate it
> a bit? Are there any internal details that make the case for it?
>
> Anyway, feels like everyone likes the idea so I'm fine playing along :)
>
>
> 2. Should you be able to specify a dynamic version for the forced version?
> Something like:
>
> configurations.compile.resolveStrategy.force("group:module:latest.integration")
>
> I would think you should be able to (and probably can at the moment). In
> which case we should change the type of ResolutionStrategy.forcedModules to
> be something other than ModuleIdentifier, probably a new interface called
> ModuleSelector.
>
> Good point, ModuleIdentifier is no good. I'm wondering if we should aim for
> more specific, self-describing interfaces that catch the essence better. E.g.
> how about a 'ForcedModule' or 'ForcedSomething' interface (that can extend
> ModuleSelector if the that generalization is also needed).
It's not the actual forced version. It's a selector, or set of criteria, for
the version or versions we should consider for a given module. We may extend
this to include criteria on attributes other than version: for example, 'only
consider released versions', or 'only consider those architectures which are
compatible with the current platform'. The generalisation is required right
now, as ExternalDependency also is-a (or has-a) one of these things. I would
call it something like a ModuleVersionSelector to reflect what it actually is.
>
> Also, if the changing versions are already possible then we need a coverage
> for it.
We need coverage either way: if we support it, we need an int test that shows
it works. If not, we need an int test that shows you get a nice error message
when you accidentally use a dynamic version.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
