I'm trying to create a ScriptRunner Script Plugin, and have more-or-less followed these guidelines (I'm using later Jira and ScriptRunner versions and hope that I've edited the pom file correctly).
I have some scripts in my plugin (they're definitely in the JAR) and I'm hoping that installing the plugin will add a Script Root and make these scripts visible. However, this doesn't seem to be happening, and I'm not seeing the scripts or the script roots in the Source Editor.
I'm wondering whether I need to do something to somehow declare the existence of these scripts, e.g., add something to scriptrunner.yaml, scripts.properties or atlassian-plugin.xml.
I'd be very grateful for any suggestions. I can give more details, but thought I'd keep it simple to start with.
--- UPDATE #1 (2021-11-15) ---
I've looked into this a bit further by going back to the guidelines referenced above and creating two different builds (links are to branches in my fork):
When I run #just-change-to-bbf, I see the various scripts, e.g., script.groovy:
But I'm almost sure that these are coming from the server directory, not from the plugin. If I uninstall the plugin they're still there:
If I run #remove-all-scripts, as expected I don't see the scripts:
But if I install the #just-change-to-bbf plugin (which should contain the scripts, yes?) I still don't see them:
The #just-change-to-bbf JAR file (unzipped into a temporary directory) looks like this:
hana:temp% unzip ../target/scriptrunner-plugin-just-change-to-bbf-1.0.0-SNAPSHOT.jar
Archive: ../target/scriptrunner-plugin-just-change-to-bbf-1.0.0-SNAPSHOT.jar
creating: META-INF/
inflating: META-INF/MANIFEST.MF
creating: css/
creating: images/
creating: js/
creating: org/
creating: org/broadband_forum/
creating: org/broadband_forum/scriptedfields/
creating: org/broadband_forum/main/
creating: org/broadband_forum/main/webfragments/
creating: org/broadband_forum/main/scriptedfields/
creating: org/broadband_forum/main/behaviours/
creating: org/broadband_forum/main/scripts/
creating: org/broadband_forum/main/listeners/
creating: org/broadband_forum/main/rest/
creating: META-INF/plugin-components/
creating: META-INF/spring/
inflating: css/scriptrunner-plugin-min.css
inflating: css/scriptrunner-plugin.css
inflating: images/pluginIcon.png
inflating: images/pluginLogo.png
inflating: js/scriptrunner-plugin.js
inflating: js/scriptrunner-plugin-min.js
inflating: scriptrunner-plugin.properties
inflating: org/broadband_forum/scriptedfields/CreateScriptFieldUpgradeTask.class
inflating: org/broadband_forum/scriptedfields/AbstractUpgradeTask.groovy
inflating: org/broadband_forum/scriptedfields/AbstractUpgradeTask.class
inflating: org/broadband_forum/scriptedfields/CreateScriptFieldUpgradeTask.groovy
inflating: org/broadband_forum/main/webfragments/webfragments.class
inflating: org/broadband_forum/main/webfragments/webfragments.groovy
inflating: org/broadband_forum/main/scriptedfields/scriptedfield.class
inflating: org/broadband_forum/main/scriptedfields/scriptedfield.groovy
inflating: org/broadband_forum/main/behaviours/behaviour.class
inflating: org/broadband_forum/main/behaviours/behaviour.groovy
inflating: org/broadband_forum/main/scripts/script.groovy
inflating: org/broadband_forum/main/scripts/script.class
inflating: org/broadband_forum/main/listeners/listener.class
inflating: org/broadband_forum/main/listeners/listener.groovy
inflating: org/broadband_forum/main/rest/rest.class
inflating: org/broadband_forum/main/rest/rest.groovy
inflating: org/broadband_forum/main/rest/rest$_run_closure1.class
inflating: scriptrunner.yaml
inflating: META-INF/plugin-components/component
inflating: META-INF/plugin-components/exports
inflating: META-INF/spring/plugin-context.xml
inflating: atlassian-plugin.xml
creating: META-INF/maven/
creating: META-INF/maven/org.broadband_forum.scriptrunner/
creating: META-INF/maven/org.broadband_forum.scriptrunner/scriptrunner-plugin-just-change-to-bbf/
inflating: META-INF/maven/org.broadband_forum.scriptrunner/scriptrunner-plugin-just-change-to-bbf/pom.xml
inflating: META-INF/maven/org.broadband_forum.scriptrunner/scriptrunner-plugin-just-change-to-bbf/pom.properties
Why aren't I seeing the scripts? I would think that the plugin:// script root URL would access the entire plugin tree, but is this wrong? Does it maybe "serve" a sub-hierarchy?
This is an old ScriptRunner version, and the version that I currently use doesn't give this list of script roots. Why is this (I rather like it)?
Hi William
I might be able to clear a few things up here:
1- Running the samples plugin with atlas-debug will add the plugins resource directory as a script root so yes you are correct they are coming from the server directory and not the plugin. They will not be there if you just installed the samples plugin jar into a separate Jira instance i.e. not run from your samples project with atlas-debug. You can compile just the jar for your plugin with the`atlas-package` command.
2- Auto completing the file paths for script file selectors does not work for the samples plugins at the moment, there is a bug for this here SRPLAT-935. I tested this again today and it also does not work in the latest version 6.39.0
You can still refer to the scripts inside the samples plugin resources directory but you have to manually enter the file path.
With regards to samples plugin file paths: The scripts need to be in the sample plugins resources folder before you compile it and the path starts from inside the resources folder (not including the resources folder). e.g. if I have a samples plugin directory structure and script like this `mysamplesplugin/jira/src/main/resources/com/mythings/myscripts.groovy`
the file path you need to use in ScriptRunners various features via the script file tab would be `com/mythings/myscripts.groovy`
3- We do not show the installed samples plugin roots in the script editor because those will be read-only directories and at the moment we do not show read-only script roots. The samples plugin roots are read-only because they are part of a plugin. i.e. contained inside its jar. You cannot edit these inside Jira, changes have to be made inside the sample plugins code (e.g: in an IDE), then you re-compile it and install it into Jira again.
Hope this helps
Regards
Matthew
Thank @Matthew Clark I was curious and tried to figure this out myself for the OP when it first appeared and wasn't able to.
Out of additional curiosity, I re-installed the test plugin I had created then and found that I was able to access a script in mysampleplugin/src/main/groovy/com/mythings/myscript.groovy by adding this to the console: com/mythings/myscript.groovy
But I was not able to access scripts from mysampleplugin/src/main/resources/com/mythings/myscript.groovy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Exactly, `mysampleplugin/src/main/resources` is not part of the compiled plugins jar.
If you run `atlas-package` and take the compiled jar from the samples plugins `jira/target/` directory and then unzip the jar file you will see it stores your script in a structure like `com/mythings/myscript.groovy`
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is all really helpful. Thanks
Maybe I have something weird in my project (it's a sample from a training)... but I have these two files:
After packaging,
I have these two paths
Notice the first is 4 directories deep (separated by /) while the second has only 1 directory with dots.
Either way ... it's good to know that scripts in plugin are available, you just have to figure out the correct path since autocomplete doesn't work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks _very_ much @Matthew Clark. Sorry for the delay, but I didn't notice that you'd replied.
1. So it seems like my main problem was that I assumed that failure to auto-complete implies absence, and that the expected scripts were probably there all the time? I'll try this (but don't have the time to do so right now). Could the existence of this bug be documented?
2. I guess I see the logic for not showing the read-only script roots in the Script Editor, but the problem is that (with the auto-completion bug) these files aren't visible at all! Could they be made visible (there could be a "read-only" indication, and of course any attempt to save changes would fail)? Alternatively, could the Console provide some indication of the script roots (as I believe it did before the Script Editor was introduced)?
3. I'm confused by your discussion with @Peter-Dave Sheehan of mysampleplugin/src/main/groovy and mysampleplugin/src/main/resources. I thought (from your first post) that the contents of the latter would go into the plugin JAR, but (in your reply to Peter-Dave) you seem to be saying the opposite.
4. What's the answer to the com/mycompany versus com.mycompany question? There's an example of this within the samples directory: scriptrunner-samples/jira/src/main/resources contains both a com directory (with an example subdirectory) and a com.adaptavist directory. If this is correct it's really confusing!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi William
I will try to answer the points as you numbered:
1- I guess you mean to put the bug in the Scriptrunner Doc. I will see if we can get a note about how to construct the paths to script files rather than referencing a bug that we will hopefully fix. I agree that it is hard to find scripts if you do not know how the paths are constructed or how ScriptRunner will see them.
2- At the moment, we decided not to show read-only script roots in the script editor when we added multiple script root selection. We are looking into it separately, but I cannot say if it will happen or not yet.
I think it is more likely we would add read-only directory support rather than bring back the old way we used to show available script roots.
3- I am not sure I understand what part confuses you, so I am not 100% sure what to expand on.
I think you are referring to what goes into the jar from the 'groovy' or 'resources' directory.
I did not mean to indicate it is one or the other. This structure of having a `main/groovy` and `main/resources` is just a standard for how maven projects work, as far as I know.
In a typical Maven project, you have a library sources folder `src/main/groovy` and a library resources folder `src/main/resources`.
Typically you make classes in the sources folder and the scripts that use those classes in the resources folder.
When it is compiled into a jar those directory concepts are removed and they will be combined into a structure representing the package names.
So if from the Intellij maven project view you have:
`scriptrunner-samples/jira/src/main/groovy/com/mythings/HelperMethods.groovy`
where the package name is `com.mythings`
and
`scriptrunner-samples/jira/src/main/resources/com/mythings/myscript.groovy`
where the package name is also `com.mythings`
it would compile to a jar (which is essentially a special java zip) with a structure like:
`/com/mythings/HelperMethods.groovy`
and
`/com/mythings/myscript.groovy`
with both `HelperMethods.groovy` and `myscript.groovy` inside the `mythings` folder, which is then inside the `com` folder.
4- I think this might be a mistake we made because the samples plugin source code comes with a folder named `com.adaptavist` (1 folder) with the `CustomEventListenerScript.groovy` inside it.
So it is a folder with a '.' in its name rather than a `com` folder with a nested `adaptavist` folder.
I cant see a reason in the commit history so I think it was just some IntelliJ shortcut used to make a folder structure that ended up making 1 folder instead of 2, and it went unnoticed. You should be able to avoid this problem if you just make sure to make nested folders. I will also make a bug to fix that, as that does appear to cause some confusion.
I think it only causes a problem because we are trying to manually write script file paths because auto complete is broken and we expect the package name `.` character to be replaced by the file separator when we have to type out the path.
Essentially it is just a folder, so any script inside that folder would just have a path like this `com.adaptavist/myOtherScript.groovy`
I hope this helps clear some things up :-)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks again @Matthew Clark. With the same numbering:
1. Back in the environment described in my initial post, I was able to paste and run org/broadband_forum/main/scripts/script.groovy and it disappeared when I uninstalled the app. So that's all as expected and you've definitely solved my problem!
1a. Yes I understand why it's not appropriate to reference the auto-completion bug. It would just be good to make it clear that if auto-completion doesn't work then the user should always try specifying a full path.
(I've had problems before with auto-completion not working, but not with it working for some files and not for other files. I think that was the killer.)
2. OK.
3. Thanks very much. I think I've got it now. I have almost zero knowledge of maven and am not a Java programmer, so I don't know the conventions here. I was missing the idea that the JAR will contain files copied from multiple source roots into a single tree (this is probably completely obvious to everyone else!).
4. When first I wrote this I was assuming that a structure like this is wrong:
com/
example/
birds/
Emu.groovy
example.animals/
Aardvark.groovy
...but I just tried it in IntelliJ and it doesn't complain, so I guess it's not wrong, just confusing (I hadn't considered the fact that if affects whether you need to use dot or slash separators in paths).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We too are having trouble with this and would like some resolution.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.