We are encountering issues with DBB and the dbb-zappbuild scripts that we believe are the result of the UserID naming strategy for the customer environment that we are operating with.
On the system we are currently trying to test in all UserIDs follow a naming convention which includes a # character at the start of the UserID.
This means that the "sandbox" value that the users pass through for the IDz DBB User Builds they are launching, which are using their home directories to hold the sandbox, contain the # character. (The path looks something like /u/#12345/sandbox/)
Because the # character is a special character on the command line all user builds fail when we try to run User Builds.
We have tried many ways to get around this and not seen any success. These options have included passing the sandbox value surround by single quotes or double quotes (neither worked), escaping the # character with a slash (\), among others.
Given that the rest of the tools all support a UserID with a # at the beginning, we are wondering what the solution for IDz User Builds interacting with the dbb-zappbuild scripts and DBB is that would allow us to have these UserIDs.
Stack Trace:
/u/#i00937@ACU2>$DBB_HOME/bin/groovyz /u/#i00937/sandbox/dbb-zappbuild/build.groovy --sourceDir /u/#i00937/sandbox --workDir /u/#i00937/sandbox/work --hlq #I00937.MORTGAGE -a MortgageApplication -v -d --userBuild 'MortgageApplication/cobol/epscmort.cbl'
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during instruction selection: java.lang.NoClassDefFoundError:
java.lang.RuntimeException: java.lang.NoClassDefFoundError:
at org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:972)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:692)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:666)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:373)
at groovy.lang.GroovyClassLoader.lambda$parseClass$2(GroovyClassLoader.java:316)
at org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163)
at org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:572)
at groovy.lang.GroovyShell.run(GroovyShell.java:392)
at groovy.lang.GroovyShell.run(GroovyShell.java:382)
at groovy.ui.GroovyMain.processOnce(GroovyMain.java:649)
at groovy.ui.GroovyMain.run(GroovyMain.java:389)
at groovy.ui.GroovyMain.access$1400(GroovyMain.java:67)
at groovy.ui.GroovyMain$GroovyCommand.process(GroovyMain.java:313)
at groovy.ui.GroovyMain.processArgs(GroovyMain.java:141)
at groovy.ui.GroovyMain.main(GroovyMain.java:114)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:572)
at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:115)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:37)
Caused by: java.lang.NoClassDefFoundError:
at java.base/java.lang.ClassLoader.defineClassImpl(Native Method)
at java.base/java.lang.ClassLoader.defineClassInternal(ClassLoader.java:467)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:428)
at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
at groovy.lang.GroovyClassLoader.access$400(GroovyClassLoader.java:89)
at groovy.lang.GroovyClassLoader$ClassCollector.createClass(GroovyClassLoader.java:690)
at groovy.lang.GroovyClassLoader$ClassCollector.onClassNode(GroovyClassLoader.java:707)
at groovy.lang.GroovyClassLoader$ClassCollector.call(GroovyClassLoader.java:712)
at org.codehaus.groovy.control.CompilationUnit$3.call(CompilationUnit.java:806)
at org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:938)
... 22 more
1 error
** Build finished
/u/#i00937@ACU2>/u/#i00937@ACU2>
We are encountering issues with DBB and the dbb-zappbuild scripts that we believe are the result of the UserID naming strategy for the customer environment that we are operating with.
On the system we are currently trying to test in all UserIDs follow a naming convention which includes a
#character at the start of the UserID.This means that the "sandbox" value that the users pass through for the IDz DBB User Builds they are launching, which are using their home directories to hold the sandbox, contain the
#character. (The path looks something like/u/#12345/sandbox/)Because the
#character is a special character on the command line all user builds fail when we try to run User Builds.We have tried many ways to get around this and not seen any success. These options have included passing the sandbox value surround by single quotes or double quotes (neither worked), escaping the
#character with a slash (\), among others.Given that the rest of the tools all support a UserID with a
#at the beginning, we are wondering what the solution for IDz User Builds interacting with the dbb-zappbuild scripts and DBB is that would allow us to have these UserIDs.Stack Trace:
/u/#i00937@ACU2>$DBB_HOME/bin/groovyz /u/#i00937/sandbox/dbb-zappbuild/build.groovy --sourceDir /u/#i00937/sandbox --workDir /u/#i00937/sandbox/work --hlq #I00937.MORTGAGE -a MortgageApplication -v -d --userBuild 'MortgageApplication/cobol/epscmort.cbl'
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during instruction selection: java.lang.NoClassDefFoundError:
java.lang.RuntimeException: java.lang.NoClassDefFoundError:
Caused by: java.lang.NoClassDefFoundError:
1 error
** Build finished
/u/#i00937@ACU2>/u/#i00937@ACU2>