Ok we can touch base later on remaining bits when you are around (It is a holiday in US on Monday too).
I am nervous to apply a Classloader change without substantial bake time to figure out what potential unintended consequences there might be. So I would be inclined to not address that for 1.7.5 but possible try it early for 1.7.6 and definitely on master for 9k. You explanation for wanting the change seems reasonable to me but I fear a change close to a release. -Tom On Sat, Aug 31, 2013 at 1:18 PM, Christian Meier <meier.krist...@gmail.com>wrote: > Kind of offline until Monday. The missing source dist and the opensll gem > is either already there or just a small config change. BUT the biggest > thing is to get all the remaining snapshot dependency released first - can > not look at the current state. > > And my class loader patch would be great to get some comments on it - > maybe I was too unclear about it. > > Anyways one the snapshots are gone I can see into how to use the maven > release plugin to do the actual release. But it has to wait until Monday. > > Regards Christian > > > > > Thomas E Enebo <tom.en...@gmail.com> schrieb: > >> 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 >>> >>> >> >> > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com
