Kristian, Hiro mentions a couple of more items needed to complete issue 912 and some things which we need to release 1.7.5. Any chance you can take a look and weigh in (or better yet make it work)?
-Tom On Thu, Jul 25, 2013 at 6:35 AM, kristian <m.krist...@web.de> wrote: > 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 > > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com
