Exclude default contents of Distribution Plugin


(Lars Kaulen) #1

Probably a pretty easy to answer question, but I can’t find the correct approach neither in the documentation nor in the forum.
When using the Distribution Plugin, the (by the ‘distZip’-task) generated Zip contains all runtime dependencies in the ‘lib’ folder. I want to use this feature but exclude specific jars, as they depend on the java version the costumer is using and need to be placed there manually. I tried to use the following code:

distributions.main.contents {
    into('lib') {
        from(configurations.runtime).exclude('**/patternToExclude*')
    }
}

Problem is afterwards every jar (except the ones excludes) are included twice in the zip, as they got already included by the default behavior.
What would be the common way to resolve this? Do I need to perform an explicit delete operation on the zip after it has been created?


(Adam Kunicki) #2

You’re using the Java Library distribution plugin, not the Distribution plugin it sounds like.
I came across the same issue as we package our jars a little differently, so instead I use the vanilla Distribution plugin and create my own configuration. For example:

apply plugin: 'distribution'

  // Disable creation of zips, we currently only ship tarballs
  distZip.enabled = false

  configurations {
    runtimeJars
  }

  dependencies {
    runtimeJars configurations.runtimeClasspath - configurations.providedCompile
  }

  distributions {
    main {
      contents {
        from tasks.withType(Jar) // app artifact
        from configurations.runtimeJars
      }
    }
  }

(Lars Kaulen) #3

Hi, thanks for your input.
I am using the Application plugin which might have the same effect as using the Java Library Distribution plugin.
For me it was more of a misunderstanding of the default configurations provided by the Java plugin. I did end up placing the needed dependencies in the comileOnly configuration. As stated here these should be used in the following use cases:

Compile-only dependencies address a number of use cases, including:
  1. Dependencies required at compile time but never required at runtime, such as source-only annotations or annotation processors;
  2. Dependencies required at compile time but required at runtime only when using certain features, a.k.a. optional dependencies;
  3. Dependencies whose API is required at compile time but whose implementation is to be provided by a consuming library, application or runtime environment.

As the third use case is exactly what I needed, this was my approach which did work as I wanted it to and the dependencies were not placed in the distribution anymore. Example:

configurations {
    compileOnly.extendsFrom dependenciesNotToBeDelivered
}