Exposing rubygems.org in a Maven format for Java tooling

[R. Tyler Croy]

Howdy, I am the maintainer of JRuby/Gradle [0] which is one of a number of
tools in the JRuby ecosystem which consumes Rubygems in a Maven-dependency
format.

I was wondering if it would be possible to "upstream" the serving of
rubygems.org as a Maven repository? We currently rely on the rubygems-servlets
[1] code which transforms and caches gemspecs to Maven pom files, and is hosted
at: <http://rubygems-proxy.torquebox.org/>

That service can be slow at times, and is unfortunately not TLS encrypted.

My preference would be to host something within the rubygems.org
infrastructure, and I am more than happy to do the maintenance work if this is
something the rubygems.org maintainers would be open to. rubygems-servlets
easily drops into a Jetty/Tomcat instance, which I doubt you all are running at
the moment, but it's also pretty easy to drop into a container and deploy into
k8s, ECS, etc.


Do let me know if this is something we could work out :)


[0] http://jruby-gradle.org
[1] https://github.com/torquebox/rubygems-servlets


Cheers
--
GitHub: https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

[Evan Phoenix]

Putting the additional burden on the admin team of rubygems.org to run this unknown component is a hard sell.

I'm also confused how rubygems.org running it would solve the problems you've indicated, other than it wouldn't be you dealing with them. :D

If it were written in Ruby itself and we could add it to our canonical rubygems.org app that would be a much easier sell (but still comes with understanding the performance implications given our reliance on fastly caching).

Can you tell us more?

 - Evan

--
You received this message because you are subscribed to the Google Groups "rubygems.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[R. Tyler Croy]

(replies inline)

On Mon, 06 May 2019, Evan Phoenix wrote:

> Putting the additional burden on the admin team of [1]rubygems.org to run this

> unknown component is a hard sell.

I am a maintainer of the Jenkins project's infrastructure, so I definitely know
the feeling :)

> I'm also confused how [2]rubygems.org running it would solve the problems

> you've indicated, other than it wouldn't be you dealing with them. :D
>

> If it were written in Ruby itself and we could add it to our canonical [3]

> rubygems.org app that would be a much easier sell (but still comes with
> understanding the performance implications given our reliance on fastly
> caching).
>
> Can you tell us more?

Running the service under rubygems.org would help address the challenges we
have depending on some third-party service run by somebody somewhere with an
undefined level of service. I don't mean to suggest that I wouldn't be dealing
with the service issues, that is not my intent. Rather I would be able to help
operate/deploy the service as part of an group which maintains other open
source infrastructure.

The thought of implementing some verison which can go into the rubygems.org
application is really an interesting idea that I had not considered before.
Really all Gradle, Maven, and any other Java-land tool which may want to
consume Ruby dependencies just needs to speak Maven formatted XMLs. Adding that
to rubygems.org might actually be a fair bit simpler than rubygems-servlets
which can act as a caching mutable gem repo.


If the idea of teaching rubygems.org how to emit Maven XML is agreeable, then I
can take a whack at creating a pull request. I wouldn't want to spend the time
if the idea is abhorrent to the maintainers of the rubygems.org app :)