<distant[m]>
I'm still pretty new to Ruby, so I don't know how well-written it is, especially since it's not even reaching the point to where it'd crash because of this.
<distant[m]>
Anyway I mean prepackaging, not that embedding.
<distant[m]>
Like, providing JRuby inside of the Fabric Language Ruby jar.
<distant[m]>
Why did that send twice?
<distant[m]>
(As that's the easiest way to provide things to Fabric Loader.)
<distant[m]>
Anyway, the goal is to provide JRuby, as well as the language adapter, to Fabric as a mod.
<distant[m]>
O_O Webclient's broken...
<distant[m]>
I just refreshed, it's not sending twice.
<distant[m]>
The goal is to provide JRuby and the language adapter to Fabric as a mod, as that's the easiest way to do so.
<nilsding>
ah, so you embed your ruby in the jar itself, I think I get you now
<distant[m]>
I can force JRuby into libraries instead, if that breaks JRuby though...
<nilsding>
* your ruby code in the
<distant[m]>
(It's not ideal, as then it becomes more dependent on Minecraft.)
<distant[m]>
nilsding: That, and the entirety of JRuby.
<distant[m]>
I'm making a utility that others can use to write mods in JRuby.
<distant[m]>
It launches by itself, but it crashes when it launches any mod with a Ruby entrypoint class (the point from which a mod launches).
<distant[m]>
It's blaming the crash on this:
<distant[m]>
> org.jruby.exceptions.NoMethodError: (NoMethodError) undefined method `load_defaults' for Gem::Specification:Class's blaming the crash on this:
<distant[m]>
byteit101[m]: The LanguageAdapter class is, yes.
<distant[m]>
(I also did ExampleMod's entrypoint because Fabric Loader's not reading `.rb` files, but anything outside of entrypoint should be able to just remain as `.rb` files.)
<byteit101[m]>
> JRuby is being shaded in Fabric Language Ruby.
<byteit101[m]>
That... may require some fixup
<distant[m]>
JRuby doesn't like being shaded?
<distant[m]>
I was hoping that wasn't it...
<distant[m]>
I guess I could try to get Loader's current libs directory at runtime...
<byteit101[m]>
I'm not sure. I know that there used to be load path issues with jar vs filesystem. Changing the loadpath may or may not help, as lots of gems are present in some paths in the jruby jar
<byteit101[m]>
iirc if you crack open the jruby jar there is a folder calls gems in the root of the zip
<byteit101[m]>
no idea if that has to or has to not move
<distant[m]>
`gems` is in META-INF/jruby.home/lib/ruby
<byteit101[m]>
on a hunch, I'm going to say shading isn't going to help unless the shader knows how to re-write the ruby code in the stdlib to know the paths to some jruby classes
<byteit101[m]>
but again, not 100% sure. enebo or headius would know
<byteit101[m]>
maybe I'm thinking of warbler packaging
<distant[m]>
Oh, right.
<distant[m]>
Is there a working jruby Gradle plugin?
<distant[m]>
The one I found had a issue with newer versions of Gradle (versions I need for Loom to work).
<distant[m]>
As much as I'd like to throw Gradle out of a 15 story window, I kinda need it for this...
<distant[m]>
I can *import* JRuby just fine, but Gradle doesn't seem to care much for `jrubyc`...
<enebo[m]>
I am not sure how much help I can be in this problem but jrubyc uses an implicitly loaded jruby runtime which has a specific embedded configuration
<enebo[m]>
I am not sure how much help I can be in this problem but jrubyc uses an implicitly loaded jruby runtime which has a specific embedded configuration
<enebo[m]>
This is the more flexible option for embedding but I don't actually know if jrubyc will bridge to this or not
<enebo[m]>
It gives a better mechanism over lifecycle of objects and I believe you can set the classloader used etc
headius has quit [Ping timeout: 240 seconds]
headius has joined #jruby
<distant[m]>
I'm actually not that great at Gradle dev... ;-;
<distant[m]>
I can do some ASM, and I've gotten Fabric Loader on all sorts of games, but I cannot for the life of me figure out how to make a Gradle plugin.
joast has quit [Quit: Leaving.]
<enebo[m]>
I have not ever done more than run gradle a small number of times
<distant[m]>
Oof
<distant[m]>
Let's ignore Minecraft and Fabric...
<distant[m]>
> org.jruby.exceptions.NoMethodError: (NoMethodError) undefined method `load_defaults' for Gem::Specification:Classses
<distant[m]>
Say I'm working on a perfectly normal and not edge case at all JRuby/Java project, and it refuses to start because of this.
<distant[m]>
* Let's ignore Minecraft and Fabric...
<distant[m]>
Say I'm working on a perfectly normal and not edge case at all JRuby/Java project, and it refuses to start because of this.
<distant[m]>
> org.jruby.exceptions.NoMethodError: (NoMethodError) undefined method `load_defaults' for Gem::Specification:Classses
<distant[m]>
> at RUBY.<main>(uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems.rb:1354)r Gem::Specification:Classses
<distant[m]>
Is this a problem that can be fixed, or at least worked around?
<distant[m]>
Still need to get a Gradle plugin working, otherwise it can't be used for Fabric/Minecraft...
<distant[m]>
(It can still work with other games just fine, Loom's only used for Minecraft.)
<headius>
I'm not in the office until tomorrow but maybe we can figure something out then, or enebo will have some additional thoughts
<enebo[m]>
distant: For the unknowm method I believe it is not picking up the ruby lib directory (unless you are using ruby-core or something which is not including lib/ruby at all)
<enebo[m]>
distant: It might be needing something like: -Djruby.lib="$JRUBY_HOME/lib"
<enebo[m]>
where you pass in the proper location
<enebo[m]>
but I would use jruby-complete if you are not and then rubygems should be seen
<distant[m]>
<enebo[m]> "distant: For the unknowm..." <- It's running Ruby code...
<distant[m]>
🤔
<distant[m]>
<distant[m]> "ew.png" <- I just had to break this to make it work.
<distant[m]>
Though I'm just pulling the `jruby` package...
<distant[m]>
Should I pull complete?
<enebo[m]>
When Ruby starts it tries to load rubygems on startup. You are running ruby but the runtime starting up is trying to load rubygems and it would appear to not be finding it
<enebo[m]>
jruby-complete probably will not have this issue
<enebo[m]>
since all of ruby stdlib is within the jar
<distant[m]>
Alright, I'll try it.
<distant[m]>
This is going to be one massive jar doe...
<distant[m]>
(At least as far as mods go...)
<distant[m]>
<enebo[m]> "jruby-complete probably will not..." <- Still has the issue.
<distant[m]>
;-;
<distant[m]>
Though it did add a noticeable chonk of Ruby, and is still fixable by just changing that one file to be bad, so I have no reason to revert.