Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
It seems to me that the RubyGems proxy for JRuby {1} is missing a major use case (which could perhaps become an key opportunity for Bintray). I'll describe the issue here.
While it's nice that the proxy serves gems so that they can be consumed (i.e., retrieved) by Maven or Gradle, a packaged gem is _useless_ to JRuby. If you try to stick a regular gem on the classpath, JRuby just won't know what to do with it. JRuby _only_ understands how to read a gem in its extracted layout.
You get the extracted gem layout by running `gem install`. The resulting layout format looks like this: gems/ asciidoctor-1.5.0/ lib/ asciidoctor.rb
asciidoctor/ ... specifications/ asciidoctor-1.5.0.gemspec No repository that I know of serves gems this way. Why? As a consequence, the application using the gem inside JRuby has to deal with all the grunt work of downloading the gem, installing it, bundling the extracted layout as a jar and adding the jar the classpath. In other words, we're shifting the onus of packaging onto the developer instead of the repository maintainer. This seems completely ridiculous to me. As far as the developer using JRuby is concerned, a gem should just be another jar file available in a binary (Maven) repository.
I see this as a great opportunity for binary repositories like Bintray. They can implement a repository transformer that takes the gem from rubygems.org, installs it (using these great plugins that we're making all the developers learn how to use {2}), bundles the extracted layout into a jar and serves the result as type = jar instead of type = rubygem.
If we had such a service, then requiring Asciidoctor Diagram in AsciidoctorJ would be a matter of adding the following dependency (shown in shorthand syntax) and you would literally be done! rubygems:asciidoctor-diagram:1.2.0:jar This would also allow us to take gems out of the AsciidoctorJ jar and just depend on them as transitive dependencies (that can be excluded if necessary).
To conclude, we should *not* be making users worry about installing and repackaging gems just to load them into JRuby. The repositories should be serving them gems this way! I'm I wrong? |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
It would make life a lot easier.
Even better if it can be done at source, meaning that rubygems make both versions available (gem+jar), so that the proxy services don't have to do the conversion. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
I agree, though I don't have high hopes of getting anyone to change rubygems.org. since JRuby is already using a proxy, and it's only relevant for JRuby, I don't see any downside of just doing it there. One thing is for sure. If we can get both formats, we are going to save ourselves a lot of time & energy. -Dan On Aug 26, 2014 5:18 AM, "ysb33r [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
It would make life a lot easier. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Totally agree, from the point of view of AsciidoctorJ users they will be able to exclude and add gems as any single jar.
|
Free forum by Nabble | Edit this page |