Rethinking settings propagation to inner test modules

[lefou]

While implementing and testing #3460, I discovered a downside of our current inner test sub-module approach. Since the inner JavaTests trait automatically initializes it's compiler setup from its outer module (e.g. def javacOptions = T{ outer.javacOptions() }), compiler plugins like error-prone are automatically applied to all test sources. It's rather hard to later disable it in the actual modules, esp. if other traits contribute to the configuration too. But disabling it in tests is most likely what users want, since test typically use bad code practices for some reasons, e.g. ignoring return values, self-comparisions, static initializations.

Therefore, we should find a way to better handle it. We could make inheriting optional/configurable. Or provide a dedicated testJavacOptions to contain options to forward to tests.

Originally posted by @lefou in #3460 (comment)

[lihaoyi]

I guess the question is what should we propagate or not? Like repositoriesTask should probably be propagated. scalaVersion as well for ScalaModules. javacOptions is less obvious, but I can imagine someone who turns on e.g. Lombok in their application code would expect it to be available in their test code.

Maybe we just need to make it easier to opt out of propagating things we don't want? e.g. thisModuleOnlyJavacOptions or something that is like javacOptions but not propagated

[lefou]

There was a question on Gitter recently touching the same topic:

Hi, is there a way to pass scalac options such that those are only applied to the main, not the test?
I currently define scalacOptions which get applied to both

I think we need two kind of javac/scalac options. Those common, like -encoding, -release, or -deprecation which we share with the test modules, and some module specific, like linters or annotation processors. So, the hardest thing left is probably naming.

[lefou]

I see two variants.

Implement it in the inner trait

We would need to provide an accessor the the outer settings, so users can use them if needed.

Downside is, that we can't easily control it via shared modules which typically handle the outer level.

Implement in the outer trait

This makes sharing the setup easier, since we support moving common setups into shared modules.

We could have a testSharedJavacOptions, which will be automatically propagated to the test modules.

Downside is, we get yet another location where tests are configured. And since the test modules are also JavaModules, we end up with a testSharedJavacOptions in the test module itself, which might be confusing and misleading. But we also have a JavaTests trait in a JavaTests trait, so this should already be confusing, but never popped up as an issue.

Considerations

We could split JavaModule into some JavaBaseModule (I don't mean the already existing JavaModuleBase which is more like some DependencyAwareModule), where only the former has the convenient JavaTests trait and some targets to configure it. The JavaTests could only be a JavaBaseModule.

[lihaoyi]

I'm not that much of a fan of having testShared* tasks. If anyone wants to share stuff with tests, assuming we don't share it already, they can define their own inner trait FooTests extends JavaTests just like they define trait MyModule extends JavaModule for sharing stuff among non-test modules. A bit of boilerplate, but it avoids the worse boilerplate of duplicating everything task for shared/non-shared variants. Similarly, if they want to unshare stuff that is currently shared, they can use the same trait FooTests extends JavaTests and set def javacOptions = Nil.

[lefou]

So, the actual issue is, that once a more complex trait-based contributor (e.g. ErrorProneModule) to javacOptions comes into play, it's hard to manage inner test modules, which automatically inherit the outer javacOptions. It's rather difficult to customize the inner module, e.g. by explicitly inheriting the the ErrorProneModule or by filtering the javacOptions. The underlying issue is probably that traits wanting to contribute compiler plugins need to use javacOptions at all.

How about introducing an additional configuration target for compiler options dedicated to this case and not automatically ineriting the value of the outer module? It could be managedJavacOptions or providedJavacOptions?

FTR, we have a similar concept with compiler plugin provision in ScalaModule, enabledScalacPluginOptions which isn't propagated from the outer to the inner module.

[lefou]

• Add JavaModule.mandatoryJavacOptions #3503