Move all main classes to org.jruby.main package - #9024
Conversation
Sorry, something went wrong.
|
This is the recently-promised move of "mains" to the org.jruby.main package. One problem presents itself immediately: if we change the jruby.sh file to reference org.jruby.main.Main it can't be used on earlier versions of JRuby than 10.0.3.0. Given that we have been hoping to single-source this file for all supported releases, that's probably not acceptable. I think one solution would be to make the jruby.sh file default to the old org.jruby.Main class name, but allow customizing the main to use via some file in the bin dir (.jruby.mainClass for example). Older releases would not have to be modified, but newer releases could provide this file pointing at the new org.jruby.main.Main. Thoughts @enebo @mrnoname1000? This also might be too aggressive for 10.0.x and better for 10.1.x or even 11.x. |
Sorry, something went wrong.
|
Yeah I think this is ok without major since the original will continue to work and based on number of .xml references there will be a lot of stuff out in the wild still calling it (and if they want to support 9.4 or older they have to continue calling the older version). There is possible value backporting to 9.4 as well which might be enough for people to just change over once we put out a release containing the new change. |
Sorry, something went wrong.
enebo
left a comment
There was a problem hiding this comment.
Left comment in PR itself but as old main continues to run this can land any time.
Sorry, something went wrong.
|
It is too bad there is not a simple embedding somewhere to get JRuby version from the launcher script. This would be an extra file access (unless it is somewhere we already read) but it would elegantly allow script to choose proper main. |
Sorry, something went wrong.
I will also remove the "forRemoval" attribute from org.jruby.Main at least, since it can prevent compilers from allowing access at all. JarBootstrapMain isn't really well known and extremely unlikely to be used as an API, so I'll leave it there and we can remove it soon.
Yeah since it's still being maintained I think there's no harm in making the same change there.
My idea above would be to add a bin/.jruby.mainClass file, but perhaps we should make a more generic file that can also contain things like the version number? That could easily be updated with our current build scripts, and we'd always have a way to get that information from now on, similar to the JDK "release" file. Perhaps bin/.jruby.release? |
Sorry, something went wrong.
This copies org.jruby.Main and org.jruby.JarBootstrapMain to the org.jruby.main package where we keep other "mains". This is in part to localize mains but also to start removing classes from org.jruby package that don't need to or should not be accessed by users. In this case, we don't recommend using Main to execute JRuby from within an already-running JVM, preferring our embedding APIs or using org.jruby.Ruby directly. JarBootstrapMain is rarely (if ever) used, so we'll also move it alongside other mains. JarBootstrap main is marked for removal, since nobody is likely to be using it as an API. org.jruby.Main is not marked for removal, since it almost certainly is being used as an API and the removal attribute might prevent that code from compiling at all.
|
I have made a small tweak to the original commit (omit forRemoval from org.jruby.Main) and added support for a bin/.jruby.release file. This new file contains two values: JRUBY_VERSION and JRUBY_MAIN. The main value will be used to select a main class, or else default to the old org.jruby.Main. The version value is used in environment output. @mrnoname1000 I'd like your review on my shell changes, and also your thoughts on #9028 and how we might approach that. |
Sorry, something went wrong.
In order to keep the same shell script across versions, this introduces a new dotfile bin/.jruby.release which currently contains two values: * JRUBY_VERSION reflects the version of JRuby associated with this bin directory. * JRUBY_MAIN indicates the main class to use when launching. This allows the script to start using the new org.jruby.main.Main instead of the old location without breaking existing releases that don't have that class.
|
@enebo Review additional changes and let me know what you think. |
Sorry, something went wrong.
Co-authored-by: mrnoname1000 <mrnoname1000@riseup.net>
|
Should be all good now with suggestions from @mrnoname1000 integrated. I'm inclined to merge this and deal with fallout as it happens (which should be minimal since org.jruby.Main remains available). Full speed ahead! |
Sorry, something went wrong.
Equivalent to jruby#9024, minus the moves of "main" classes.
This copies org.jruby.Main and org.jruby.JarBootstrapMain to the org.jruby.main package where we keep other "mains". This is in part to localize mains but also to start removing classes from org.jruby package that don't need to or should not be accessed by users. In this case, we don't recommend using Main to execute JRuby from within an already-running JVM, preferring our embedding APIs or using org.jruby.Ruby directly. JarBootstrapMain is rarely (if ever) used, so we'll also move it alongside other mains.
The old classes have been deprecated for removal.