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

27th
Aug 2015
Christian Meier
@mkristian
Aug 27 2015 09:31
@raelik if you put the class files of the subproject into a jar and then require this jar from jruby, then all the jars end up in the same classloader (jruby-classlaoder of the JRuby.runtime). yes, the moment you add ths class files as usual in the jar they end up in JRuby.runtime.jruby_class_loader.parent and can not see the classes from the jruby-classloader
@ysb33r will try project.class.class_loader - though I looked at the classloader itself and it carries the jruby-gradle-plugin dependencies as well the integrationTest dependencies. and this mix is a problem since integrationTest comes with jruby-9.0.0.0 used for testing and conflicts with the servlet.
the point is also how much "extra" code I want to add into the plugin ONLY to get the integrationTests working.
Schalk W. Cronjé
@ysb33r
Aug 27 2015 10:38
@mkristian can we not have the jruby version consistent?
Christian Meier
@mkristian
Aug 27 2015 10:39
not so easy to replace the jruby which is packed inside a war file
Schalk W. Cronjé
@ysb33r
Aug 27 2015 10:40
@mkristian, make jar not war :)
Christian Meier
@mkristian
Aug 27 2015 10:41
:)
Schalk W. Cronjé
@ysb33r
Aug 27 2015 10:41
can we not extract all of the necessary servlet code out and build something that is closer to the grade rep mgmt
Christian Meier
@mkristian
Aug 27 2015 10:44
@ysb33r the servlet is just a thin wrapper around the nexus-ruby-tools. yes, we can BUT the nexus-ruby-tools needs jruby to work and the version of jruby should be fixed (as it is a nexus-ruby-tools dependency). so we really need to take care of separating classloaders as well
but if I try to play with things again I will look at gradleTest which already works when using the plugin from mavenLocal()
Schalk W. Cronjé
@ysb33r
Aug 27 2015 10:57
@mkristian the idealistic thing that I had in the back of my might is to take the logic from there and rewrite in java/groovy whilst making it to look like a MavenArtifactRepository instance.
Christian Meier
@mkristian
Aug 27 2015 10:59
this part should be easy. not sure how to plugin such custom MavenArtifactRepository from plugin
I mean from the jruby-gadle plugin
Schalk W. Cronjé
@ysb33r
Aug 27 2015 11:03

two parts to that
[1] the easy part

apply plugin : ‘make.rubygems.servlet.native.to.gradle’
repositories {
  rubyGems()
}

Easy because once plugin is applied rubyGems should be resovable from a RepositoryContainer.

[2] more difficult to use from build script

buildscript  {
  repositories {
    rubyGems()
  }
}

ONly possible with direct support from Gradle folks OR by passing an initscript on the cmdline

Christian Meier
@mkristian
Aug 27 2015 11:14
not sure what https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/repositories/MavenArtifactRepository.html is meant for. something else does know that this is maven and use the provided urls respectively
Schalk W. Cronjé
@ysb33r
Aug 27 2015 11:55
Also one probably would need to add ane xtension via metaClass to https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/dsl/RepositoryHandler.html. Thereafter it all gets very diry, very quickly as one descends into Gradle internal API hell.
Christian Meier
@mkristian
Aug 27 2015 12:00
one way which is less intrusive would be a custom url protocol handler: gems://rubygems/rake/10.4.2/rake-10.4.2.pom then we can reuse the current syntax maven { url { 'gems://' } } or hide it under rubygems()
the problem is to register such a protocol handle one needs to add or modify a system property
Schalk W. Cronjé
@ysb33r
Aug 27 2015 12:02
@mkristian now, there’s some lateral thinking
Schalk W. Cronjé
@ysb33r
Aug 27 2015 12:07
Will probably still require getting into some Gradle internals
Christian Meier
@mkristian
Aug 27 2015 12:08
for the buildscript part definitely
Schalk W. Cronjé
@ysb33r
Aug 27 2015 12:26

Will need to implement a org.gradle.api.internal.artifacts.repositories.transport.RepositoryTransport for a start. Will also need to look at org.gradle.internal.resource.transport.aws.s3.S3ResourceConnector as an example. And then …

implement a org.gradle.internal.service.scopes.PluginServiceRegistry and create an appropriate META-INF file to get it loaded. FOr the latter I assume that once your jar is on the gradle classpath it can get loaded.

Blane Dabney
@raelik
Aug 27 2015 14:54
@mkristian Yeah, that wasn't really a problem. It's more of a project layout issue. This subproject really deserves to be a first-class citizen in its own project, I just don't have a real need to do that because I'm not using it anywhere else currently.
R. Tyler Croy
@rtyler
Aug 27 2015 15:08
I like waking up to a busy scrollback :)