Open tibidi opened 5 years ago
+1
Since each Groovy script creates its own classloader and JNI can only be loaded once in a JVM, Groovy scripts using JNI must be run in a forked JVM. A workaround could be a meta runner using <groovy>
Ant task shipped with Groovy, which supports forking (and provides other useful functionality).
@dlukyanov Would you consider adding support for forking of JVM?
do you mean to run groovy in a separate process? It will be impossible to pass all internal teamcity objects...
It'll be possible to pass only build properties. maybe possible to load your JNI in a system class loader?
It would suffice to pass the build properties. In fact, I was considering using Ant bindings to run Groovy task and fork 😄 If you follow the discussion on YouTrack, loading JNI in a system (effectively the TeamCity agent) class loader was frowned upon by JetBrains, but I'd love to give it a try.
See here : https://youtrack.jetbrains.com/issue/TW-60776