Load inline script code from a file in Bamboo specs

Bamboo Development
1

Hi,

I am currently working on migrating a bunch of our Bamboo plans into bamboo specs (java).
Among the refactoring of the bspecs code, we decided to have all inline script code in files and have java load them into the plan spec code.

Given the maven project structure I stored all the script files under “bamboo-specs/src/main/resources/inline-scripts/”

Within the code I created a method to load the files and return a string.

public static String inlineScriptFromFile(String filePath) {
        try {
            ClassLoader loader = PlanSpecUtilities.class.getClassLoader();
            InputStream s = loader.getResourceAsStream(filePath);
            byte[] b = s.readAllBytes();
            return new String(b);
        } catch (Exception e) {
            System.out.println(e.getMessage());
            return "";
        }
    }

Everything worked fine when tested offline, however, as soon as I pushed the code, bamboo server failed to compile it with the error below:

20-Aug-2021 16:42:51	[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project bamboo-specs-generator: Compilation failure
20-Aug-2021 16:42:51	[ERROR] /mnt/input/src/main/java/com/x/product/common/PlanSpecUtilities.java:[11,25] cannot find symbol
20-Aug-2021 16:42:51	[ERROR]   symbol:   method readAllBytes()
20-Aug-2021 16:42:51	[ERROR]   location: variable s of type java.io.InputStream
20-Aug-2021 16:42:51	[ERROR] -> [Help 1]
20-Aug-2021 16:42:51	org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project bamboo-specs-generator: Compilation failure
20-Aug-2021 16:42:51	/mnt/input/src/main/java/com/x/product/common/PlanSpecUtilities.java:[11,25] cannot find symbol
20-Aug-2021 16:42:51	  symbol:   method readAllBytes()
20-Aug-2021 16:42:51	  location: variable s of type java.io.InputStream
20-Aug-2021 16:42:51	
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions (MojoExecutor.java:353)
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:198)
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51)
20-Aug-2021 16:42:51	    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
20-Aug-2021 16:42:51	    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
20-Aug-2021 16:42:51	    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
20-Aug-2021 16:42:51	    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
20-Aug-2021 16:42:51	    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
20-Aug-2021 16:42:51	    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
20-Aug-2021 16:42:51	    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
20-Aug-2021 16:42:51	    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
20-Aug-2021 16:42:51	    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
20-Aug-2021 16:42:51	    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
20-Aug-2021 16:42:51	    at java.lang.reflect.Method.invoke (Method.java:498)
20-Aug-2021 16:42:51	    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
20-Aug-2021 16:42:51	    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
20-Aug-2021 16:42:51	    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
20-Aug-2021 16:42:51	    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
20-Aug-2021 16:42:51	Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure
20-Aug-2021 16:42:51	/mnt/input/src/main/java/com/x/product/common/PlanSpecUtilities.java:[11,25] cannot find symbol
20-Aug-2021 16:42:51	  symbol:   method readAllBytes()
20-Aug-2021 16:42:51	  location: variable s of type java.io.InputStream

Does any one know what I am doing wrong here?

Thanks.
2 Likes
2

InputStream#readAllBytes() is only available since Java 9, so I assume a respective JDK version mismatch from your local/offline environment to your Bamboo server setup/build configuration.

2 Likes
3

Thanks hopel.
Do you know whether the java version used for Bamboo specs is the same as the one used to install Bamboo server or is it something that could be configured separately? I can’t seem to find anything regarding this on the web.

4

In principle, a Bamboo spec build is just a normal Java&Maven build, so you should be able to use a different JDK to get past the exception you posted the same way you’d do for other Java builds on Bamboo. See e.g. Maven and Defining a new JDK capability for details on that.

However, I’m not 100% sure if a JDK mismatch might eventually cause other issues later on in the build spec processing logic. I’d try to use a JDK matching your Java source version for the build first (while setting a compile target version matching the one used on the Bamboo server), but if I ran into follow up issues right away, I’d consider refactoring the offending resource loading logic to use ‘older’ Java methods as a possibly simpler approach.

3 Likes
5

Thank you, I appreciate the support.
I will opt for the safe approach of using older methods.