Publish CLI combined Jar as separate artifact from the base Jar and fix code coverage report #3654
+42
−27
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.
This makes a few changes to the way that we handle the relational CLI jar.
Firstly, it migrates the Relational CLI project from some custom code that would copy classes into the Jar to using the "shadow" plugin already in use in other sub-projects to create the combined Jar.
Secondly, it updates the artifacts for that project so that we now publish the combined jar as
fdb-relational-cli-${VERSION}-all.jar
, and so the "base" jar contains only that subproject's logic, which is more in line with the way the rest of the project's are published. That does mean that anyone who is relying on using the combined jar should switch their dependency from:group: 'org.foundationdb', name: 'fdb-relational-cli'
togroup: 'org.foundationdb', name: 'fdb-relational-cli', classifier: 'all
'. I did double check the CLI script that we have in the repo: (https://github.com/FoundationDB/fdb-record-layer/blob/main/fdb-relational-cli/bin/fdb-relational-sqlline). That script relies on invoking the generated command line script that is generated during building, and that has logic to set the class path correctly so that we get the dependencies, so it should still work.Thirdly, we now build the
jar
during code coverage report analysis. This allows code coverage to more accurately report on the classes from Relational CLI. You can see this in a recent teamscale run. Compare:Customize.java
coverage with the new changes toCustomize.java
coverage onmain
. Note that the file is marked as fully covered with the changes here, whereas it was reported as missing data before.