Akom's Tech Ruminations

I'm testing a product that needs to be compiled with JDK 8 but tested (sometimes) on JDK 11. This is now possible to do with maven surefire (although that took some effort). With gradle, I was doing it as follows, which is terrible, even if the path comes from configuration:

// The old way:
test {
    executable = '/some/hardcoded/path/to/java'
}
 

Now that Gradle 6.7+ has built-in toolchains support, it's trivial to configure the compile toolchain:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}
 

But what about tests? What if I want to test with a different JVM? It's a little more verbose:

test {
    JavaToolchainService javaToolchainService = project.getExtensions().getByType(JavaToolchainService.class)
    def launcher = javaToolchainService.launcherFor{
        languageVersion = JavaLanguageVersion.of(11)
    }
    javaLauncher = launcher
    environment 'JAVA_HOME', launcher.get().metadata.installationPath //if your tests care about JAVA_HOME
}
 

This turned out to be fairly simple, with only one gotcha: do not follow the how-to's out there that tell you to use expect fork. The process doesn't technically fork. When I had that setting enabled, upstart commands would hang under very specific but repeatable conditions (if the process was killed externally).

So, here is my upstart conf file:

Continue reading "Running Jenkins Swarm client as a service via Upstart"

I have about 200 jobs that have the HudsonStartupTrigger (this is a plugin) turned on. This makes all of them run every time the master is restarted, causing the build queue to go crazy. I don't know why people turned this on in so many jobs (probably blindly copying jobs) over the years, but I'd like it gone. I don't want to restart the master or uninstall the plugin.

Here is a script console snippet to do this (can be adapted to remove other triggers easily). This does not do folders, if you're using that plugin.

This week I found myself in one of those situations...

I had initially implemented corporate web services in Axis2 1.2, using ADB data binding, starting with a WSDL. Only problem is - the WSDL I had to reimplement came from .NET, sometime around 2001... when overloading must have seemed like a good idea. Since then it's been abolished by just about everyone, including of course the current WSDL specifications. Moreover, the WSDL was most likely auto-generated by .NET with no regard for how manageable it would be. Yes, this is an experience infused with "ArrayOfAnyType", <anytype xsd:type="string">, and other such pearls.

I can't say that ADB handled overloaded methods

Continue reading "Convincing JAX-WS on Axis2 1.4 to handle overloaded web service methods"