Allow for using a PatternFilterable to determine source processed by JavaExtension and KotlinExtension

[JLLeitschuh]

Sometimes you want your entire source code to be linted/formatted except for some code in a particular package.

For example, in my project I want everything reformatted except for things in files that match the pattern **/generated/**.

When setting up my java source sets, if I didn't want these files to be compiled I could do something like this:

sourceSets {
    "main" {
        java {
            exclude("**/generated/**")
        }
    }
}

I propose that spotless should expose the same API for filtering out sources that I don't want to be linted or reformatted.

I would expose an API that allowed the user to use a PatternFilterable to configure what is excluded from the task's target FileCollection.

[nedtwigg]

It's possible to do this already with target, but it would be easier with this. I'm worried about documenting this feature, specifically how it interacts with default targets and manually-set targets.

If you can make the documentation easy for users, and the implementation doesn't add a large maintenance burden, I'd be happy to merge.

[JLLeitschuh]

Do you mean by using javadocs or by updating the information in the README?

I use plugin Javadocs a lot but that's because I use Gradle Kotlin DSL so I get actual plugin source code I can navigate to.

Do you think that target should take precedence and override any configured sourceSets configuration?

Also, would it make sense to filter by source set or would that overcomplicate the issue?

[nedtwigg]

Do you mean by using javadocs or by updating the information in the README?

Both, but especially the README. "Spotless will format every file in target, and if you don't set it then the default value is X" is the contract right now.

Do you think that target should take precedence and override any configured sourceSets configuration? Would it make sense to filter by source set or would that overcomplicate the issue?

I dunno. What's nice about just having target is that we don't have to answer any of these questions. If a user wants a special behavior, the API we have to test and document is just "set target to what you need".

For my projects, generated code is always in its own sourceset, and I set the target explicitly, e.g.

java {
    target 'src/main/java/**/*.java', 'src/test/java/**/*.java' 
    // this avoids src/main/generated-jooq and src/main/generated-rocker
}

The questions you are asking are the right ones. My conclusion is "target is easy and good enough", but I've put very little effort into it. If you find a better solution, I'm all for it! Just make sure you've figured out what the behavior ought to be, and how you'd like to communicate it to users, before you spend time building it.

[JLLeitschuh]

The problem with what I've got is that my company has our generated jooq code in the src/main/java directory so filtering isn't that simple.

Currently the build is in maven but I'm thinking about attempting a second rewrite in gradle (the first attempt (which was successful!!) died on a feature branch that got killed 😢)

[nedtwigg]

How long ago did it get killed? You should still be able to grab it from the reflog. (little video of my fav free reflog tool)

[JLLeitschuh]

It's not time. It's just that most of it lives on a git branch that has deviated so far from master that it's going to be difficult to redo. I still have the branch checked out in a separate clone of the repo on my work machine.

I had to move a lot of code around to get it to work, ended up deleting some irrelevant projects for that the feature was making irrelevant, ect. That feature (actually more of a full project) got killed so the old code was still relevant.

I can port much of the same gradle logic, but I need to do the refactor and move code around dance all over again.

[nedtwigg]

I've proposed a fix in #353.

[nedtwigg]

Fixed in 3.18.0.