1

I'm in the process of developing a shared library for Jenkins with scripts in vars/ and classes in src/. I have these two stumbling blocks:

  1. I use a Jenkins-specific method sh or echo. It is greyed out because Eclipse doesn't recognize it as a proper Groovy method. Is there a way to make these "known" to Eclipse?

  2. I create a file vars/foo.groovy with two methods, call() and helper(). Using foo() anywhere int he program results in it being greyed out, suggesting that Eclipse doesn't know what this refers to. Is there a way to make Eclipse understand that foo() is now a legal method?
    Note that inside foo.groovy, both call() and helper() are recognized as valid methods. The same holds true for a class src/clazz.groovy - using new clazz() gets recognized everywhere in the shared library as valid code and the shown doc refers to the clazz.groovy file.

All of this works fine if run on Jenkins, this is purely about syntax highlighting and, if possible, showing the Javadoc when hovering over the functions. Syntax highlighting is the main concern, though, as it is a PITA to deploy a shared library only to notice there's a typo in some function somewhere I didn't catch because it's all greyed out.
The default Groovy syntax highlighting works, this is just about methods relating directly to Jenkins and/or the shared library.

This doesn't help me as it refers to IntelliJ which is sadly not an option.

MrThaler
  • 124
  • 8
  • Can you include a small sample project so I can see how the sources really relate and for experimentation? – emilles Aug 11 '20 at 22:19
  • @emilles What would be the best way to do that? Include code snippets or upload something somewhere? – MrThaler Aug 12 '20 at 07:33
  • You can create a small public repository on GitHub or you could file a new issue at https://github.com/groovy/groovy-eclipse/issues, which should allow archive and image attachments. – emilles Aug 12 '20 at 12:55
  • I just ran into this problem too. Pure Jenkinsfiles are recognized directly but anything inside a "def call() { pipeline { ... } }" is not. It's a big pity. – Raúl Salinas-Monteagudo Nov 22 '21 at 12:43

1 Answers1

1

You can add individual inference suggestions using quick assist (Ctrl+1) or you can create a DSLD that gives more complete slash complex information. If your script is using methods defined by a specific type, you can use @BaseScript annotation.

If your scripts (in vars folder) are not part of project classpath, they won't be available for import or static import.

emilles
  • 1,104
  • 7
  • 14
  • I think they are part of the classpath (Eclipse shows the folder as a source folder and syntax highlighting works). BaseScript doesn't seem to be the right solution, though - files in the `vars/´ folder aren't *really* scripts as they all have to contain a `call()` method and everything outside method blocks is being ignored. I tried `@BaseScript` but it complains that it is not supposed to be attached to a method. Inference seems to be a good workaround - any way of doing this on a project level instead of a per-file basis? I haven't found anything for this unfortunately. – MrThaler Aug 12 '20 at 12:00