Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there seriously not a better way to depend on JARs? #1

Open
mmmries opened this issue Jan 20, 2014 · 6 comments
Open

Is there seriously not a better way to depend on JARs? #1

mmmries opened this issue Jan 20, 2014 · 6 comments
Labels

Comments

@mmmries
Copy link
Owner

mmmries commented Jan 20, 2014

Right now this gem vendors several jars (has a copy of the jar in the distributable gem) and it requires them conditionally (see 6dc5898) to try to make sure we don't clober the same jars from some other gem, but this is obviously not a great idea.

We really only want jstyleparser 1.7.0, but have to manually handle all of its dependents. It looks like @mkristian has been trying to work on this problem for a while (https://github.com/mkristian/jbundler/wiki/Gem-with-declared-jars) but it doesn't look there has been any community-wide acceptance for this standard. I would love to see bundler support this natively, but in the meantime is there any better option than vendoring + conditionally requiring?

@mkristian
Copy link

I will share some ideas later today or tomorrow - maybe with jruby-9000 this situation improves ;)

@mkristian
Copy link

please have look at http://blog.mkristian.tk/2014/01/rubygems-with-java-extensions.html
and the branch jar_dependencies of https://github.com/mkristian/ruby-maven-demo/tree/jar_dependencies

which shows a few steps further then the proposal from jbundler. so I hope thing start to materialize soon ;)

@mkristian
Copy link

so finally I got around and did my first gem with native-extension which basically installs the declared jar dependencies. see

https://github.com/mkristian/ruby-maven-demo/tree/no_vendored_jars

the simple gem has jar dependencies but does not vendor them. on install of the gem those jars will be installed in the local repository and then required by the jar-dependencies gem (which just keeps track of version conflicts)

the Rakefile setup task does that installing and it need ruby-maven which comes with jbundler already. ruby-maven is not a runtime dependency since is has nothing to do during runtime. it is only needed on install time ;)

the jar-dependencies is not on rubygems.org yet and I want to wait for some more feedbaclk on all this.

@mmmries
Copy link
Owner Author

mmmries commented Jan 28, 2014

@mkristian thanks for all your hard work checking into this issue. You have been trying to improve this situation for a long time.

I'm curious what your thoughts are about taking an approach similar to https://rails-assets.org/ where they basically let you pull in a bower dependency and just wrap it in a gem. Could we make a similar sort of service that wraps maven artifacts in a gem and when you Bundler.require'd them the jar would be added to the classpath?

@mmmries
Copy link
Owner Author

mmmries commented Jan 28, 2014

I should clarify, my goal here is to keep as many of the tools as possible so that the transitions from ruby -> JRuby -> Java has the least number of hurdles possible.

@mkristian
Copy link

jruby/jruby#1451

and the PR mentions maven-gems which was the attempt to wrap jars into a
gem and let rubygems resolve them. BUT the rubygems only works with version
ranges and maven in general does use fixed version (and in case of a
version conflict it takes the one which is closer to the root in the
dependency tree). and that version resolution made more and more jar
artifacts to fail and in the end it was like those wrapped jars had only
looked for the major version. and even that was not sufficient since maven
version be everything and rubygems has quite some constraints on that as
well. and JRuby patch rubygems and any rubygems update wipped out the
maven-gem support.

the above PR uses post_install hook on rubygems and it is clean solution in
my opinion. but I need to enforce some feedback soon (that is not really my
thing ;)

any ways I am grateful to all the input I got the last two weeks regarding
that issue !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants