Package and distribute JVM's like you do gradle_all

Help/Discuss
1

My environment uses 3 primary jvm’s. IBM 7, Oracle 7 and Oracle 8, with IBM 7 being the massive majority. Our development machines have Oracle JRE 8, our MyEclipseBlue instances come with Oracle JDK 8, and we have to compile everything in IBM 7 so it runs on our WAS servers properly.

That is a lot of confusion on a LOT of machines. Especially since one random software update or the renaming of a folder can blow up tons of developer machines. I was wondering, how hard would it be to build a system similar to the gradle wrapper, where i can just take a folder with a JVM in it, zip it up, drop it on my Artifactory server, and then in my build file say

dependencies {
  remote-jvm "mycompany:ibmjvm:7.23.2"
}

and gradle just knows to use that for the project. The trick would also be making sure that buildship can recognize it as well and configure eclipse to use that jvm.

forget licensing issues for the moment, thats why I have a legal department.

This doesn’t seem to be horribly difficult to me. Can anyone think of a reason this wouldn’t work?

2

You can definitely do that. Write a small task that unpacks all zips from the jvm configuration and then set up your compile/javadoc/test tasks to use those executables instead. The JVM that Gradle runs on becomes much less important that way.

3

Also have a look at what @vermeulen_mp has been doing on the sdkman project. He has specifically been working on the installing JDKs of late.

4

i don’t want to install the jdk. One issue we have of late is some of our desktop software requires jre8, and if jre8 isn’t default, those apps won’t run, so we are always playing tricks with eclipse to switch things to ibm jdk 7 because our was servers won’t run our apps if compiled on the oracle jdk due to the changes that IBM made to the classloaders and how our server clusters are setup.

its a mess

i started tinkering with it last night, it doesn’t seem to hard, using the wrapper as a baseline to start with. If my CTO can work thru the legalities of me committing to OSS projects, ill polish it and send it up as a MR.

5

Early days yet on the grolifant library, but maybe this can help you on your way

6

You don’t have to install, did you have a look at the documentation I linked?

I don’t think changing the wrapper is the way to go. That breaks down as soon as you want to build two libraries for different Java versions in the same build.

7

I have been tinkering with this for the past few days. Finally got the beginnings of a DSL going, thats pretty cool. Now my problem. My plan is to distribute these jvm’s with my artifactory server. I have our artifactory beat box sorta kinda running (as long as noone throws that light switch in the middle type thing) and the jvm’s zipped up and in there. I have the jvm module defined with pretty much a maven GAVC structure.

The question is, is there a way that i can piggy back maven? Meaning if i have the GAVC “jdk.win:oracle_x86:1.8.66” is there a way i can just feed that into the maven subsystem and have it download the file from the configured repository?

if not, i may just redesign everything and put that into the base dependencies block and come up with another way to reference it in.

8

You can use a detached configuration when your plugin needs to do some internal dependency resolution. See the documentation of ConfigurationContainer (for creating the detached configuration) and DependencyHandler (for adding dependencies to that configuration).