I will try to explain what I want to do with an example:
First, let’s assume that we are using Ivy metadata and we chose a version syntax that:
- does not have a notion of a changing revision (aka SNAPSHOT) - does not have any maturity information in the version (e.g. milestone, rc, etc.)
Then we end up with something like ‘major.minor.micro-timestamp’ for a non-release version (integration or milestone), e.g. ‘1.0.0-20121001’. However since Ivy’s latest revision strategy would consider this version greater than the ‘1.0.0’ release version, we have to add some character before the timestamp, which would lead us to a proper ordering:
1.0.0-v20121001 < 1.0.0
We then define three repositories for each maturity level (status of a project):
- 'release’s - contains modules with versions e.g. ‘1.0.0’, having release status - ‘milestones’ - contains modules with versions e.g. ‘1.0.0-v20121001’, having milestone status - ‘snapshots’ - contains modules with versions e.g. ‘1.0.0-v20121101’, having integration status
Now if I want to enforce that a project with a integration status can resolve from ‘releases’ and ‘milestones’ repositories only, I would have to write a plugin to do that, let’s name it ‘releaseEnforcer’
However, I cannot restrict the users to use only the"final" (release) version of this plugin - I consider the buildscript’s dependencies like any other dependency so if the project is having a milestone status, then it should be allowed to resolve milestone buildscript dependencies as well. I cannot force the users what version to use when referencing this plugin, they could even use a version range, e.g.
classpath ‘org.foo:releaseEnforcer:[1, 2)’
} But if they do the above, since the plugin cannot run before it is resolved, the buildscript’s repositories would still contain all resolvers (‘releases’, ‘milestone’ and ‘snapshots’), so the build might pick up e.g. ‘1.0.0-v20121101’ version which is an ‘integration’ version.
What I want to achieve is that the build picks up ‘1.0.0-v20121001’ (a milestone) if the status of the project is also ‘milestone’ (or release) - here I assume that the status of the project can be identified before evaluating the build script (e.g. by examining the task list or project properties) - to achieve this goal the ‘releaseEnforcer’ must remove the ‘snapshots’ repository for the buildscript’s and the project’s repositories - thus any higher integration version there will be ignored.
I guess the solution would be to add the logic that restricts the set of repositories to resolve from in a Gradle init script instead of adding it to a custom plugin, this way it could run even before the buildscript’s dependencies are resolved. The only other thing to ensure is that the project’s status cannot be changed after that (e.g. during the evaluation of the build script).
I probably answered to my question myself, but I wonder whether all this sounds reasonable or I’m making wrong assumptions?