These are chat archives for jruby-gradle/jruby-gradle-plugin

7th
Nov 2017
Schalk W. Cronjé
@ysb33r
Nov 07 2017 15:44
@rtyler I just pulled master and getting integrationTest failures
Schalk W. Cronjé
@ysb33r
Nov 07 2017 16:04
@mkristian I think #316 is related to an issue inside the rubygems resolver code not being compatible with changes in the Gradle Resolver API
Christian Meier
@mkristian
Nov 07 2017 16:05
I expected this to happen one day :)
Schalk W. Cronjé
@ysb33r
Nov 07 2017 16:06
Want to give me some pointers where to look?
Christian Meier
@mkristian
Nov 07 2017 16:07
setting log level to debug should help, as the resolver does print a lot (as far I remember). need to have look at the code now for further remarks
Christian Meier
@mkristian
Nov 07 2017 16:19
so the code first runs over all transitive dependencies and collects its version ranges. second run it intersects all the version ranges for a given gem name.
@ysb33r looking at the sample project, the resolver output looks as expected
but just after the resolver ran the build reports failed on both gem dependencies
Schalk W. Cronjé
@ysb33r
Nov 07 2017 16:23
17:17:06.569 [DEBUG] [org.gradle.internal.progress.DefaultBuildOperationExecutor] Completing Build operation 'Resolve dependencies of :jrubyExecCopy'
17:17:06.571 [DEBUG] [org.gradle.internal.progress.DefaultBuildOperationExecutor] Build operation 'Resolve dependencies of :jrubyExecCopy' completed
17:17:06.571 [DEBUG] [org.gradle.api.Project] jrubyExec
                       ------------------------
                       apply version range info
                       ------------------------
17:17:06.572 [DEBUG] [org.gradle.api.Project] configuration ':jrubyExec': gem asciidoctor 1.5.2+
17:17:06.573 [DEBUG] [org.gradle.api.Project] configuration ':jrubyExec'      collected [1.5.2,1.5.99999]
17:17:06.574 [DEBUG] [org.gradle.api.Project] configuration ':jrubyExec'      resolved  [1.5.2,1.5.99999]
17:17:06.574 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.DynamicVersionResolver] Attempting to resolve version for rubygems:asciidoctor:[1.5.2,1.5.99999] using repositories [flatDir, BintrayJCenter, maven, maven2]
17:17:06.576 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver] Attempting to resolve component for org.jruby:jruby-complete:9.1.12.0 using repositories [flatDir, BintrayJCenter, maven, maven2]
17:17:06.576 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver] Using org.jruby:jruby-complete:9.1.12.0 from Maven repository 'BintrayJCenter'
17:17:06.576 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder] Visiting configuration org.jruby:jruby-complete:9.1.12.0(default).
17:17:06.577 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.oldresult.TransientConfigurationResultsBuilder] Flushing resolved configuration data in Binary store in /private/var/folders/jy/ls4wb8pd3tgg10f8vr2q27_h0000gn/T/gradle2276355485287136869.bin. Wrote root 2.
17:17:06.578 [DEBUG] [org.gradle.internal.progress.DefaultBuildOperationExecutor] Completing Build operation 'Resolve dependencies of :jrubyExec'
This is what I am seeing
I am trying to figure out how this ties together
where the plugin tries to overwrite the version to be used.
Christian Meier
@mkristian
Nov 07 2017 16:29
maybe - can not fully understand if this implies to our case or not.
Schalk W. Cronjé
@ysb33r
Nov 07 2017 16:36
To confirm: the current resolving method still goes to lasagne/torquebox direct without an internal servlet?
Schalk W. Cronjé
@ysb33r
Nov 07 2017 16:44
What I know of this is twofold: It is not the ordering of dependencies AND it is not the open range that is the problem.
Christian Meier
@mkristian
Nov 07 2017 16:45
yes: the internal servlet is not active per default.
Schalk W. Cronjé
@ysb33r
Nov 07 2017 17:23
It is related to that 4.3 change. I think lasagne is playing up again. When I removed it from the list of repoS in the test code, all works fine.
Christian Meier
@mkristian
Nov 07 2017 17:59
interesting - would be nice if this is the case.
Schalk W. Cronjé
@ysb33r
Nov 07 2017 22:17
@mkristian I got word back from the Gradle folks and tried a nightly SNAPSHOT build of the upcoming 4.3.1 release. It resolves the problem.
Christian Meier
@mkristian
Nov 07 2017 22:40
@ysb33r great and actually I am also relieved that the fix is not on our side. all this resolving bits can be quite tricky ;)