My dist (from Friday afternoon):

  -rw-rw-rw-       810  16-Jan-2015  15:25:12  META-INF/jruby.home/lib/ruby/stdlib/json/add/ostruct.rb

fwiw, I am hoping jruby-complete is smaller since was only ship a single version of stdlib and a single parser instead of three. I will not close this until tomorrow when I verify that latest build changes did not break something (some were made on Saturday).

I have created a test case here https://gist.github.com/monkstone/b5714dbf84431273ec87 which mimics ruby-processing. With jruby-complete-1.7.18.jar ie the following test

ruby runner.rb

yields the expected result

{"JRUBY"=>"false", "PROCESSING_ROOT"=>"/home/tux/processing-3.0a5", "X_OFF"=>192, "Y_OFF"=>108}

With jruby-core-9.0.0.0.pre1-complete.jar ie the following test as expected, with runner-pre.rb I get this:-

LoadError: no such file to load -- psych/syntax_error
     require at org/jruby/RubyKernel.java:954
     require at org/jruby/RubyKernel.java:954
  __script__ at psych.rb:1

or similar for ostruct_test (not provided)

LoadError: no such file to load -- ostruct
     require at org/jruby/RubyKernel.java:954
  __script__ at ostruct_test.rb:1

perhaps the clue is in the name of the jar in which case my apologies, but I had been assuming that
mvn -Pcomplete would produce a usable jruby-complete.....

use a clean build in case you switch branches or so:
mvn clean install -Pcomplete

anyways it is THE jruby-complete jar, my build shows

$ ll maven/jruby-complete/target/jruby-complete-9.0.0.0.pre1.jar
-rw-rw-r-- 1 christian christian 28255791 Jan 19 10:38 maven/jruby-complete/target/jruby-complete-9.0.0.0.pre1.jar

the main reason it is bigger than jruby-1.7.18 is the new truffle backend.

Its a pity that build does not work for me even when preceded by successful mvn package
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project jruby-core: Compilation failure [ERROR] /home/tux/jruby/core/target/generated-sources/org/jruby/truffle/nodes/core/ModuleNodesFactory.java:[3551,29] error: error while writing ClassEvalRubyModuleUndefinedPlaceholderUndefinedPlaceholderUndefinedPlaceholderUndefinedPlaceholderNode: /home/tux/jruby/core/target/classes/org/jruby/truffle/nodes/core/ModuleNodesFactory$ClassEvalNodeFactory$ClassEvalRubyModuleUndefinedPlaceholderUndefinedPlaceholderUndefinedPlaceholderUndefinedPlaceholderNode.class (File name too long)

git branch
*master
lest there be any confusion................

@monkstone That is an unfortunate side-effect of build system. Any compile errors (which can even be generated classes) will trigger as if there is a compiler error in truffle code. The only way to solve this is to mvn clean first.

@enebo I routinely do mvn -Pclean and still got same result

wow. I did not read that error very closely...wtf is that massive file name :)

@monkstone Can I ask which OS you are trying to build this with?

@chrisseaton @nirvdrum @eregon I do not see this on MacOS but perhaps other OSes won't like such long generated filenames? I am not sure this is the base cause of this reported issue or not but I thought I would bring your attention to it.

I thought we had an issue open for this but apparently not. My guess would be that @monkstone is on Windows - or a unix with some kind of encrypted or FUSE file system?

The filename is a little bit ridiculous. I'll see if I can get it fixed so it doesn't try to generate this filename in the first place for Truffle 0.7 (in a few days).

@chrisseaton Your guess was right about encrypted home directory but it was on linux Mint, I'll have a go on Archlinux instead @enebo and report back (something I had not thought of).

Yeah an immediate workaround is to use a directory on an unencrypted filesystem if you have one.

@monkstone can you try building the truffle-u branch? It just renames some classes so they might be below the limit.

Well now I've booted up into Archlinux (where my user home is not encrypted), compiles OK, and
I get jruby-core-9.0.0.0.pre1-complete.jar size 20.5 MB (note same name as I got originally)
However when I run my test psych is now included and thus test works, so @enebo can probably close this issue (I will check ruby-processing works OK, if you don't mind before conducting @chrisseaton experiment with the original setup).

OK I think we can close this issue now ruby-processing shader sketches run fine, funny how the incomplete jruby-complete got built in the first place?

@monkstone If you can verify @chrisseaton truffle-u branch we would love to see if it works with the secure filesystem

@chrisseaton Your guess was right about encrypted home directory but it was on linux Mint, I'll have a go on Archlinux instead @enebo and report back (something I had not thought of).

@enebo @chrisseaton Well this is entirely unexpected to me compile of truffle-u branch seems to go OK producing a jruby-complete with same size file 20.5 MB but 'ostruct' and 'psych' are not found as before.

I wonder if there is some other longs paths causing packaging to not complete successfully but perhaps not crap out over the long paths?

@monkstone you are basically saying jruby-core and jruby-complete have both the same 20.5MB - sounds the jruby-complete does miss the stdlib files :( - for you

No! what I am saying is that jruby-complete truffle-u branch compiled on an encrypted file system and master branch jruby-complete compiled on an unencrypted file system are the same size 20.5 MB. Previously rather surprisingly I got 15.6MB on the encrypted system when it actually compiled see first entry....

I got confused by jruby-core-9.0.0.0.pre1-complete.jar which NOT jruby-complete and my jruby-complete-9.0.0.0.pre1.jar is about 28MB

just in case have a look maven/jruby-complete/target

something does not add up not sure what

I'm now a bit confused but happy to close the issue jruby-complete-9.0.0.0.pre1.jar works OK on both encrypted (compiles OK with truffle-u branch) and unencrypted systems (but jruby-core-9.0.0.0.pre1-complete.jar built on unencrypted system also seemed mostly work for me). @enebo @mkristian @chrisseaton

sorry - naming things can be quit a challange. the idea was that those "complete" files do not have an further dependencies: jruby-complete-9.0.0.0.pre1 == jruby-core-9.0.0.0.pre1-complete + jruby-stdlib-9.0.0.0.pre1