Then you might as well merge them into one library.

I know that this has been closed as Won't Do, but I want to share an additional use case where this might be useful to have.
We like to have testing code and the code for the shared library related to the tests close together - i.e. in one repo.
The directory structure looks like this e.g.

src/main/java/<package_name>
src/main/resources/<package_name>
src/test/java/<package_name>

and so on.

If I add now the shared library to this it's like this

src/<package_name>
vars/

I.e. it 'taints' the global directory structure of the project

I'd rather more like it to be something like this:

src/pipeline/groovy
src/pipeline/vars

I am facing similar issue as described above. We have src/main/groovy/<package_name> and src/test/groovy/<package_name>. But, I would like to point to src/main/groovy or update my classpath to use the correct directory. Have you found any solution or a workaround?

Thanks in advance.

Another reason the /vars location is bad: it breaks IDE classpaths.  I can't just set / as the source root if I also want stuff under /src to be counted as the classpath, so it's forced me to add a symlink: src/vars -> ../vars.  I'd much rather have the pipeline stuff follow standard maven project conventions (such as src/main/).

With the bug marked "won't do", I can't even select "vote for this issue".

I use the global-shared-library archetype at https://github.com/jenkinsci/archetypes and am wondering how to use this in Jenkins out-of-the-box without creating two repositories.

For anyone interested in a workaround. I got a repo to work as a Jenkinsfile repo and as Shared Library, complete with jenkins-pipeline-unit and JUnit5 tests, by using Gradle.

Here's my build.gradle:

apply plugin: 'groovy'

group 'com.tieto'
version '1.0-SNAPSHOT'

sourceCompatibility = 1.8

sourceSets {
    main.groovy.srcDirs = ['src']
    test.groovy.srcDirs = ['test']
    vars.groovy.srcDirs = ['vars']
}

repositories { mavenCentral() }

String junitVersion = '5.3.1'
dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.4.12'
    testCompile (
            "org.junit.jupiter:junit-jupiter-api:$junitVersion",
            'com.lesfurets:jenkins-pipeline-unit:1.1',
    )
    testRuntimeOnly ("org.junit.jupiter:junit-jupiter-engine:$junitVersion")
}

test {
    useJUnitPlatform()
    testLogging.showStandardStreams = true
}

And here's how my repo is structured:

This issue was marked closed in 2016.

Since the closure of this issue in 2016, it has been heavily requested in the comments.
Re-opening for reconsideration of the requested feature.

I submitted a fix to this, and have made a pull request (checks passed, pending merge), 

https://github.com/jenkinsci/workflow-cps-global-lib-plugin/pull/84

In this attempted fix, I added a "Library base path" (libBasePath) to "Global Pipeline Libraries" configuration, which is a relative path, e.g. common/subprojects/sharedlibs/, that will be added to the library path so that the library will be loaded from "${libBasePath}/src/*/.groovy", "${libBasePath}/vars/.groovy", "${libBasePath}/vars/.txt", "${libBasePath}/resources/". If blank, the library will be loaded from default location under project root of code repository "src/*/.groovy", "vars/.groovy", "vars/.txt", "resources/". 

These sort of issues with shared libraries (like not being able to load one library from the local filesystem in a clean manner) makes me sometimes feel to look for a complete different alternative to Jenkins.

+1 for this

Since there's a PR that seems to fix this, can someone take a look at merging it please? Would be very useful to not have to create yet another git repo in my team's already expansive set of repos. I have a "devops" repo already with other devopsy stuff in it. I would love to commit the pipeline shared libraries into that instead of creating a special one just for Jenkins.