Answering below and then summarizing *exactly* how our maven gem stuff works.
On Tue, Jan 17, 2012 at 7:51 PM, Eric Hodel <drbr...@segment7.net> wrote: > On Jan 12, 2012, at 10:29 AM, Luis Lavena wrote: >> So what you're suggesting, even you stated differently is that you >> want to pollute rubygems.org with maven artifacts wrapped as gems? ... > So I take this to mean that the clojure gem only exists on the user's machine > while installed and not on rubygems.org nor anywhere else. That is correct. Maven artifacts are managed much like RubyGems, with a central server (really many "centrals"). The main namespace is "group", which would be something like org.jruby. Under group there's "artifact" which would be "jruby" for the main JRuby library, "jruby-complete" for the jruby jar that includes stdlib, and so on. All this is managed in an XML-based specification file (pom.xml) which additionally contains other library dependencies, library information (desc, authors, home repo, web page), testing information, build information, and so on. Maven is like RubyGems + Rake (+ 5000 other things) all in one. JRuby's support for "maven gems" basically just uses Maven to fetch the given library's pom.xml, convert that into a gemspec, and then pass that off to RubyGems to install. We hook into spec retrieval and file download in both cases, looking for "mvn" prefix to indicate that we need to look at Maven Central instead of RubyGems.org. The mechanism is fairly elegant, since RubyGems does all the version and dependency walking. At install time, the process goes like this: * Our RubyGems recognizes that this is an mvn: gem and uses our Maven logic to build a gemspec * The gemspec is returned and RubyGems processes it as normal * Dependencies that are also mvn: gems go through the same process * Finally, when it comes time to fetch the actual gem, our RubyGems again recognizes that it's a mvn: gem, fetches the jar file (or whatever) for the Maven artifact, and wraps it up in a rough gem structure. The resulting gem only exists on the user's local system; it is "virtual" in nature. The gem mostly just contains the jar file, but we also throw in a few simple .rb files for easy loading, version numbers, and getting the real path to the jar file on disk. If the dependency restriction is dropped, that's 90% of our issues solved. I fully endorse that change :) The other piece that would be "nice to have" is making it possible for gems to either: a) automatically source pieces of them from another location; e.g. pull the gem from RubyGems.org but the jar from somewhere else OR b) make it easier to hook the spec retrieval + gem fetch process I prefer the latter, since it allows us to build the gems any way we want, so long as we feed RubyGems a valid spec and provide it smarts to get a .gem file in hand. This thread is fine to discuss the additional support, I think. Questions? Comments? - Charlie _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
