Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nested projects don't play well with default input files #38

Open
JakeWharton opened this issue Jun 26, 2019 · 2 comments
Open

Nested projects don't play well with default input files #38

JakeWharton opened this issue Jun 26, 2019 · 2 comments

Comments

@JakeWharton
Copy link

By using the project directory as the default input, nested projects are automatically formatted.

For example,

.
├── LICENSE.txt
├── README.md
├── foo
│   ├── bar
│   │   ├── src/main/java
│   │   └── build.gradle
│   ├── src/main/java
│   └── build.gradle
├ build.gradle
└ settings.gradle

This is a basic example. The real project has many more modules. The idea, though, is that the root build.gradle is applying the plugin to all subprojects except for certain ones. In this case, let's say we're excluding "bar".

The problem, though, is that by applying it in "foo" the sources in "bar" will automatically be formatted.

For now, I can configure this myself and have each project specify only its Java source folders as GJF sources, but it would be nice if this was the default. Operating outside of these folders would then become the thing which required explicit configuration.

@sherter
Copy link
Owner

sherter commented Jun 26, 2019

There are arguments against using the project's java sourceSets as default input (see #3 and #11). I'm not sure if this is still an issue for Android builds.

Adding default excludes for subproject directories might be a solution. Would that solve your problem?

@JakeWharton
Copy link
Author

Ah, good 'ol Android Gradle plugin. I did search for history on the topic but didn't read past the issue descriptions. The important bits are in the follow-up comments of those.

There's really only two plugins (or at least their supertypes) that cover 99.99% of use cases, right? The Java base plugin and Android base plugin. Detecting these would give you a working plugin without configuration in almost every case. Anyone doing something more bespoke could still do something custom.

Excluding subproject directories would certainly seem to solve it, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants