For the "cloby" gem, which exposes Clojure's STM and persistent list
as Ruby instance variables, I wanted to have a dependency on Clojure
directly from Maven, using JRuby's maven gem support. The gem name for
that looks like "mvn:org.clojure:clojure". This worked well as a
dependency in the gemspec, and local copies of the gem would also
fetch Clojure from Maven Central. But I was not able to push the gem
to rubygems.org.
Inability to push gems that depend on Maven artifacts waters down that
support considerably. It also means we would need to start pushing
Maven libraries to Rubygems.org for every such library anyone depends
on...which could mean hundreds of gems that only exist to wrap a JVM
library. I know nobody wants that (and that's why we built this
support into JRuby) so perhaps we can reach a compromise?
- Charlie
_______________________________________________
RubyGems-Developers mailing list
http://rubyforge.org/projects/rubygems
RubyGems-...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
http://guides.rubygems.org/specification-reference/#requirements
However this is yet another reason to have metadata :(
-Nick
-Erik
1) Gem names with ":" will not work on Windows, is not safe.
2) RubyGems cannot install gems across multiple repositories (so if
your maven wrapper is in another server it will not find it)
3) Last but not least: let's not turn RubyGems "dependencies" into
"anything this gem depend on".
RubyGems dependencies *must be* a gem.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
-Erik
I believe it has never been released, but is still in trunk waiting for the 1.9 release.
Nick, metadata is in!!
>
> -Erik
>
> On Oct 13, 2011, at 9:41 AM, Nick Quaranto wrote:
>
> > Erik, not sure what you're referring to...
> > On Oct 13, 2011 12:28 PM, "Erik Hollensbe" <er...@hollensbe.org (mailto:er...@hollensbe.org)> wrote:
> >
> > >
> > > Did my patch get reverted?
> > >
> > > -Erik
> > >
> > > On Oct 13, 2011, at 9:17 AM, Nick Quaranto wrote:
> > >
> > > > "dependency" is for "gem" dependency, let's keep it that way, please.
> > > There
> > > > is a "requirements" field in the gemspec that this could be used for
> > > > instead:
> > > >
> > > > http://guides.rubygems.org/specification-reference/#requirements
> > > >
> > > > However this is yet another reason to have metadata :(
> > > >
> > > > -Nick
> > > >
> > > > On Thu, Oct 13, 2011 at 11:47 AM, Charles Oliver Nutter <
> > > hea...@headius.com (mailto:hea...@headius.com)
> > > > > wrote:
> > > >
> > > > > I ran into a snag trying to demo JRuby's support for installing Maven
> > > > > artifacts as gems: rubygems.org (http://rubygems.org) does not allow pushing gems with
> > > > > external dependencies.
> > > > >
> > > > > For the "cloby" gem, which exposes Clojure's STM and persistent list
> > > > > as Ruby instance variables, I wanted to have a dependency on Clojure
> > > > > directly from Maven, using JRuby's maven gem support. The gem name for
> > > > > that looks like "mvn:org.clojure:clojure". This worked well as a
> > > > > dependency in the gemspec, and local copies of the gem would also
> > > > > fetch Clojure from Maven Central. But I was not able to push the gem
> > > > > to rubygems.org (http://rubygems.org).
> > > > >
> > > > > Inability to push gems that depend on Maven artifacts waters down that
> > > > > support considerably. It also means we would need to start pushing
> > > > > Maven libraries to Rubygems.org (http://Rubygems.org) for every such library anyone depends
> > > > > on...which could mean hundreds of gems that only exist to wrap a JVM
> > > > > library. I know nobody wants that (and that's why we built this
> > > > > support into JRuby) so perhaps we can reach a compromise?
> > > > >
> > > > > - Charlie
> > > > > _______________________________________________
> > > > > RubyGems-Developers mailing list
> > > > > http://rubyforge.org/projects/rubygems
> > > > > RubyGems-...@rubyforge.org (mailto:RubyGems-...@rubyforge.org)
> > > > > http://rubyforge.org/mailman/listinfo/rubygems-developers
> > > > _______________________________________________
> > > > RubyGems-Developers mailing list
> > > > http://rubyforge.org/projects/rubygems
> > > > RubyGems-...@rubyforge.org (mailto:RubyGems-...@rubyforge.org)
> > > > http://rubyforge.org/mailman/listinfo/rubygems-developers
> > >
> > > _______________________________________________
> > > RubyGems-Developers mailing list
> > > http://rubyforge.org/projects/rubygems
> > > RubyGems-...@rubyforge.org (mailto:RubyGems-...@rubyforge.org)
> > > http://rubyforge.org/mailman/listinfo/rubygems-developers
> > _______________________________________________
> > RubyGems-Developers mailing list
> > http://rubyforge.org/projects/rubygems
> > RubyGems-...@rubyforge.org (mailto:RubyGems-...@rubyforge.org)
> > http://rubyforge.org/mailman/listinfo/rubygems-developers
>
> _______________________________________________
> RubyGems-Developers mailing list
> http://rubyforge.org/projects/rubygems
> RubyGems-...@rubyforge.org (mailto:RubyGems-...@rubyforge.org)
system ~/projects/jruby $ gem install mvn:org.clojure:clojure
Successfully installed mvn:org.clojure:clojure-1.4.0.a.1-java
1 gem installed
system ~/projects/jruby $ ls lib/ruby/gems/1.8/cache/*clojure*
lib/ruby/gems/1.8/cache/mvn:org.clojure:clojure-1.3.0-java.gem
lib/ruby/gems/1.8/cache/mvn:org.clojure:clojure-1.4.0.a.1-java.gem
We have some additional tweaks to RubyGems to source them out of Maven
instead of having to push them to Rubygems.org. We did this to avoid
everyone pushing their own copy of every maven artifact in the world,
which I think you all would agree is best.
Here's the deal...
JVM libraries are as useful to JRuby users as gems are. There's tens
of thousands of them available. They're generally published by the JVM
community to Maven repositories, primarily the "central" repositories
that act like rubygems.org does for RubyGems. JRuby users want to use
those libraries in their apps and depend on them in their gems. In
order to do that, one of two things need to happen:
1. They push a gem that contains the libraries. This means potentially
hundreds or thousands of binary jar files wrapped in gems and pushed
to rubygems.org, and updated as those libraries are versioned. This is
what you are recommending to me.
2. They use JRuby's maven/gem integration to source the libraries
directly from maven, transparently wrapped in a gem at install time. I
think this is preferable in many ways, but since those gems don't
exist on rubygems.org it's not an option.
I can certainly make a recommendation to JRuby users that they should
start pushing maven artifacts as gems to rubygems.org, if that's what
you'd prefer. I could also set up a nightly/weekly job to scan Maven
Central and push tens of thousands of jars-in-gems to rubygems.org, so
we'd know they're available for JRuby users.
I don't think anyone wants that, though. :)
Suggestions?
- Charlie
I'll look into that. I know we have tests for this functionality that
pass on Windows...
> 2) RubyGems cannot install gems across multiple repositories (so if
> your maven wrapper is in another server it will not find it)
The Maven logic is built into our copy of RubyGems directly; it knows
if it sees anything prefixed with "mvn:" it uses Maven to source the
contents of that gem, rather than looking on rubygems.org.
> 3) Last but not least: let's not turn RubyGems "dependencies" into
> "anything this gem depend on".
How would you recommend people grab the required libraries? Like I
said in other posts, I can certainly recommend that they start
wrapping and pushing those libraries to rubygems.org, but I don't
think anyone wants rubygems.org bloated up with thousands of jar
files.
> RubyGems dependencies *must be* a gem.
These *are* gems...we just build them dynamically by sourcing the
contents from Maven.
- Charlie
* No duplication of every Maven artifact on rubygems.org
* No conflicting gem versions from different users pushing their own
copy of jars-in-gems
If there's a simple way to handle this with metadata or requirements,
I would love to hear it!
- Charlie