I may be a biased editor... I personally believe RubyGems is broken, certainly around dep-resolution. I point to CPAN a lot as an example of library repository that sums up all the best-practices. Maven may do the same, though I haven't learned it.
I believe the existence and adoption of Bundler is a clear indication that the community needed to move beyond Rubygems. Thoughts? Peter Fitzgibbons (847) 859-9550 Email: peter.fitzgibb...@gmail.com IM GTalk: peter.fitzgibbons IM AOL: peter.fitzgibb...@gmail.com On Tue, Mar 27, 2012 at 7:44 AM, Nick Klauer <kla...@gmail.com> wrote: > Wouldn't the simplest solution be to do what I've seen other projects do > and just implement some wrapper around Aether ( > http://www.eclipse.org/aether/)? I know that Leiningen's 2.x version > that they are working towards is using it, and it simplified their API > quite a bit in resolving dependencies, handling multiple maven > repositories, etc., without forcing them to adopt the entirety of Maven's > settings.xml and other configs. > > I think the point Kristian's making is that Rubygems shouldn't care about > Maven deps, their layout, and Maven-related issues such as pom-only > dependencies, transitive dependencies, SNAPSHOT versioning, etc., yet Maven > shouldn't have to care about Ruby's idiosyncracies along the same lines, > either. > > I think the crux of this issue is finding out how much one side will end > up treading on the other to get the job done, and if there's a clean way to > keep them separate. > > -Nick Klauer > > > > On Tue, Mar 27, 2012 at 07:20, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com > > wrote: > >> It was a bit confusing to me too, but I guess he is saying that you >> shouldn't try to convert each maven artifact to a gem and let RubyGems >> manage the dependencies instead of Maven. >> >> Honestly I don't know what is the advantage of this approach. I mean, >> Kristian, why do you think the Maven dependencies management algorithm >> would be better than RubyGems or Bundler. >> >> Notice that I don't really care which approach is used, I guess the >> easiest one to implement should be taken. >> >> I just think that letting Maven resolve the dependencies would be weird >> as it won't know about the Ruby dependencies and won't be able to find out >> the better resolution like RubyGems or Bundler could do as they're aware of >> all dependencies. >> >> Could you please detail what approach do you think should be taken, >> Kristian? >> >> Cheers, >> Rodrigo. >> >> Em 27-03-2012 08:11, Peter Fitzgibbons escreveu: >> >> Can someone point me to a doc that decyphers what kristian just said? >> Interesting! >> >> Peter Fitzgibbons >> >> On Tue, Mar 27, 2012 at 2:07 AM, kristian <m.krist...@web.de> wrote: >> >>> On Tue, Mar 27, 2012 at 5:36 AM, Rodrigo Rosenfeld Rosas >>> <rr.ro...@gmail.com> wrote: >>> > Finally integrating Maven to Bundler would be terrific. I would >>> certainly >>> > vote on this project! >>> >>> as long it opens the whole maven artifact universe and NOT tries to >>> map an maven artifact onto a rubygem and hope that the quite different >>> rubygems version resolution gives a somewhat similar result as with >>> maven. (i.e. use maven for resolving the transitive dependencies). >>> >>> then I would vote it too ! >>> >>> regards, >>> Kristian >>> >>> >>> > Cheers, >>> > Rodrigo. >>> > >>> > Em 26-03-2012 20 <26-03-2012%2020>:45, aliaksei escreveu: >>> > >>> >> I would like to participate in gsoc as a student. >>> >> I have the same difficulties as Benoit. But i'm interested in Maven >>> >> support for Rubygems and Bundler and Runtime code optimization in >>> >> particular. >>> >> >>> >> So, Is there any mentors of that specific projects that i could >>> >> contact directly? >>> >> >>> > >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe from this list, please visit: >>> > >>> > http://xircles.codehaus.org/manage_email >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >> >> >
