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
