Is it currently possible to extend a config that is not the base config? Would this be something we...

# detekt

[zmoore]

Is it currently possible to extend a config that is not the base config? Would this be something we would be interested in in the library?

[schalkms]

Do you know about the buildUponDefaultConfig = true config option? If I understand you correctly, it's exactly what you need.

[Artur Bosch]

The config property/flag supports comma separated config paths e.g. "${rootProject.resolve('top-config')},${project.resolve('relative-path-config')}" .
Isn't this exactly what you want?
The top level project config is the general config and the module config's are merged on the base config.

[chao]

That’s interesting. I was wondering if I should customize our own plugin to merge config files, but it does exist today.

[chao]

Thanks @schalkms @Artur Bosch for the information. This is very close to what we want.

[chao]

(I have to confess that we have a custom gradle plugin to run Detekt Task, so I would need to port the code and test if our custom gradle plugin that handles this case

[Artur Bosch]

It's the cli flag config which handles this case. So your gradle plugin should also be able to use it 😉.
What are your additional use cases so you need a custom gradle plugin?

[chao]

We found it hard to process AndroidSourceSet where we would like one gradle task per AndroidSourceSet

[zmoore]

We also merge checkstyle reports from all our tasks into a single one