Hi Kristian, thanks for your response.
I'm very sorry but I have a hard time trying to understand your point.
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.
So, why are you worried that we *should* use Maven for that purpose
which is already achieved by Bundler?
"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.
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
