-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adds compatibility to install gems with jruby > 9.2.10.x #106
adds compatibility to install gems with jruby > 9.2.10.x #106
Conversation
I see the project fails because Travis is using Java 11 which fails. Not sure this is blocking. I could make the project build and pass all test with Java8, but going higher requires more work. After this PR we could discuss on "up-to-date" roadmap? At least make it so the project is build with Java11 but is still compatible with Java 8 if necessary. |
@mkristian any comment? |
We also need this change. |
try { | ||
return this.factory.getVersion(); | ||
} catch (Exception e) { | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we really need to swallow silently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would argue a not aborting with hard failure here is not the end of the world...but...
- It should warn that it cannot detect version (I think what @kares wants?)
- It should not emit no rdoci/ri since it really does not know what jruby version it is (and therefore will work for all versions of jruby).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right @enebo, in some way the idea was to keep it as similar as possible with current behauviour. So if for some reason the version could not be extracted*, I prefered a more "optimistic" approach and fall back to current behauviour. The code is 1.5 so could not use Optional which may had been nicer.
About the warning is not so easy, I can inject the Logger from the mojo when called from AbstractGemMojo, but not when called from RailsService. To avoid extra checks I could use Slf4j if it's ok, Maven picks it up. or just create a Slf4j if none is injected.
*Note we would need to parse several differents formats for differents Ruby implementions and for now I focused only on jruby.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@abelsromero Sounds reasonable to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a second thought I think it doesn't make sense to treat that in GemInstaller. I move it to ScriptFactory and added a WARN message there.
wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for building on this!
I added inline reader's notes, all of which are from a Ruby person's perspective, with uneasy Java fluency.
<groupId>rubygems</groupId> | ||
<artifactId>pom_first</artifactId> | ||
<version>0.0.0</version> | ||
<description>Installs a gem from http://rubygems.org with Ruby 2.7 compatibility</description> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is a line which made me wonder: http vs https?
It's not recommended to request gems via http from rubygems.org.
Is there a special reason to not use https in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only reason is legacy configuration. Right now it shows a warning but works, and I see there're other places where http is used that are not Java so not sure of the impact.
I am happy to work on it but I'd rather do it in a separated issue. wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Separate issue, totally right decision, and it's not a priority for me. Thanks for answering!
File f = new File( basedir, "target/rubygems/gems/yard-0.9.25" ); | ||
if ( !f.exists() ) | ||
{ | ||
throw new RuntimeException( "file does not exists: " + f ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Grammar note:
throw new RuntimeException( "file does not exists: " + f ); | |
throw new RuntimeException( "file does not exist: " + f ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I will also check the other tests, I recall copying it.
return true; | ||
|
||
if (minor < Integer.parseInt(parts[1])) | ||
return true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder here, the minor
and parts[1]
seem to be compared in separation of major
.
Does this mean that 2.5.0 would be considered lower than 1.9.2?
Perhaps I'm just confused, that could also be it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just added that case to a test and you are right. I will fix and add more extra tests to JRubyVersionTest
to ensure all cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<3
Thanks to @olleolleolle's comment I fount the approach was not reliable because jruby always reports 2.5.7 and my test where working due a false positive. I tried other options and asked int the jRuby Matrix channel and no solutions was available 😞 At the end I check the explicit jRuby version. Also, today I check what jruby-gralde-plugin is doing and they just use @enebo @olleolleolle @kares PR ready for final review 🚀 |
I filed #108 to remember the JDK11 issue. |
Any comment? |
I will review soon! |
Any progress? |
@headius Any progress on this one? 😃 |
Sorry this got left behind. Looking into it now. |
The tests are failing on Travis because they run with Java 11 and use JRuby 1.7.3 for certain actions, and "11" is rejected as a version number by JRuby 1.7.3. I am testing locally to confirm things are working, and then will fix the use of this very old JRuby. |
The branch appears to fail for a different reason locally, but master also fails for the same reason. So the tests are a bit out of date (like most of this library) and I think we can go ahead with merging this. |
This PR was a bit messy to review, due to the many whitespace and formatting changes throughout. I am guessing some of these were done automatically by a tool or an IDE, which is difficult to avoid. The changes appear to align the associated files with JRuby standards for source formatting, so I will still proceed with the merge. There's also a spelling correction of "exists" to "exist" throughout that made the diff much larger than it needed to be. In the future, please keep whitespace, spelling, and documentation changes in their own PRs if they are not directly related to the PR's primary changes. And finally, thank you for putting this together and being so patient about it being merged! It has been a crazy summer. @mkristian I will merge this, but I can't remember if I have Maven publishing rights or not. Either way we will want to do a release...possibly after fixing #107 if it is not already. |
Spot on! I was aware of that and I checked if there was any formatting configuration in the docs, but saw nothing, and trying to keep the current formatting manually was impossible and extremely unproductive.
If so, formatting configuration should be provided in the project. If there's any guide, point me and I can look into it. Otherwise, for the sake of lowering the barrier of entry I would stick with whatever most popular IDE provides ootb. |
@abelsromero Yeah I understand the difficulty, especially since the sources in this project were pretty far from typical Java formatting ("else" and friends on new line, tabs instead of spaces in some places, etc). In general the standard is really just typical Java formatting guidelines. IDEs may vary, but I don't believe any will automatically use the formatting that existed here. |
Actually I think it wasn't tabs as much as useless whitespace on newlines that got cleaned up, but again I think most IDEs would deal with that better. We will try to format things better going forward. If your IDE happens to "fix" another file, don't worry about it too much. |
This PR fixes #105 by checking the Ruby language version. If 2.6 or higher, it will replace the
rdoc
andri
arguments (noew deprecated) by the supporteddocument
. Older versions of Ruby runtimes will work same as now.Only thing I am not confident is that when running
mvn clean test -pl gem-maven-plugin -am
I get this errorgem-maven-plugin: Execution default of goal org.apache.maven.plugins:maven-plugin-plugin:3.4:helpmojo failed: The source must not be a directory
. Any idea?It also:
rubygems-in-test-resources-failure
test. This caused false positives when running all IT tests (those run by maven-invoker-plugin) in a specific order.include-rubygems-in-test-resources
adding the correct dependency. This worked due to previoud comment, but failed when run in isolation.