Base plugin should provide a GemInstall task

[rtyler]

We have a few internal jruby-gradle projects which rely on locally built or otherwise .gem file-based installation procedures.

Since the past few versions we have introduced additional functionality to create .jrubydir files after the gem installation process internal to jruby-gradle.

To allow us to handle a .gem-based use case, it would be beneficial to have a GemInstall task type, so instead of:

task installLocalGem(type: JRubyExec) {
    environment [:]
    dependsOn ':subproject:buildGemm'
    workingDir rootProject.projectDir
    gemWorkDir jruby.gemInstallDir
    jrubyArgs '-S'
    script 'gem'
    scriptArgs {[
        'install',
        builtGemPath(rootProject.projectDir.absolutePath, project(':subproject').name),
        '--install-dir',
        jruby.gemInstallDir,
        '--ignore-dependencies',
    ]}
}

task regenerateJRubyDirInfo(type: JRubyExec) {
    dependsOn installLocalGem
    description 'Regenerate dir info post gem install'
    jrubyArgs "-r", "jruby/commands", "-e", "JRuby::Commands.generate_dir_info 'build/gems/specifications'"
}

we could have

task installLocalGem(type: GemInstall) {
    dependsOn ':subproject:buildGemm'
    gemPath { builtGemPath(rootProject.projectDir.absolutePath, project(':subproject').name) }
    destination jruby.gemInstallDir
}
``

[tommysullivan]

alternatively, when expressing the dependencies of a gradle project, we can have a notation that says "use the gem artifact built by this other gradle project". This would work in tandem with the declarative gem artifact capability i've been bugging you about :)

[tommysullivan]

so in other words it would go under dependencies closure, and there would be a string notation that causes resolution to happen in this new way which causes the gem to be built by gradle and the result moved into the appropriate place like the other gradle managed gem dependencies

[tommysullivan]

make it analogous to how a java / groovy gradle project expresses a dependency on jar(s) built from other gradle subprojects (from a gradle declaration perspective, not from an implementation perspective)

[mkristian]

there are two issues here. first when and how shall the .jrubydir creation takes place and second how to use gem from gradle subprojects.

the .jrubydir files are needed for ruby application packed in jars, i.e. it is needed for the jruby-gradle-jar-plugin and probably for the war-plugin as well. but is NOT needed for jrubyExec. creating .jrubydir right after gem install is the wrong place. currently the jar-plugin does exclude the directories where the gem got installed and it still has huge problems to get all the .jrubydir right

so moving the .jrubydir creation to where it is needed is the first step. and then you can consider having a GemInstallTask if this is really needed.

for gem from a gradle subprojects I think (not sure how gradle works here) it needs a way to "assemble" a gem.

the ruby way gem build my.gemspec will not work since all the dependencies info are hidden to gradle. moving the gemspec DSL into build.gradle feels wrong (I did this for maven but since maven can use a gemspec as POM DSL a subproject with a gemspec only is just enough). better use the gemspec to tell gradle about the gem's dependencies and use it to assemble the gem.

[ysb33r]

make it analogous to how a java / groovy gradle project expresses a dependency on jar(s) built from other gradle subprojects (from a gradle declaration perspective, not from an implementation perspective)

@tommysullivan, I assume you mean something like

dependencies {
  gems project('foo')
}

We have a few internal jruby-gradle projects which rely on locally built or otherwise .gem file-based installation procedures.

@rtyler, are you inferring something analogous to publishToMavenLocal, which installs to ~/.m2, except in this case it might install to '~/.gem' ?

for gem from a gradle subprojects I think (not sure how gradle works here) it needs a way to "assemble" a gem.

@mkristian, yes, that is one reason for potentially getting my Rake plugin to work.

[rtyler]

@tommysullivan, I assume you mean something like

@ysb33r part of what @tommysullivan is referring to, and @mkristian, is an idea we've been kicking internally at @Lookoutto describe a Gem::Specification inside of a Gradle file using a Gradle DSL. That would obviously make the syntax you reference possible, but first I think we would need to get the building of a valid gem working properly.

@rtyler, are you inferring something analogous to publishToMavenLocal, which installs to ~/.m2, except in this case it might install to '~/.gem' ?

This is not the use-case that we have internally right now. The core use-case is for a backend service which has the service (Ruby) and a client gem (Ruby) and testing both of those requires us to effectively include/install the client gem in a test project. Whether this is a "maven local" type location or just ${buildDir}/gems is largely irrelevant to me.

[tommysullivan]

Yes, step one would be to "get the building of a valid gem working properly". Where does one describe the gem and its dependencies? In a gemspec file? In build.gradle? If the latter, do we generate a gemspec and then build with that? Can we do an analogue to bundle + gemfile + gemspec, where we use the gemspec as the canonical definition of the gem metadata, including its dependencies, but then we can use bundler and Gemfile to provide optional, additional metadata that can be used by bundler to resolve dependencies (ie: bundler's :path configuration that changes where a dependency is obtained) - only replace "bundler" with "gradle" and "Gemfile" with "build.gradle"? Could such a pattern work in the case where we have arbitrary number of transitive gems following this pattern in some dependency graph? What about java based gem dependencies?

In lieu of answering these questions, perhaps a very simple use case could be considered or prototyped, yielding more knowledge around the limits of various design ideas, while still enabling some more basic use cases such as we have here with the local protobuf style gems.