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?
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). 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).
Also, if the changing versions are already possible then we need a coverage
for it.
Cheers!
>
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
--
Szczepan Faber
Principal engineer@gradleware
Lead@mockito
