On Mon, Feb 1, 2010 at 12:08 PM, Vladimir S. [email protected]
Running install-gems automatically (and without any checks) would slow
down the build significantly. We could do some tricks to detect when
to install gems and when to skip the step, but this just adds and adds
to our build file, which is pretty big already.
I’d see this happening along the same timeframe as moving everything
to Rake, which would drastically reduce the complexity of our build
files. But I also agree, we’d need a smarter check to see if the gems
are already installed. It could be as simple as checking for them on
the filesystem under lib/ruby/gems/1.8/gems/rake, etc, which would
introduce almost no cost into the build.
In this particular case, for those who clone the git repo and build
themselves, such folks probably won 't have much problem to invoke ant
install-gems or jruby -S gem install rake, or write to the alias
Yeah, it’s easy, but it’s still an extra step you have to perform.
Ideally we should have one command people can run against a checkout
to get a fully working JRuby home, and right now it’s not obvious that
you need to install-gems.
The other option (maybe the better option)
would be that instead of installing as gems we bundle directly.
I actually like the fact that all those “built-in” gems that we
provide, are just pre-installed gems, so that they could be easily and
safely upgraded/removed, queried, etc.
I’m not sure what “bundle directly” would mean, but if such libs would
be different from other, “external” gems, that would not be good (just
Yeah, that’s a good point. I was mostly pointing at the bundling of
RubyGems and Rake directly into Ruby 1.9…but that already has
introduced upgrading issues for them. So maybe it’s not a good idea.
If we could just get RubyGems and Maven and embedded deployment and
classloaders and classpath and jruby-complete to all work perfectly
together, it would be a non-issue
To unsubscribe from this list, please visit: