hi, the missing bits are roughly (as far I am right ;)
* maven artifacts jruby-core, jruby-stdlib, jruby-complete * dist files tar.gz and zip * jruby-jars gem * osgi * various gems: bouncy-castle-java, openssl I just pushed a branch 'pom-proposal' to github where the above is partially done but misses the dist files and openssl gem and osgi. on top of it there are improvements in building the core jar, i.e. repeated run dropped from 16s to 10s on my machine (I guess 9s is still possible ;). ## vendored jars and some possible improvement ## with the jruby stdlib maven artifact I did NOT include the bouncy-castle and jline jars as "vendored" jars. I guess that is my personal thingy that vendored jars and gems are better avoided to prevent version clashes with jars/gems used somehow along with that artifact. instead it declares them as regular dependency. i.e. for bouncy-castle that approach allows to use a different version of BC for jruby maven artifact. actually even though the latest BC does not compile openssl the compile error ONLY affects a single method for a password protected container (I would have fixed the code but there are no tests and to figure a way of trying out the new code is a bigger task for me). vendored jars whether with jruby or within gems always bothered me - I have no control over them and there is no easy to find out which version I am using and there is no way to isolate the hidden jars from gems from the java application which uses the ScriptingContainer. short list of problematic gems is (I might be wrong here and there since I did not verify them right now - just out of my head): * jrjackson - has some jackson jar * nokogiri - xercers and other xml related jars * neo4j - have not check what they all have * jruby-openssl - bouncy castle one way to help a java application to choose their "own" version of those jars is to isolate the jrubyclassloader from its parent classloader. this is done for servlet-classloader via a configuration setting "load the classes from war first before going to the parent classloader". this is also done with other projects where you want to separate plugins and their dependencies from the containing application and their dependencies. and this I have done with the commit 9b9ee54022c54a5e49d6ef3dae73e5dad30a6039 that should be perfectly save since if an application had no jar versions conflict problems nothing really changes beside the search order of those classes. but now you can use any gem with your ScriptingContainer and you are still be free to choose any jar for your java application or you can use any bouncy-castle-java gem with ScriptingContainer without affecting the java application. the commit 86d23de4687e8ca6e7eba9ac5f9f5ca2257eda24 adds some integration tests for the jruby artifact as well the jruby-complete artifact showing how to use different version BC for java and ruby in ONE application. one could a system property for that behavior to be switched on/off but it should be just fine without the switch - maybe java scripting has some say in that as well ? for me that lifts both gems and jars on a more equal level: the BC gem gets updated the same way as you would update a newer minitest gem with MRI and the BC jar from jruby can be "overwritten" by just adding the desired version to the classloader/classpath along with jruby. there is a slight difference between the jruby artifact and jruby-complete: jruby-complete has the BC jars vendored, i.e. a different BC jar in the classpath will not affect openssl. with the jruby artifact the BC jar is not vendored, i.e. it will take the BC version from the classloader and that can be a different one than the declared dependency of the jruby artifact. please note that * not vendoring BC and jline with jruby artifact * reverse class loading on the JRubyClassLoader are TWO independent topics. ## jruby-core maven artifact for maven projects ## next change I need to point out is: there are three maven artifacts: jruby, jruby-core and jruby-stdlib in order to use jruby for a maven/ivy/buildr/... project you need to use org.jruby:jruby:1.7.5.dev, with jruby-1.7.4 you needed to use org.jruby:jruby-core:1.7.4 and in older version you needed to add both jruby-core and jruby-stdlib in your project. the reason for that change is just that jruby-core (./core/pom.xml) does not have a dependency to jruby-stdlib and can not have it at that point of the build. ## gems with maven ## for packaging gems I used the gem-maven-plugin, actually I used the https://github.com/tesla/tesla-polyglot to generate the pom.xml but you can just use tesla maven to execute it directly. currently I am working on getting this on rubygems.org as ruby-maven gem. all the pom.rb from the pom-proposal branch are generated by tesla and can be executed directly. it is possible that a tesla maven run dumps the generated pom.xml (it is also possible as readonly dumps). any feedback on the DSL itself are welcome as well ! ### bouncy-castle-java gem ### the bouncy-castle-java gem looks rather straight forward with ruby-maven: ./gems/bouncy-castle-java/Mavenfile where the jar is declared as deps inside ./gems/bouncy-castle-java/bouncy-castle-java.gemspec the version comes from an external version file which could be included with the gem as well but I just kept the gem as close as it was before. ### jruby-jars gem ### that one has almost the same setup as the bouncy-castle-java gem. the version is coded inside the gemspec and the pom parent declaration (is called inherit in Mavenfile) uses the gemspec version. you all might have seen that 1.7.5.dev is hardcoded in all pom.xml !!! the dependencies I put into the Mavenfile instead of the gemspec file. these dependencies are just shaded jruby-core and jruby-stdlib artifacts and they need to have them built first. due to that built order it feels that ./gems/jruby-jars ./gems/jruby-core-complete ./gems/jruby-stdlib-complete should move to ./maven/jruby-jars ./maven/jruby-core-complete ./maven/jruby-stdlib-complete ## openssl gem ## that one I did not make yet since it should move into ext/openssl since it is easy to package a gem with a "jar extension" and the ./ext/opensll part is not meant to deploy on maven central itself.ext/openssl/pom.rb would probably just get a "gemspec :jar=>'jopenssl'" declaration and some more little mods' ## profile to build all or parts ## built all - without the 'package' goal it makes all the reporting as well which takes a long long time $ mvn -Pall package jruby-complete artifact $ mvn -P complete jruby artifact $ mvn -P main jruby-rake-plugin artifact $ mvn -P rake-plugin jruby dist files $ mvn -P dist jruby docs $ mvn -P docs jruby gems $ mvn -P gems the reporting needs to go away from all in its own profile. the gems profile should become jruby-jars and the bouncy-castle-java gem will get some rake tasks (using ruby-maven gem) to build the gem. ## epilog ## it is a bigger task for me to write up such an email then writing code ;) and for me once something works I can easily get carried away with the next thing and forgetting to push and/or publish things so the issue https://github.com/jruby/jruby/issues/912 was the hint that I have forgotten something !!! the idea or vision to treat jars and gems more equal reflects in jbundler project. I will have a look in how warbler can make use main jruby maven artifact as well use jbundler for getting all the jar inside the war-file by taking the dependency of jruby into account. hope I stayed in line with the jruby project !!! regards, christian
