hierynomus/license-gradle-plugin

SourceSet excludes impacts JAR packaging

jdpgrailsdev opened this issue · 4 comments

If I add the following to my build.gradle script:

license {
    header rootProject.file('../LICENSE_HEADER.txt')
    strictCheck true
    mapping {
        java='SLASHSTAR_STYLE'
        groovy='SLASHSTAR_STYLE'
    }

    sourceSets {
        main {
            resources {
                exclude '**/*.properties'
            }
        }
    }
}

the plugin correctly skips checking the header on any files in the src/main/resources source folder. However, it appears to also have the side effect of excluding those artifacts from the packaged JAR. My guess is that it is updating the global sourceSets for the build script. This should probably be changed to have a separate excludes configuration property like the corresponding Maven plugin:

<plugin>
    <groupId>com.mycila.maven-license-plugin</groupId>
    <artifactId>maven-license-plugin</artifactId>
    <version>1.9.0</version>
    <configuration>
        <header>${licensePath}</header>
        <excludes>
            <exclude>**/*.properties</exclude>
        </excludes>
        <mapping>
            <java>SLASHSTAR_STYLE</java>
            <groovy>SLASHSTAR_STYLE</groovy>
        </mapping>
        <strictCheck>true</strictCheck>
    </configuration>
</plugin>

Of course, if I could figure out why it fails the check on the license in a properties file, this would be a lesser issue (though still something I believe is worth correcting).

There are definitely valid usecases for defining exclusions that you don't want to impact the rest of the build (for example, on https://github.com/spring-projects/spring-xd we only want licenses on our .java files, but not on the resources/ files. Yet we obviously want them to be seen / included during the build)

Continuing discussion here as it seems to be the most sensible place.
I did try to apply the latest snapshot to our use case (Spring XD).
While I guess I could endup making it work, it feels very cumbersome. What we want is to apply the plugin to *.java files only (i.e. include *.java), as opposed to trying to list all current (and future) excludes

I also understand that replicating the functionality provided by source sets may be a real pain for you :( ..

@ericbottard If you can open an issue, I'll include includes functionality as well, shouldn't be too hard of a change.