to add those files to jruby-stdlib jar is easy and with it goes to lla the
other distribution forms.

BUT is it really the way to go: pack those "all" included ?

as far as I understand truffle is optional, so if I do not want to use
truffle I want "truffle" free artifacts. using ruby scripting in a java
even if it is only "puts 'hello world'" means I need to add 20MB or more
extra libraries to get it working.

rather I would like specifiy a classifier "truffle" to get the truffle and
NOT get the stuff truffle replaces (as far I understand this that would be
IR). unfortunately maven does pick only another jar with the classifier and
not another pom.xml (which different dependencies). but it could be done in
a similar manner as 'jruby-noasm' which collects the jruby-core with the
right classifier.

I am not talking about jruby-dist which is anyways "all inclusive" ;)

so jruby should become more modular in the way it gets distributed.

On Fri, Jan 16, 2015 at 2:44 AM, Kevin Menard notifications@github.com
wrote:

Since Truffle has a long ways to go before being widely useful, we've
whitelisted the standard libraries we think are okay to load. These are
implemented by way of stubs in lib/ruby/truffle/mri and they basically do a
require_relative back to the standard lib file in JRuby. The problem is
these stubs aren't currently being packaged so anyone using the tarballs as
the source for their installation can't use even the whitelisted libs.

@mkristian https://github.com/mkristian -- Any help you can provide
with packaging would be much appreciated.

—
Reply to this email directly or view it on GitHub
#2466.

dist is the problem. ruby-build uses the nightly tarballs (and the versioned ones upon release) for installation. They currently don't include everything needed to run Truffle-backed JRuby.

We're working on some ideas to reduce the size of the Truffle code (it's generated code, so we're improving the generator), so it may not be quite as bad as 20MB. I'll let you know as we experiment.

As you say, jruby-dist (the binary tarballs, right?) and JRuby complete I think should include all backends, and I think that's always the way it's been understood to work. Truffle's a runtime configuration option, not an entirely separate product.

We're happy to work with you on some finer grained packaging as well. Personally, I don't see the issue as it's only a few MB and we don't have separate packages for indy and non-indy, but if you know of use cases I'll trust your judgement on that. Let us know if you need us to help. It's already possible to remove Truffle by brute force deleting the classfiles from the jar and users will get a nice error message.

Do we need to do anything to help you get our stdlib into the tarballs and complete?

just give me time until tomorrow and then there will be the truffle stuff
included. just do not want to push things and then go to bed without being
to fix the build in case I break it.

maybe my wish to modularize it is not so important, but it is already half
way: remove Truffle by brute force deleting the classfiles from the jar =>
just put it into two jars.

On Fri, Jan 16, 2015 at 10:59 PM, Chris Seaton notifications@github.com
wrote:

We're working on some ideas to reduce the size of the Truffle code (it's
generated code, so we're improving the generator), so it may not be quite
as bad as 20MB. I'll let you know as we experiment.

As you say, jruby-dist (the binary tarballs, right?) and JRuby complete I
think should include all backends, and I think that's always the way it's
been understood to work. Truffle's a runtime configuration option, not an
entirely separate product.

We're happy to work with you on some finer grained packaging as well.
Personally, I don't see the issue as it's only a few MB and we don't have
separate packages for indy and non-indy, but if you know of use cases I'll
trust your judgement on that. Let us know if you need us to help. It's
already possible to remove Truffle by brute force deleting the classfiles
from the jar and users will get a nice error message.

Do we need to do anything to help you get our stdlib into the tarballs and
complete?

—
Reply to this email directly or view it on GitHub
#2466 (comment).

The other thing to consider if that Ruboto needs to be able to not include Truffle due to size being much more important. They are doing this outside our build processes but it is still worth mentioning.

This is the command to remove Truffle safely:

https://github.com/jruby/jruby/blob/master/tool/remove-bundled-truffle.sh