My product can have two different releases (let's call them release#1 and release#2) running at the same time. Due to incompatible logic, I created two workflows and two sets of scripts and hope each workflow can use its own set of scripts. This mostly is done by configuring multiple script roots by plugin.script.roots JVM option.
I have two script roots, one is "scripts" and the other one is "scripts/release2." They contain same sub-directory hierarchy and files with same names. For example each root has two files com/company/jira/postfunction/a.groovy and com/company/jira/util/b.groovy. The release#1 workflow invokes com/company/jira/postfunction/a.groovy and the release#2 invokes ../release2/com/company/jira/postfunction/a.groovy. Each b.groovy contain a single method called "build" but different signature (i.e. different method arguments). Finally each a.groovy invokes the b.build() method but with different arguments( and a.groovy cotains a line "import com.company.jira.util.b").
The problem is that now a post function of one release doesn't work due to the method signature mismatch in b.groovy. I think the problem is that both a.groovy uses the same b class loaded by the class loader.
My question: what's the best practice for a workflow to only use the scripts, invoked directly or indirectly, from the same script root without changing my package names?
Is the "scripts folder" in scripts/release2 the same as the scripts in the other script root? If so this will not work if the files have the same names and package decleration. The classloader will not know which class to load.
Your best off just putting the scripts under one script root, for example under /scripts under the correct folders to match the package decleration.
I'd rename the files so you have something like:
As for the shared class you should use a structure like:
I recognise this is some manual work for you to do, but i think it's really the best way to achieve this.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs