On Tue, Mar 27, 2012 at 9:43 PM, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com> wrote: > Em 27-03-2012 13:02, kristian escreveu: > >> 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 > > > Here is how I think about it. When I specify on Gemfile that my software > depends on 'nokogiri', it means I don't care which version as long it works. > > When I specify some specific version, it means I explicitly know that I want > that version, but this usually doesn't happen. > > Then Bundler will remember what are the exact versions of the gems that > worked for me when I developed my application. > > I don't see any issues with that, but I wouldn't like to manage my > dependencies versions manually as it doesn't make sense to me. > > >>> Until recently Maven didn't support adding dependencies like '>= 1.2' >>> like >>> RubyGems supported. >> >> [1.2,) >> >> works already with maven2. > > > Yes, I know, that is why I've said "until recently", > > >> 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. > > > That is because they don't have a tool like Bundler, so they suffer from the > same problems as RubyGems. > > >>> 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. > > > Which seems like a correct and logical approach to me. > > >> BUT maven version resolution does >> this with only version ranges but any "fixed" version is resolved >> differently. > > > Which seems wrong to me. If I specify a fixed version I want it to be fixed > and I'd like to be reported if that is not possible instead of trying to get > a best guess. >
no it is not a guess, it is the version closer to the root which gets taken. and you are not in a position to change that but that is what people are using. > >> 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. > > > We don't need to fix all corner cases in the first moment. We will be able > to handle 80% of the Maven dependencies without getting into corner cases > handler. We can discuss about them later I guess. > since even jruby uses maven for the jruby maven gems, you have already mixed environment and you will need to get the poms resolved into the "effective pom" before you can use it in anyways. and mapping it onto rubygems version ranges is a mess I did do it for quite some time now with that maven-gems support of jruby and decided not to continue since it will remain a big mess. aether is meant to embed maven dependency resolution outside of maven. to use it will give you the 100% and bundle can even take care of the version ranges here and there. > Ivy is still working for many people even if it doesn't integrate seamless > with Maven. > > >>> 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. > > > Sorry, didn't understand this statement. > > sorry. with my maven-gems from jruby people started to use real world maven dependencies and it resulted into more and more hacks to get this or that working too. maven dependency resolution is not compatible with bundler or rubygems !!! regards, Kristian >> 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 :))) > > > I really would prefer to avoid this messed environment if possible. If we > could manage all our dependencies with a single Gemfile it would be just > perfect. > > That is my opinion at least. > > Thank you for your input, > > 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