Provide jruby in environment PATH ?

[blop]

Hello,

I would like to use your plugin to automatically provide a working local jruby installation.

However, further in my tasks, I need to call an external script which is using this :

!/usr/bin/env jruby

Is there a way to get a jruby entrypoint that I can put in my PATH so that my script would use that local jruby ?

Ideally I would depend on some jrubyInstall task and be able to get the path to the executable in a variable somewhere.

Thank you!
Regards,

Olivier

[ysb33r]

Even though it might be possible, I don't really think this plugin is suited for that. It sounds more like something that should be handled by (http://gvmtool.net)[GVM] (Or sdkmanager as what it will be known as from now on).

@marcoVermeulen Any thoughts?

[marc0der]

Yes, sounds like a good idea. I'm currently in the process of migrating to
SDKman, but once that is all done we can look at onboarding many other new
technologies.

On Wed, 17 Jun 2015 at 14:28 Schalk W. Cronjé notifications@github.com
wrote:

Even though it might be possible, I don't really think this plugin is
suited for that. It sounds more like something that should be handled by (
http://gvmtool.net)[GVM] (Or sdkmanager as what it will be known as from
now on).

@marcoVermeulen https://github.com/marcoVermeulen Any thoughts?

—
Reply to this email directly or view it on GitHub
#132 (comment)
.

[blop]

The idea is to be able to get jruby for build/test Gradle tasks in a CI environment where everything should be automated and the dependencies should be minimal (like only java, to run gradle, to setup everything).

[marc0der]

Yes, and that is exactly what SDKman does for groovy related tech atm. You
could even include this installation step in your Dockerfile if you're
using Docker.

On Wed, 17 Jun 2015 at 14:33 Olivier Voortman notifications@github.com
wrote:

The idea is to be able to get jruby for build/test Gradle tasks in a CI
environment where everything should be automated and the dependencies
should be minimal (like only java, to run gradle, to setup everything).

—
Reply to this email directly or view it on GitHub
#132 (comment)
.

[ysb33r]

@marcoVermeulen, it might be possible to onboard jruby earlier in the same way that was done for asciidoctorj

[rtyler]

@blop If you're needing to invoke an Exec task which might exec back into Ruby land, I might have a solution for you.

That said, I would say that providing a general purpose JRuby in PATH is an RVM type job (for which there's definitely lots of prior use-cases with Jenkins)

With that caveat out of the way, take a use-case like Google's protoc compiler. The way one compiles Protobufs for Ruby is by invoking protoc with --ruby_out=blah which causes the protoc binary to look for protoc-gen-ruby in the PATH.

Still with me?

The protoc-gen-ruby file in the PATH is something that JRubyExec` can already handle, but that file is actually something like:

#!/usr/bin/env ruby

# Before requiring protobuf, ensure that we will not load any
# server or client code.
#
ENV['PB_NO_NETWORKING'] = '1'

$LOAD_PATH << ::File.expand_path("../../lib", __FILE__)
require 'protobuf'
require 'protobuf/descriptors'
require 'protobuf/code_generator'

request_bytes = STDIN.read
code_generator = ::Protobuf::CodeGenerator.new(request_bytes)
response_bytes = code_generator.response_bytes
STDOUT.print(response_bytes)

So our Gradle task execution goes: Gradle -> protoc -> protoc-gen-ruby -> Ruby. Containing the last part of that inside the Gradle build can be challenging because basically you need Ruby in the PATH when protoc is executed.

The way I've solved this is with the GeneratedGradleRb task which is available in later versions of the plugin, and basically generates a stub file which will invoke the jruby-complete installation that JRuby/Gradle has created, e.g.

task prepareRubyStub(type: GenerateGradleRb) {
    description 'Prepare a Ruby stub binary for executing protoc properly'
    group 'Protobuf'
    baseName 'ruby'
    /* Shove this in build directory right next to our JRuby binstubs */
    destinationDir file("${jruby.gemInstallDir}/bin")
    dependsOn jrubyPrepare
}

task buildRubyProtos(type: Exec) {
    group 'Protobuf'
    description 'Build Ruby protobuf bindings'
    dependsOn prepareRubyStub
    /* Setting our environment's path to include our protoc-gen-ruby which was
     * previously installed. Using setEnvironment instead to ensure that the
     * subprocess *only* has the PATH variable set and doesn't accidentally
     * inherit some RVM settings
     */
    setEnvironment 'PATH' : "/usr/bin:/bin:/usr/sbin:${jruby.gemInstallDir}/bin:/usr/local/bin"
    inputs.files(protoFiles)
    commandLine 'protoc'
    /* Need to generate my output into the root project's root directory
     * since that's where all our Ruby client code lives right now
     */
    args = ["--proto_path=${projectDir}", "--ruby_out=${rootProject.projectDir}/lib"] +
            inputs.files.files
}

[marc0der]

I would rather hold off until we are sdkman because if we do it we will
need to get all the historic releases in the DB.

Also, we would need to get the jruby team onboard so that they can start
publishing their own releases. Otherwise it will be on me to publish new
releases every time they come out.

On Wed, 17 Jun 2015 at 15:53 Schalk W. Cronjé notifications@github.com
wrote:

@marcoVermeulen https://github.com/marcoVermeulen, it might be possible
to onboard jruby earlier in the same way that was done for asciidoctorj

—
Reply to this email directly or view it on GitHub
#132 (comment)
.