build(deps)!: bump maven-core from 3.6.3 to 3.8.1

[jeremylong]

BREAKING CHANGE: dependency-check-maven now requires maven 3.8.1 or newer
Resolves #7566

[aikebah]

LGTM; not required, but it saves us a whole lot of confusion and anyone interested in secure development pipelines should've upgraded to 3.8.1 or later anyhow.

Not sure how soon you'd like to release it as I can foresee my local attempts to get rid of the deprecated maven-artifact-transfer (https://github.com/apache/maven-artifact-transfer?tab=readme-ov-file#deprecation) as something that could likely trigger a new major (as it would be a good time to further cleanup/refactoring of the maven plugin amongst others addressing the plugin-dependencies-scope issue).

Hope to spend some serious time on that the week after ascension day.

[jeremylong]

@aikebah I'm fine holding off on publishing this so we can combine a few breaking changes. I don't see this PR as too high of a priority.

[johanblumenberg]

Any plans on merging this one?

[chadlwilson]

@johanblumenberg is there a particular issue you were trying to address?

More widely, Maven 3.8 is EOL now and will get no patches for security or otherwise, so that's food for thought in only supporting secure defaults, especially with supply chain risk increasing.

https://endoflife.date/apache-maven

Also 4.0 seems will be out soon, and I believe many plugins are being updated on their 3.8 or 3.9 compatible versions to be forward compatible so it'd be good to sort this to reduce the combinations we have to deal with.

I think we already have most of the infra already available to test using maven-invoker-plugin against multiple maven versions so I could take a look and see if there is any real difference between targeting a 3.8 or 3.9 minimum of the API.

I do agree with @aikebah that addressing the deprecated dependencies and classpath issues would probably be a good idea to do at the same time though.

[marcelstoer]

Can we add a 'breaking' GH label to get an overview of what we could add to the next major?

[jeremylong]

@marcelstoer sure - I have no problem adding a breaking label. However, that is what the exclamation point means in the conventional commit PR title.

[marcelstoer]

The label has one advantage: we may add it to issues as well (my initial intention). The idea is to find such issues when a new major is in the works.

[nhumblot]

I created a 12.2.1 milestone since none existed when I integrated a PR shortly after the 12.2.0 release.

If we want to prepare for a major version, there’s no issue with simply renaming the milestone.
However, if we want to take advantage of the major version bump by introducing additional breaking changes, do we have any specific breaking changes already identified that we should prioritize?