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.

Close try

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...