To describe the plugin for those who do not know it yet, it allows Hudson or Jenkins users to add labels dynamically to every node with a specific tool installation. For example, if you need to build or test your software with JDK 1.6 but you do not want to install such an old version automatically installed on many nodes, you can add
jdk1.6 as a label to the JDK 1.6 installation. Then, if you set the tool path of JDK 1.6 on the nodes on which it is installed, those nodes will have
jdk1.6 dynamically as a label and you can restrict nodes to run your job by that label.
Of course, this plugin is not limited just to JDK. You can use it for Maven, Ant, MSBuild, or any other tool if you can set tool paths for it per node.
The plugin should soon be available in the Update Center of your Jenkins server instance. If you are interested in the project itself or in its source code, please watch its source code repository on Bitbucket.
The lifecycle method [init] must not throw a checked exception. Related annotation information: annotation [@javax.annotation.PostConstruct()]…
So what was a checked exception, I thought and got an answer in a few minutes.
To explain a checked exception in short, it is an exception (
java.lang.Throwable and its descendants) that is not an unchecked exception (
java.lang.RuntimeException and its descendants). The
@javax.annotation.PostConstruct annotation simply requires the annotated method does not throw a checked exception, but Quercus violates the requirements.
It became clear that I could not use Quercus on GlassFish Server 4 without modifications, so I decided to build Quercus myself from the source code.
I made a Maven project for Quercus, but the first apparent issue was its dependencies are not clear. I tried to add possible dependency to resolve errors, but a few remained. One of the causes was Quercus happened to use a draft version of the Java Caching API that is not compatible to the final release. I decided to go with the final release and made trivial changes to the Quercus source code. Another one is a bug in the Java EE API available from the Maven repository. I finally added explicit dependency on the CDI APIs to work around it.
(To be continued to Episode 2)