sorry for the late responds. so I try to indicate some problems: * maven artifacts can be relocated and it can be just relocated to a new version. ie. you depend on xml-api-3.0.1 and actually get xml-api-3.0.2
* for example maven3 has a version 3.x :) but is backwards compatible with maven2 3.x. so having the same version of the artifact inside the dependency hull is a version conflict which maven resolves by using the version of the artifact which is closer to the root, i.e. to your pom. in this case if it is maven3 then the conflict is solved and due to the backward compatibility layer of maven3 there is no code conflict !!!! * maven considers version ranges as broken (which is the reason of a many problems with rubygems) and uses just the version. in case of version conflict the closer to the root resolution takes place, i.e. maven does not guarantee that version from your transitive poms gets obeyed BUT it does guarantee that it is reproducible (i.e. it does not break because there is suddenly a new version of a lib which does break things in your code) * maven version can be anything there is no semantic in it - it is just a string ! actually it works kind of OK to map rubgems onto maven and resolve all the dependencies with maven - prereleased version are a bit problematic. but the other way around it was quite a challenge and there were always artifacts which did not map onto rubygems. and then one point is that my project is tested against a set of dependencies, i.e. the set of dependencies maven resolves. if rubygems or bundler are not able to reproduce the same set of dependencies what is the meaning of my tested code ? - Kristian On Tue, Mar 27, 2012 at 8:40 PM, Peter Fitzgibbons <peter.fitzgibb...@gmail.com> wrote: > 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
