permits them to be used in type declarations in the script, for example: @Library('somelib') import com.mycorp.pipeline.somelib.Helper int useSomeLib(Helper helper) { helper.prepare() return helper.count() } echo useSomeLib(new Helper('some text')) library 'my-shared-library' library('my-shared-library').com.mycorp.pipeline.Utils.someStaticMethod() 63 You can also access  static  fields, and call constructors as if they were  static  methods named  new : However you may use library classes dynamically (without type checking), accessing them by fully- qualified name from the return value of the  library  step.  static  methods can be invoked using a Java-like syntax: Using classes from the  src/  directory is also possible, but trickier. Whereas the  @Library  annotation prepares the “classpath” of the script prior to compilation, by the time a  library  step is encountered the script has already been compiled. Therefore you cannot  import  or otherwise “statically” refer to types from the library. Thereafter, any global variables from that library will be accessible to the script. Global Variables however, are resolved at runtime. As of version 2.7 of the  Pipeline: Shared Groovy Libraries  plugin, there is a new option for loading (non-implicit) libraries in a script: a  library  step that loads a library  dynamically , at any time during the build. If you are only interested in using global variables/functions (from the  vars/  directory), the syntax is quite simple: Loading libraries dynamically