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 >> >> > > >-- >blog: http://blog.enebo.com twitter: tom_enebo >mail: tom.en...@gmail.com -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
