Fix core export provider

[oehme]

Since apache/maven#616, the default CoreExportProvider no longer uses the provided CoreExports, but instead tries (and fails) to discover them itself.

This change fixes that by providing our own custom instance of CoreExportProvider. This allows core extension to contribute exported artifacts and exported packages again, like it used to do before the Maven 4.x upgrade.

[oehme]

The underlying reason why the default logic doesn't work is because the discovery method calls ClassRealm.loadResourcesFromImport, which does not handle META-INF entries from imported realms. It looks up the name META-INF/maven/extension.xml and matches that against the import realms. The matching logic only accounts for classes/resources in packages, but doesn't account for META-INF. So it never never finds the extension.xml entries.

maven-embedder has the same problem now.

Really, loadResourcesFromImport is broken. It should iterate over all imports and try to load the resources from each of them, rather than trying to find a single one. This is a performance optimization that has gone too far and breaks correctness. But given that this bug and the workaround in MavenCli has existed for so long, I've opted to provide a quick fix to unblock further testing of the Maven daemon.

[ppalaga]

I have resterted the ubuntu-18.04 CI job. Not sure why it has shown up as cancelled.

[gnodet]

@oehme thx for the detailed explanation. Would it be possible to add an IT to test this feature ?

[oehme]

Yes, I'll add one

[oehme]

@gnodet The test infrastructure assumes that every test case is a single project, but for my case I had to install the extension first before using it in the consuming build. I hacked around this by adding the project dir as an additional parameter, but I'd love suggestions for a more elegant solution.

[ppalaga]

The test infrastructure assumes that every test case is a single project, but for my case I had to install the extension first before using it in the consuming build. I hacked around this by adding the project dir as an additional parameter, but I'd love suggestions for a more elegant solution.

I have left a suggestion inline.

[oehme]

@ppalaga this should be good to go :)

[ppalaga]

I'll let @gnodet re-review and merge.

[oehme]

Would it be possible to get an m2 for this? I'd love to run our extensions full CI build against this to make sure we work properly when 1.0 comes out.

[ppalaga]

We actually used to publish the binaries produced by the given PR's CI run via Checks -> Artifacts

Let me check why they are not there anymore.

[gnodet]

Would it be possible to get an m2 for this? I'd love to run our extensions full CI build against this to make sure we work properly when 1.0 comes out.

Yes, though I'd like to have a maven 4.0.0-alpha-4 release and then release mvnd 1.0.0-m2.

[ppalaga]

Here is a fix for GH Actions not publishing the PR's binaries #774

[ppalaga]

@oehme, BTW if you now send some dummy PR, it will publish the distribution zips for 3 (of 4, excl. Apple M1) supported platforms under Checks > Artifacts. You could perhaps use those to test on your side?