Dirk Schnelle-Walka
Dirk Schnelle-Walka

Reputation: 41

filter gradle configuration for specific libraries

I am currently about to migrate the build system for my project from ANT to gradle. So I am pretty new to gradle My project features a plugin mechanism that dynamically loads jars configured in an XML file. Each plugin is in its own subproject. The entries of the XML configuration look as follows

<?xml version="1.0" encoding="UTF-8"?>
<implementation ...>
    <repository>text</repository>
    <classpath>library1.jar</classpath>
    <classpath>library2.jar</classpath>
    ...
</implementation>

I added an XSL transformation to prefix each entry with the correct lib folder in the build folder to make it usable in a run task of my main project.

This already works OK for the libraries that are created within my project. However, some of them rely on third party libraries, e.g., protobuf.

For now, I solved this by copying all referenced jars to the lib folder. My build.gradle looks as follows

dependencies {
    compile group: 'com.google.protobuf', name: 'protobuf-java', version: '3.1.0'
    ...
    compile project(':main')
}

task copyReferencedLibraries(type: Copy) {
    into "$buildDir/libs"
    from configurations.compile
}

jar {
    dependsOn xslt
    dependsOn copyReferencedLibraries
    ...
}

However, this copies all libraries, including those inherited from the main project to the lib folder. More than I actually need.

How could I filter the libraries to those defined in this subproject or at least manually filter the ones that I want to be copied?

Upvotes: 3

Views: 2409

Answers (1)

JBirdVegas
JBirdVegas

Reputation: 11405

You could just filter in your Copy task

task copyReferencedLibraries(type: Copy) {
    into "$buildDir/libs"
    from(configurations.compile) {
        exclude 'some.jar', 'some-other.jar'
        include 'some-required.jar', 'some-other-required.jar'
    }
}

Reference: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Copy.html

Just be careful you don't exclude second or third tier dependency (ie a jar required by a jar your using). If you do then you won't get compile errors you will get runtime errors when the code is executed that touches the missing dependency.

Upvotes: 2

Related Questions