On Tue, Mar 27, 2012 at 9:09 PM, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com> wrote: > Here is my point of view about this subject. > > We're comparing different things here. > > RubyGems can be compared to Maven but I don't think Bundler has anything > similar in other languages I know about. >
> Bundler will generate a Gemfile.lock that will assure that the exact > dependencies versions can be replicated in other environments. > unless you use version ranges which are there for quite some time in maven, there is no need for Gemfile.lock > Until recently Maven didn't support adding dependencies like '>= 1.2' like > RubyGems supported. [1.2,) works already with maven2. even the rubygems default [0,) is possible. that is why the mapping from rubygems to maven works recently well, since you can map (almost) rubygems version to maven and resolve them in rubygems manner. >Now it supports but I still believe there is no such > tool like Bundler for Maven yet. > maven discouraged the use of version ranges because it breaks things over time. > So we shouldn't be comparing different tools as if they were the same thing. > Bundler is quite different from Maven for us to compare them both. Maven can > be compared to RubyGems and in fact JRuby RubyGems already was patched to > support installing Maven artifacts as Ruby gems. > which suffers exactly what I tried to say in my first comment, it can not and will never be able to install ALL maven artifacts. rubygems and bundler uses version ranges and try to find a set of version which obeys any such version constraints. BUT maven version resolution does this with only version ranges but any "fixed" version is resolved differently. actually you can not install the jruby maven artifact with that jruby maven gem support !!!! what about parent pom, i.e. hierachies of poms. or import dependencies from other poms ? even IVY is not able to do the job right with maven pom, which was recently on the jruby-users list. > What is still missing is adding support for Bundler to also be able to > manage Maven artifacts specified in the Gemfile. > just use maven or aether to do the job right and not create something which does not work sooner or later since you choose the "wrong" maven artifact. actually I personally use a Mavenfile along bundler where I specify my jar dependencies (in Gemfile like manner). let maven setup the classpath and bundler setup the gems. then I create binstubs like bundler which handle both the gems and the classpath. the tool for that is ruby-maven. there I get the jars as if I would specify the same jar dependencies inside a java pom.xml. and to obey Gemfile.lock with locked down jar dependencies from version ranges should be a minor change ;-) maybe a Mavenfile.lock :))) regards, Kristian > Cheers, > Rodrigo. > > Em 27-03-2012 12:10, Peter Fitzgibbons escreveu: > > 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: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 >>>> >>>> >>> >>> >> > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
