Discussion:
[jruby-dev] pending maven bits
(too old to reply)
kristian
2013-07-25 11:35:20 UTC
Permalink
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
Thomas E Enebo
2013-08-30 20:32:33 UTC
Permalink
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
Post by kristian
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
* 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 ##
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 ###
./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.enebo-***@public.gmane.org
Christian Meier
2013-08-31 18:18:48 UTC
Permalink
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
Post by Thomas E Enebo
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
Post by kristian
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
Post by kristian
of it there are improvements in building the core jar, i.e. repeated
run
Post by kristian
dropped from 16s to 10s on my machine (I guess 9s is still possible
;).
Post by kristian
## vendored jars and some possible improvement ##
with the jruby stdlib maven artifact I did NOT include the
bouncy-castle
Post by kristian
and jline jars as "vendored" jars. I guess that is my personal thingy
that
Post by kristian
vendored jars and gems are better avoided to prevent version clashes
with
Post by kristian
jars/gems used somehow along with that artifact. instead it declares
them
Post by kristian
as regular dependency. i.e. for bouncy-castle that approach allows to
use a
Post by kristian
different version of BC for jruby maven artifact. actually even
though the
Post by kristian
latest BC does not compile openssl the compile error ONLY affects a
single
Post by kristian
method for a password protected container (I would have fixed the
code but
Post by kristian
there are no tests and to figure a way of trying out the new code is
a
Post by kristian
bigger task for me).
vendored jars whether with jruby or within gems always bothered me -
I
Post by kristian
have no control over them and there is no easy to find out which
version I
Post by kristian
am using and there is no way to isolate the hidden jars from gems
from the
Post by kristian
java application which uses the ScriptingContainer.
short list of problematic gems is (I might be wrong here and there
since I
Post by kristian
* 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
Post by kristian
jars is to isolate the jrubyclassloader from its parent classloader.
this
Post by kristian
is done for servlet-classloader via a configuration setting "load the
classes from war first before going to the parent classloader". this
is
Post by kristian
also done with other projects where you want to separate plugins and
their
Post by kristian
dependencies from the containing application and their dependencies.
and
Post by kristian
this I have done with the commit
9b9ee54022c54a5e49d6ef3dae73e5dad30a6039
Post by kristian
that should be perfectly save since if an application had no jar
versions
Post by kristian
conflict problems nothing really changes beside the search order of
those
Post by kristian
classes. but now you can use any gem with your ScriptingContainer and
you
Post by kristian
are still be free to choose any jar for your java application or you
can
Post by kristian
use any bouncy-castle-java gem with ScriptingContainer without
affecting
Post by kristian
the java application.
the commit 86d23de4687e8ca6e7eba9ac5f9f5ca2257eda24 adds some
integration
Post by kristian
tests for the jruby artifact as well the jruby-complete artifact
showing
Post by kristian
how to use different version BC for java and ruby in ONE application.
one
Post by kristian
could a system property for that behavior to be switched on/off but
it
Post by kristian
should be just fine without the switch - maybe java scripting has
some say
Post by kristian
in that as well ?
for me that lifts both gems and jars on a more equal level: the BC
gem
Post by kristian
gets updated the same way as you would update a newer minitest gem
with MRI
Post by kristian
and the BC jar from jruby can be "overwritten" by just adding the
desired
Post by kristian
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
Post by kristian
BC jar in the classpath will not affect openssl. with the jruby
artifact
Post by kristian
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
Post by kristian
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 ##
jruby, jruby-core and jruby-stdlib
in order to use jruby for a maven/ivy/buildr/... project you need to
use
Post by kristian
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
Post by kristian
jruby-core and jruby-stdlib in your project. the reason for that
change is
Post by kristian
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
Post by kristian
can just use tesla maven to execute it directly. currently I am
working on
Post by kristian
getting this on rubygems.org as ruby-maven gem. all the pom.rb from
the
Post by kristian
pom-proposal branch are generated by tesla and can be executed
directly. it
Post by kristian
is possible that a tesla maven run dumps the generated pom.xml (it is
also
Post by kristian
possible as readonly dumps). any feedback on the DSL itself are
welcome as
Post by kristian
well !
### bouncy-castle-java gem ###
the bouncy-castle-java gem looks rather straight forward with
./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
Post by kristian
with the gem as well but I just kept the gem as close as it was
before.
Post by kristian
### 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
Post by kristian
called inherit in Mavenfile) uses the gemspec version. you all might
have
Post by kristian
seen that 1.7.5.dev is hardcoded in all pom.xml !!! the dependencies
I put
Post by kristian
into the Mavenfile instead of the gemspec file. these dependencies
are just
Post by kristian
shaded jruby-core and jruby-stdlib artifacts and they need to have
them
Post by kristian
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
Post by kristian
is easy to package a gem with a "jar extension" and the ./ext/opensll
part
Post by kristian
is not meant to deploy on maven central itself.ext/openssl/pom.rb
would
Post by kristian
probably just get a "gemspec :jar=>'jopenssl'" declaration and some
more
Post by kristian
little mods'
## profile to build all or parts ##
built all - without the 'package' goal it makes all the reporting as
well
Post by kristian
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
Post by kristian
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 ;)
Post by kristian
and for me once something works I can easily get carried away with
the
Post by kristian
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
Post by kristian
project. I will have a look in how warbler can make use main jruby
maven
Post by kristian
artifact as well use jbundler for getting all the jar inside the
war-file
Post by kristian
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
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Thomas E Enebo
2013-09-01 21:38:00 UTC
Permalink
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
Post by Christian Meier
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
Post by Thomas E Enebo
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
Post by kristian
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
* 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 ##
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.enebo-***@public.gmane.org
Loading...