Support per-execution scalac configuration (#29)#147
Open
jozanek wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #29.
Maven lets the
scala-maven-plugin<configuration>be overridden on a per-execution basis, so thecompileandtestCompilegoals can carry different scalac options — e.g. enablingkind-projectorfor one but not the other.Previously the plugin merged all executions into a single union config and applied it to both the compile and test Bloop projects, so per-goal differences were lost: Maven would compile the project fine while Bloop/Metals diverged.
What changed
initializeMojonow derives each goal's scalac options from the config Maven itself would pass toscala:compile/scala:testCompile: the plugin-level<configuration>merged with the<configuration>of the executions bound to that goal (execution-level dominating). The resulting compile/test arg lists are stashed onBloopMojoand selected per configuration when writing each Bloop project.Notable details:
Xpp3Dom.mergeXpp3Dommutates its dominant argument, so every DOM is deep-cloned before merging. Without this, building one view (the union) would contaminate the shared Maven-model objects reused to build the compile/test splits.compile/testCompilefeed the respective split. Executions bound to unrelated goals (e.g.add-source) or no goals are excluded from the splits, but still feed the union/primary mojo, which backs Scala-version detection.scala-maven-pluginstill synthesizes its defaults (-target/-releasefrommaven.compiler.*) and honors user properties, rather than collapsing to no options.getScalacArgsfailures are swallowed (logged at debug) so a Java-only module that merely inheritsscala-maven-pluginstill gets a config written, matching the previous forgiving behavior.Scope: only scalac options are split per goal. Scala version/context, compiler jars, organization and compile setup still come from the union view, as these don't vary per goal in practice.