[Rubygems-developers] Specifying equivalent modules?

Charles Oliver Nutter charles.nutter at sun.com
Thu Apr 19 23:49:18 EDT 2007


Jim Weirich wrote:
> Zed would not have to be "responsible" for releasing a java platform
> mongrel gem.  Someone else could do all the work and even handle the
> release.  The only coordination that would be required is that for a
> given version number, the C platform and the Java platform gems have
> compatible APIs.

So is the right answer that if we made mongrel gems for the Java version 
and just handed them over to Zed to publish through RubyForge, that 
would be the right way to go forward? That probably works well enough, 
but perhaps there's issues of who to come to with problems on the Java 
version (people will go to the project they got it from) and similar 
questions. Maybe that's not a big deal.

> The two platforms would require some level of
> compatiblity anyways, otherwise plain ruby software would not be able
> to run on the other.  The reason for the version alignment is so that
> if my software requires version 1.2 of mongrel, it means the same
> thing in both MRI and JRuby land.

This is all cool...indeed the goal of these ports is to provide a gem 
that looks and feels in JRuby just like the C version of the gem looks 
and feels in MRI. And in cases like Mongrel and Hpricot, that's exactly 
what we have.

> On version alignment, the two platforms wouldn't even to be *exactly*
> aligned.  Generally (if used properly in the Gem world), only the
> first two numbers of a version denote features.  The third (and beyond
> third) number in the version generally denotes build revisions.  So,
> if mongrel-C and mongrel-JRuby keep feature aligned on the first two
> numbers in a version, i suspect that would be adequate.

In this case, the only piece that's even different is the HTTP request 
parser, which is generated from Ragel source for both the C version and 
the Java version, so tracking features almost happens automatically. The 
hard part is making sure it's built and appropriate for current JRuby 
(soon to be 1.0ish) and the publishing issue.

> The only other (minor) problem I see is that currently RubyForge
> requires that a Gem come from a single RubyForge project.  I suspect
> we can convince the RubyForge guys to allow different platform gems to
> come from different projects.

That would actually be enough if you ask me...but only if it's 
considered "ok" within the gem-publishing world. I've seen others get 
very upset in a few cases where a gem was accidentally published that 
had the same name as another, causing some trouble and confusion. It 
would be trivial for us to create our own gem and handle publishing it 
to our own jmongrel project, if it could fulfill the requirement of 
"mongrel" other gems specify. Perhaps there should be something in the 
list of gems specifying that this is "mongrel (java, "jmongrel")" so 
people know if they're getting a gem from a potentially different project?

- Charlie


More information about the Rubygems-developers mailing list