Move all main classes to org.jruby.main package#9024
Conversation
|
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 I think one solution would be to make the jruby.sh file default to the old Thoughts @enebo @mrnoname1000? This also might be too aggressive for 10.0.x and better for 10.1.x or even 11.x. |
|
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. |
enebo
left a comment
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.
|
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. |
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 |
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 @mrnoname1000 I'd like your review on my shell changes, and also your thoughts on #9028 and how we might approach that. |
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. |
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 |
Equivalent to jruby#9024, minus the moves of "main" classes.
3 participants
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.