On Tue, Mar 27, 2012 at 10:26 PM, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com> wrote: > That may seem like a small project for you that already knows about all > internals for writing such project, but this is not trivial to me. > > I don't even know how to make Maven resolve my gem dependencies. >
you can use https://github.com/torquebox/jruby-maven-plugins/tree/master/gem-maven-plugin/ which comes basically from me. regards, Kristian > Em 27-03-2012 13:52, kristian escreveu: > >> hi again, >> >> after so much writing and hoping to make myself understood. >> >> actually it seems like a small project. >> >> given a Gemfile like >> >> jar 'xerces' >> jar 'xalan' >> >> make a "pom" out of it.let maven/aether resolve the deps. locked the >> versions of the above two jars and use the rest to build up the >> classpath with jruby. >> >> :)) >> >> regards, >> Kristian >> On Tue, Mar 27, 2012 at 10:07 PM, kristian<m.krist...@web.de> wrote: >>> >>> hi Rodrigo, >>> >>> I think it should be no problem to have something like >>> >>> jar "xerces" >>> >>> in your Gemfile or Mavenfile and let bundler fix the version for it. >>> my concern is after fixing of all the version of xerces, xalan, etc >>> then transitive dependency must come from a maven deps resolution. >>> >>> that is easy to achieve, all the code does already exists you just >>> need to cherry pick things. >>> >>> with regards, >>> Kristian >>> >>> >>> On Tue, Mar 27, 2012 at 9:59 PM, kristian<m.krist...@web.de> wrote: >>>> >>>> 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
