Fix Build scan capture extension registration when using the Maven wrapper

[jprinet]

Issue

No Develocity Build scans are being published because the Maven extension to capture unpublished Build Scans is not registered.

When using the Maven wrapper, a Maven extension can't be registered once at the beginning of the build by copying it to $MAVEN_HOME/lib/ext as the folder is created on the first mvnw invocation (and emptied if already present).

Fix

Install the Maven extension in ./maven-build-scan-capture/lib/ext (using a relative path makes this approach compatible with Windows OS) and register the Maven extension as a Maven CLI argument (-Dmaven.ext.class.path)

[gsmet]

We cannot register the extension in the pom.xml directly using a profile? That would maybe makes things easier?

[jprinet]

It's a core extension and according to the doc, the registration options are:

• $MAVEN_HOME/lib/ext
• extensions.xml
• CLI argument -Dmaven.ext.class.path=extension.jar

This extension should not be added systematically, therefore the CLI argument solution

[gsmet]

Thanks!

[gsmet]

@jprinet I was a bit too optimistic on this one and had to revert it because it looks as if build-scan-data are included in nested projects:

java.lang.AssertionError: 
[Snapshot is not matching (use -Dsnap to update it automatically):CreateExtensionMojoIT/testCreateCoreExtension/dir-tree.snapshot] 
Expecting actual:
  ["/",
    "bom/",
    "bom/application/",
    "bom/application/pom.xml",
    "build-scan-data/",
    "build-scan-data/1.18.1/",
    "build-scan-data/1.18.1/previous/",
    "build-scan-data/1.18.1/previous/1702291663404-27469121-9c20-4e47-aed6-32db6139e80e/",
    "build-scan-data/1.18.1/previous/1702291663404-27469121-9c20-4e47-aed6-32db6139e80e/build-scan-metadata.properties",
    "build-scan-data/1.18.1/previous/1702291663404-27469121-9c20-4e47-aed6-32db6139e80e/scan.properties",
    "build-scan-data/1.18.1/previous/1702291663404-27469121-9c20-4e47-aed6-32db6139e80e/scan.scan",
    "build-scan-data/1.18.1/spool/",
    "build-scan-data/1.18.1/spool/13885e8f-487d-4762-afa2-b5f81fb9904b.scan",
    "build-scan-data/1.18.1/spool/245faeed-0f66-4b51-9218-55afa36cad55.scan",
    "build-scan-data/1.18.1/spool/30044a69-f46f-42cd-bac9-a2ae8f1a930d.scan",
    "build-scan-data/1.18.1/spool/4d59400a-0049-40b8-ab5c-e09d3ac72236.scan",
    "build-scan-data/1.18.1/spool/5e84a84d-2431-4c39-bcce-de340fbda870.scan",
    "build-scan-data/1.18.1/spool/9e3a4921-24cc-4457-a2eb-6e3dc92d014c.scan",
    "build-scan-data/1.18.1/spool/b86dce74-01d9-4a27-ab87-43656eb112bd.scan",
    "build-scan-data/1.18.1/spool/c54024a9-6f1d-4cb1-a39a-5af77ea6f476.scan",
    "build-scan-data/1.18.1/spool/c94d5aaf-63a4-486b-aa7b-863c359438c4.scan",
    "extensions/",

[gsmet]

Oh wait, no, there's something very odd with this test...

[gsmet]

OK, so the test is adding an extension in the tree itself and then testing that the tree doesn't contain anything odd.

I think the build-scan-data directory should be moved to target/ if possible to avoid anything odd?

[jprinet]

I changed the copy directory to env.RUNNER_TEMP
I validated the behavior on Windows and Linux runners
Can you give it a try @gsmet ?

[jprinet]

Alright, you reverted the change, let me submit a new PR

[jprinet]

I created #37663 @gsmet