Analysis: the class names only matter insofar as they may affect the order in which files are parsed, and the number of methods defined in each class. Basically the issue is manifested under certain conditions when
- there is a Groovy class defined in a library which defines some methods
- this class is extended in the main Pipeline script which defines some additional methods
For every method, Pipeline generates an internal ___cps___NNN method for the CPS transformation. The counter is incremented for each new method, but was effectively being reset at the transition between library and main script. Depending on the exact source structure, it can happen that a main script class was transformed to include a generated method with the same counter as its library superclass, producing an error by the Groovy compiler—though one of dubious correctness, since these are all private static final and so could not have been interpreted as an override (Java correctly permits this). |