New Gradle 1.0-milestone-6 snapshot available


(Adam Murdoch) #1

A new Gradle 1.0-milestone-6 snapshot is now available. Milestone 6 contains a nice swag of new features and bug fixes. Have a look at the release notes for details. Also make sure you read the migration guide. Both documents are a work in progress.

Please help us test this snapshot. If no major issues are found over the next few days, we will release this as Gradle 1.0-milestone-6. You can download the distribution, or point your wrapper at gradle-1.0-milestone-6-20111109220157+0100-bin.zip.

We’ve made some big improvements in dependency management performance. We rewrote the resolve engine to enable this. We do have an exhaustive integration test suite for this stuff, and we believe these changes work fine, but nevertheless you may run into some regressions in this snapshot. We will fix these regressions before we do the release.


(Matias Bjarland) #2

Testing out the new build and it is fast. Looking good!

Have a question though. Is is possible to use the the new:


 configuration.resolutionStrategy.cacheChangingModulesFor 2, "minutes"  

syntax in a buildscript { } block in settings.gradle? Or rather it seems that that specific syntax is perhaps not appropriate in settings.gradle. Is there some other way to set a fast expiry on a changing = true dependency in a buildscript block in settings.gradle.

EDIT: Figured it out:

  buildscript {



  repositories {



maven {



  credentials {







username artifactoryReader







password artifactoryReaderPwd



  }



  url "http://x.y.z"



}







}



configurations.classpath.resolutionStrategy.cacheChangingModulesFor 0, 'seconds'

 ...  }  

oh and a huge thank you for the new maven credentials syntax!


(detelinyordanov) #3

I found something weird while testing with this snapshot, I have a ‘bar’ project with a project dependency to ‘foo’:

dependencies {
    compile project([ path: ':foo' ])
}

A task running on ‘:bar’ (after ‘:foo:jar’ is executed) is processing the resolved module artifacts like so:

Configuration runtime = project.configurations.runtime
ResolvedConfiguration resolvedRuntime = runtime.resolvedConfiguration
...
for (ResolvedDependency resolvedDependency : resolvedRuntime.getFirstLevelModuleDependencies()) {
    for (ResolvedArtifact artifact : resolvedDependency.moduleArtifacts) {
        if (artifact.type == 'jar') {
            //do some processing
        }
    }
}

However,

resolvedDependency.moduleArtifacts

always returns an empty Set. This piece of code correctly returned the set of artifacts of the project dependency when running with Gradle 1.0 m3 to m5.

Regards,

Detelin


(Adam Murdoch) #4

This should be fixed in the new snapshot. Could you give it a try?

See http://forums.gradle.org/gradle/topics/new_gradle_1_0_milestone_6_snapshot_available-1js19c


(detelinyordanov) #5

Tested this with gradle-1.0-milestone-6-20111114000013+0100-bin.zip and the problem is gone. Thanks!


(tamabo88) #6

config.resolvedConfiguration.firstLevelModuleDependencies.each { ResolvedDependency dep ->

“$dep.moduleName”() {

println “DEPENDENCY NAME: $dep.moduleName”

version(dep.moduleVersion)

from(dep.moduleGroup)

}

}

I have a similar problem where the returned Resolved Dependency is empty. Is this related to the fix above?


(Luke Daley) #7

Juhan, please open a separate problem report for this. Also, please indicate the Gradle version you are using.