The ruby runtime plugin fails to load when running Jenkins with Java 11. I
think that is one more reason to discuss deprecation of the ruby-runtime
plugin again.
The failure message is "*unsupported Java version: 11*":
2021-04-14 17:46:48.215+0000 [id=31] INFO
ruby.RubyRuntimePlugin#start: Injecting JRuby into XStream
2021-04-14 17:46:48.451+0000 [id=31] WARNING
jenkins.model.Jenkins$5#runTask: Loading plugin ruby-runtime v0.12
(ruby-runtime) failed perhaps due to plugin dependency issues
*java.lang.RuntimeException: unsupported Java version: 11*
at
org.jruby.RubyInstanceConfig.initGlobalJavaVersion(RubyInstanceConfig.java:1674)
at
org.jruby.RubyInstanceConfig.<clinit>(RubyInstanceConfig.java:1387)
Caused: java.lang.ExceptionInInitializerError
at
org.jruby.embed.internal.AbstractLocalContextProvider.<init>(AbstractLocalContextProvider.java:42)
at
org.jruby.embed.internal.SingleThreadLocalContextProvider.<init>(SingleThreadLocalContextProvider.java:43)
at
org.jruby.embed.ScriptingContainer.getProviderInstance(ScriptingContainer.java:242)
at
org.jruby.embed.ScriptingContainer.<init>(ScriptingContainer.java:226)
at
org.jruby.embed.ScriptingContainer.<init>(ScriptingContainer.java:192)
at
org.kohsuke.stapler.jelly.jruby.JRubyFacet.<init>(JRubyFacet.java:65)
at
ruby.RubyRuntimePlugin.registerJRubyFacet(RubyRuntimePlugin.java:39)
at ruby.RubyRuntimePlugin.start(RubyRuntimePlugin.java:30)
at
hudson.ClassicPluginStrategy.startPlugin(ClassicPluginStrategy.java:406)
at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:395)
Caused: java.io.IOException: Failed to initialize
at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:398)
at hudson.PluginManager$2$1$1.run(PluginManager.java:551)
at
org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
at jenkins.model.Jenkins$5.runTask(Jenkins.java:1131)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
at
jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
2021-04-14 17:46:48.457+0000 [id=32] SEVERE
jenkins.InitReactorRunner$1#onTaskFailed: Failed Loading plugin Rvm v0.6
(rvm)
java.io.IOException: Failed to load: Rvm (0.6)
- Plugin is missing: ruby-runtime (0.12)
at
hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:950)
at hudson.PluginManager$2$1$1.run(PluginManager.java:550)
at
org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
at jenkins.model.Jenkins$5.runTask(Jenkins.java:1131)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
at
jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
com.google.inject.internal.cglib.core.$ReflectUtils$2
(file:/home/mwaite/tmp/JENKINS-65243/war/WEB-INF/lib/guice-4.0.jar) to
method java.lang.ClassLoader.
defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of
com.google.inject.internal.cglib.core.$ReflectUtils$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
On Wednesday, April 14, 2021 at 10:34:37 AM UTC-6 ga...@gavinmogan.com
wrote:
> So revisiting this really old ticket.
>
> As i've been working on rewriting/improving the process of processing
> metadata to produce plugin documentation, I'm noticing we have a lot more
> legacy bad data than I expected. While I am handling it, I also want to try
> and improve things. As such, ruby runtime is going to be on my list to
> discuss.
>
> Looking at the original list that db generated, all of them have not been
> released in at least 5 years (most are 7-9 years), including gitlab-hook
> which has huge security errors listed. I was certain at one point I saw
> ruby runtime being no longer supported in core but I can't find
> confirmation of that, so may have been thinking of this discussion.
>
> So revisiting, Can we suspend distribution of these plugins now? take them
> out of update center, prevent new installs from happening. As stated in the
> earlier comments by Jesse, this wouldn't prevent existing installs from
> using them (although they probably don't work), but would prevent peoples
> installs from getting worse.
>
> If the only blocker to doing so was writing up a blog post I can draft
> something and we can start the process of removing the support and plugins
> for ruby runtime
>
> Gavin
>
> On Friday, August 17, 2018 at 4:40:03 AM UTC-7 Oleg Nenashev wrote:
>
>> Hi Daniel,
>>
>> Thanks for the amendment!
>> Would it be also possible to add an "Announcement" section to reasoning
>> and explicitly document why proposals (blogpost, administrative warning,
>> direct maintainer notification) are rejected?
>>
>> I still disagree with the user notification approach taken in this
>> proposal, and I believe we should do the best possible effort to notify
>> users.
>> Spending 1 hour to write a blogpost with heads-up and workaround
>> guidelines (and invitations to contribute) is the most obvious way to do
>> that.
>> I do not understand why there is so much resistance about that.
>>
>> CCing all known plugin maintainers in this thread is another obvious way
>> to make them aware of the thread. We cannot expect that any plugin
>> maintainer carefully reads every thread in the mailing list.
>>
>> "Scriptler, Build Flow, Copy to Slave, or Perforce."
>>>
>>
>> I do not buy that justification for JEP-7. All these plugins have been
>> depublished due to security reasons, so there was no way to properly notify
>> users in advance. But even in such case, the users know about the incoming
>> security release in advance so they can prepare to mitigate breaking
>> changes. Maintainers also got directly contacted, and they acknowledged the
>> action. Here you propose to depublish a bunch of
>> non-healthy-but-operational plugins, and the proposed notification process
>> is "let's just do that, they should have read mailing lists". And there are
>> low-cost ways to let users know in advance and to soften the change. I
>> cannot agree with such approach, sorry.
>>
>> Best regards,
>> Oleg
>>
>>
>> On Thursday, August 16, 2018 at 9:45:33 PM UTC+2, Daniel Beck wrote:
>>>
>>>
>>> > On 16. Aug 2018, at 19:45, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>>> >
>>> >> You mean, so that _new_ users can _install_ the plugins? I would say
>>> no.
>>> >
>>> > How would you define a "new" user in the new configuration-as-code
>>> world? If somebody uses official Jenkins Docker image with plugins.txt, the
>>> plugins will fail to install when you rebuild the image after the change
>>> gets deployed. And it is a pretty popular approach nowadays. Plugin
>>> installation features in JCasC 1.0 RC would be also affected AFAICT.
>>>
>>> As of last count, 111 installs of CasC plugin. I'd be _very_ surprised
>>> if this ended up affecting more than 5 systems total.
>>>
>>> And while this isn't the only approach to configuration-as-code, people
>>> should not expect us to continue distributing plugins indefinitely after we
>>> blacklisted the likes of Scriptler, Build Flow, Copy to Slave, or Perforce.
>>>
>>> Notably, update sites only have the newest release, which isn't suitable
>>> for C-as-C anyway, so I expect the more stable approaches to use our Maven
>>> repo anyway -- which will not be affected.
>>>
>>> Running one's own Maven repo has been an important best practice for a
>>> long time. With C-as-C, running one's own update site should be similar.
>>>
>>> I will amend the JEP to record this concern and the answers. I don't
>>> think we need to change anything about the chosen approach.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/22ac20c3-486c-4d4d-bb2c-873c5d20a887n%40googlegroups.com.
