hi, On Tue, Mar 27, 2012 at 9:31 PM, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com> wrote: > Hi Kristian, thanks for your response. > > I'm very sorry but I have a hard time trying to understand your point.
I am afraid of that but I do my best to clearly things :) Could > you please elaborate using some real examples so that we could discuss on > top of those? > > > " if rubygems or bundler are not able to reproduce the same set of > dependencies what is the meaning of my tested code ? " > > Bundler can. That is why it was created in the first place. It already > solves the issue of being able to reproduce the exact versions of the > dependencies by the use of Gemfile.lock. That is exactly the existent > problem with RubyGems and the reason why Bundler was created. > first I assume the maven artifacts do not use version ranges which are still (luckliy) rare. maven artifact A is tested with a set of dependencies within maven. now bundler use the same artifact A but resolve the set of transient dependencies in bundler way which might/will be a different result then what maven produces. it is even possible that bundler can NOT resolve a working set of version for that artifact A. so testing uses one set of dependencies and using it with bundler uses a different untested set of dependencies for the artifact A. > So, why are you worried that we *should* use Maven for that purpose which is > already achieved by Bundler? > some keywords: * poms with classifier, * relocated poms * import dependencies from a pom, * poms which have a dependencies hull which can NOT resolve by rubygems. * poms which act on the OS you use via profiles so the world is bigger than it looks first !!! > > "maven considers version ranges as broken (which is the reason of a many > problems with rubygems) and uses just the version" > > I didn't understand this statement either. Maven now supports version ranges > so why do you think they're broken. It is just that now Maven suffer from > the same pain as RubyGems. The difference is that I don't know any > Bundler-like project for Maven. > yes, maven does suffer from the same as rubygems does whenever someone uses version ranges ! and there is no bundler like project for maven though I tried to explain Jason van Zyl what bundler does. was not impressed since you can read regularly in maven user list that you should avoid version ranges since they break your build (over time). yes, rubygems without bundler is "broken" so are maven artifacts with version ranges (until a bundler-maven pops up from somewhere). so a typical maven dependency is <version>3.0.1</version> but maven might use version 4.0.0 instead depending on the dependency hull. but in can be the other way around as well and maven choose version 2.0.5 regards, Kristian > Best, > Rodrigo. > > > In 27-03-2012 12:43, kristian wrote: >> >> 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
