New 1.0-milestone-5 snapshot available

Old Forum Archive
1

Another 1.0-milestone-5 snapshot is now available, which fixes a regression in project dependency handling contained in the previous snapshots.

The snapshot is available for download here. We would appreciate your help in testing this snapshot. Please point your wrapper at the distribution, or download and install it, and let us know how you go.

If no major issues are uncovered in this snapshot in the next few days, we will release it as 1.0-milestone-5.

More details about the changes in 1.0-milestone-5 are available in the release notes (a work in progress).

Please note that there are some breaking changes in this release. See breaking changes for details.

2

Looking at this m5, and I have a question. I have (ugly :slight_smile: code in my plugin for m3/m4 that pokes around a bit inside Gradle to get an Ivy instance with a special resolver added to it for a pre-resolve query that I need to do.

I had been using DefaultIvyService, retrieved like:

DefaultConfigurationContainer cc = project.services.get(ConfigurationContainer)

ErrorHandlingIvyService is0 = cc.ivyService

ShortcircuitEmptyConfigsIvyService is1 = is0.ivyService

DefaultIvyService is = is1.ivyService

then used that to make an IvySettings:

SettingsConverter sc = is.settingsConverter

IvySettings settings = sc.convertForResolve(

is.resolverProvider.getResolvers())

then, after adjusting settings, made an Ivy:

is.settingsConverter.resolveSettings = settings // M4

Ivy ivy = is.ivyFactory.createIvy(settings)

I’ll dig through the new code, but if you have any hints to point me to the least ugly approach to my hack, that’d be great.

3

What’s the query doing? We might be able to add something to the dsl to help you do this without having to dig into the internals of Gradle.

4

Oh, cool, of course.

Well, the query is used to look for all previous versions of the target module using a given resolver, and then return the metadata for the latest / most recent. I really just care about finding the latest version and its status. We then use this to compute what version to give the current build.

5

Maybe in the meantime before you get a chance to make DSL changes I can make small adjustments to my hack. Could you point me to the newer code that replaces the IvyService object?

Or, a reasonable way for the short-term to create an Ivy object instance that is configured according to my project.repositories and other settings?

Or, another way using more sanctioned methods to do effectively:

ivy.findModule(ModuleRevisionId.newInstance(org, name, rev))

6

You can do something like this to get some meta-data for a module:

def dependency = dependencies.create("group:module:revision")
def config = configurations.detatchedConfiguration(dependency)
def metaData = config.resolvedConfiguration
// do some stuff with metaData ...

Have a look at the javadoc for ResolvedConfiguration for what you can do with the result. Will this do what you need?

7

I will give that a look.

I see a couple of things that it might be missing. The bit that I do that I didn’t mention in my previous comment was to first use Ivy to list all available versions of the specific target module in the repo, then pick the newest one:

ResolvedModuleRevision latestModuleRevision(RepositoryResolver queryResolver, String org, String module) {
    Ivy ivy = createIvy()
// This also inits queryResolver. TODO: get that all init'd earlier
    OrganisationEntry organisationEntry = new OrganisationEntry(queryResolver, org)
    ModuleEntry moduleEntry = new ModuleEntry(organisationEntry, module)
    RevisionEntry[] revs = queryResolver.listRevisions(moduleEntry)
    if (revs?.size() > 0) {
        def lastRev = revs.sort{r1,r2 -> -compareRevisionEntries(r1,r2)}[0].revision
        return ivyFindModule(ivy, queryResolver, org, module, lastRev)
    }
    null
}

And then the last function will run ivy.findModule() to query the repo and return a ResolvedModuleRevision rmr. From there I get the rmr.descriptor.revision and the rmr.descriptor.status. I need both of those to know what version to build next.

In the end, all that I need to know about is this one module’s available versions, and then ask for the module descriptor for the latest one. I don’t need a dependency resolve, but I do need the Ivy status of the resolved module. I don’t see that in the Gradle ResolvedConfiguration.

The Gradle+Groovy+Ivy code I have working with m4 is actually way simpler and faster than my old Ant+Ivy code, so I hope I can keep this approach.

8

Adam: your suggestion didn’t work. I took another route and am now making my Ivy objects directly without having to muck with the Gradle internals. I only need a very simple url resolver to talk to the repo.

Second problem, though, is it is no longer possible to control the patterns for flat file repos. This used to work and now fails:

FlatDirectoryArtifactRepository res = repos.flatDir(name: name, dirs: "$project.projectDir/$dirname")
res.addArtifactPattern("$project.projectDir/$dirname/$artiPattern")
res.addIvyPattern("$project.projectDir/$dirname/$ivyPattern")

Ideas?

9

The idea is that you use flatDir() if you just want to use a directory of jars. You would use repositories.ivy() instead, if you want the repository to do any ivy stuff (look for an ivy.xml, use patterns, etc). Here’s an example:

repositories {
     ivy {
          artifactPattern "$dirname/$artiPattern"
          ivyPattern "$dirname/$ivyPattern"
     }
}
10

So, it sounds like we need 2 things on the DSL: * Given a group, module and optionally a revision pattern, list all the matching revisions, from most recent to least recent order. This would probably be just a list of module identifiers (group, module, revision). * Given a module identifier, fetch the meta-data for the module. This would include the status of the module.

11

Doh, I should have figured that out. That is now working well, thanks!