The only real problem I can forsee is that the names of DSL files in the global lib are, well, global.

eg:

builg.groovy is used as

build {
..
}

In the script. If you install 2 plugins that each want to have a build.groovy - how is the conflict resolved? will the second one they install fail?
(I fear to suggest qualified imports.... as that kind of harshes the vibe, but some way to resolve this may be warranted).

Good point. I'd probably lean towards qualified imports - we've already got a de facto requirement for uniqueness on plugin IDs, package/class names, etc, so there should be something we can reuse from that, first instinct being plugin IDs, so something like plugin "pipeline-my-dsl" providing the equivalent of "src/build.groovy" in the global library would be used as:

pipeline-my-dsl.build { ... }

Less elegant, but also safer, obviously. =)

Currently this is your option. Likely we will need a stronger API to support inclusion in DSLD/GDSL in the future.

Based on what I have seen, I think there is sufficient ability for plugins to add to a global library already - by providing a GlobalVariable extension. Some intelligence needs to be applied around naming and state, but overall, it works just fine (or can be sugared up). There is no need for plugins to "commit" to the workflowLibs repo - I think that would be not right.

So I vote we close this in favour of an example/wiki page as "done".

I think there is sufficient ability for plugins to add to a global library already - by providing a GlobalVariable extension

…but we still need an API to allow DSLD/GDSL generators to know that a given variable has a type given by a specific Groovy resource, so they could have a chance at offering strong typing. For example, if docker-workflow is installed, you would ideally like IDEA to be able to complete docker.image('maven').ins to inside.

+1 - I wonder if we might want to end up doing something with annotations here...

Prefer to avoid annotations unless there is something that cannot be done without them.

GroovyFileGlobalVariable is a prototype but does not suffice for code completion.

Also need to allow the library code to be loaded in trusted mode, which the GlobalVariable API does not currently make straightforward. That would simplify some things; for example DockerDSL.MiscWhitelist could be deleted, and @Whitelisted removed from ImageNameTokens.

allow the library code to be loaded in trusted mode

Turns out this already works, as of JENKINS-34650.

Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/docker/workflow/DockerDSL.java
src/main/java/org/jenkinsci/plugins/docker/workflow/ImageNameTokens.java
http://jenkins-ci.org/commit/docker-workflow-plugin/abe4066b6b4eb1af3e922897add192df4e0294ef
Log:
JENKINS-32731 JENKINS-34650 Docker.groovy is already trusted.

Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/docker/workflow/DockerDSL.java
src/main/java/org/jenkinsci/plugins/docker/workflow/ImageNameTokens.java
src/main/resources/org/jenkinsci/plugins/docker/workflow/Docker.groovy
http://jenkins-ci.org/commit/docker-workflow-plugin/223612bc8378cc3e02cc6fecee1416c5bd533af9
Log:
Merge pull request #75 from jglick/GlobalVariable-JENKINS-32731

JENKINS-32731 JENKINS-34650 Docker.groovy is already trusted

Compare: https://github.com/jenkinsci/docker-workflow-plugin/compare/1f5f9d0147c4...223612bc8378

The current situation is sufficient, so I'm closing this.