I have made some progress on this, but I would appreciate some advice from
anyone who knows the resolution innards and where they are going in the
future.
The main problem with the approach that we've tried in the last few messages
is that the ivySettings is not created and injected into the resolvers until
the first time a real Configuration object needs its input files and calls
resolve, delegating to ivyService.resolve(config). So, we either have to
figure out how to use this mechanism in a task that extracts what we want
from the repo, or hook the compileJava task and then call a then-initialized
resolver directly.
For example, after :compileJava, any resolver set in repositories will have
been initialized and you can use it, or use its settings property in another
resolver.
def mods = queryResolver.listModules(new
org.apache.ivy.core.search.OrganisationEntry(queryResolver, org))
This alternate approach might work earlier in execution, where the module to
query is put into a 'self' configuration. Too bad it causes a resolution
exception:
def cc =
project.services.get(org.gradle.api.artifacts.ConfigurationContainer)
def is = cc.ivyService.ivyService.ivyService
def resolvedConfiguration = is.resolve(project.configurations.self)
def flmds = resolvedConfiguration.getFirstLevelModuleDependencies()
flmds.each {println " .. $it"}
My ultimate goal here is re-implement what I have in Ant+Ivy: run an
ivy:info invocation to determine the latest built version of the given
module to use in computing the next version.
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Using-an-IvyResolver-directly-to-query-existing-versions-causes-NullPointerException-tp4552897p4581501.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
