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.
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.
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.
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
