[MRELEASE-1087] Upgrade Maven to 3.2.5 (and de-plexus)

[cstamas]

Mass changes to plugin:

• update maven 3.0 -> 3.2.5
• update resolver from org.sonatype to org.eclipse package
• off plexus XML, move fully to JSR330
• off plexus APIs like LogEnabled, Contextualize, etc
• use slf4j API for logging instead of Plexus Logger
• tests: off from Junit3 PlexusTestCase w/ XMLs to modern(er) Junit 4
• tests: off from PlexusTestCase XMLs (one exception remains)
• reformat

---

Two UTs are Ignored for now

All but two UTs pass that I cannot interpret:

maven-release/maven-release-manager/src/test/java/org/apache/maven/shared/release/versions/DefaultVersionInfoTest.java

Lines 235 to 239 in 85d973c

	if ( !"3.0".equals( mavenVersion ) )
	{
	// bug??
	checkVersionLessThanVersion( "1.01-beta-04-20051112.134500-2", "1.01-beta-04-SNAPSHOT" );
	}

https://github.com/apache/maven-release/blob/85d973c87724aa2bc0698e6773dd9ce2a0fc8701/maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/GenerateReleasePomsPhaseTest.java

Former currently does not even run (maven version != 3.0), while latter is most probably due bad diff, probably diff logic in UT needs more "no change" detection.

All IT pass OK:

[INFO] --- maven-invoker-plugin:3.2.2:verify (integration-test-prepare) @ maven-release-plugin ---
[INFO] -------------------------------------------------
[INFO] Build Summary:
[INFO]   Passed: 46, Failed: 0, Errors: 0, Skipped: 0
[INFO] -------------------------------------------------

[cstamas]

I am aware this PR is really BIG and nothing else describes it fully than vague "catch up", but we need to perform this jump, as current master is really lagging and IMHO has way too much debt than would be somewhat IMHO acceptable.

[cstamas]

There is one problem: all UT and IT pass OK except this one that is disabled (hence build is green): GenerateReleasePomsPhaseTest

I have hard time even to understand what this UT is about, and even less clues WHY it fails, seems it has to do how POM is persisted and some change probably between 3.0 and 3.2 "ways of doing it". So here I'd expect some explanation and help from @hboutemy @rfscholte and @michael-o to figure it out.

[michael-o]

Will try to go through today/tomorrow.

[hboutemy]

we need a MRELEASE Jira issue with an update of every commit message to be able to track the change in the future

[slawekjaranowski]

maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml was changed so we need change expected-*-pom.xml for UT.

[slawekjaranowski]

Probable cause of ignore tests in AbstractRewritingReleasePhaseTestCase

[cstamas]

For example, I have hard time to understand why release needs to resolve anything at all...

[slawekjaranowski]

And why we need use setDependencyArtifacts directly ...
code is also strange for me we check:

if ( project.getDependencyArtifacts() == null ) 

and next on different object

resolvedProject.setDependencyArtifacts(....)

I will check what happens if I call

resolvedProject.setResolvedArtifacts( resolvedProject.getDependencyArtifacts() )

of course I don't understand it very well

[hboutemy]

Jira issue created https://issues.apache.org/jira/browse/MRELEASE-1087

[cstamas]

I updated/fixed things reported so far, @slawekjaranowski did re-enable the failing UT GenerateReleasePomsPhaseTest (while he did disable several tests in it's parent class), but also there is that DefaultVersionInfoTest as well...

So, I'd like to see some consensus about these changes and finally make this PR merged.
But please note, that if there are some other pending PRs for upcoming release, better would be to merge those and update this PR, as am pretty sure this PR will render all existing PRs as "conflicted".

[cstamas]

Cool, thanks @slawekjaranowski !

[cstamas]

@rfscholte or @hboutemy would be good if any of you would bless this PR so we can merge. Again, as before, if there is any other PR scheduled, please merge it BEFORE this one, I will handle conflicts.

But, this PR clearly shows severe issues with m-release-p:

• why does release redo Maven CLI? (see use of commons-cli), this is obviously a duplication of logic here
• why does release resolve anything at all? Several of us have hard time to understand what is happening here

All in all, I still think what I said before: "this plugin does WAAY more than it should", and hence, is very fragile (the plugin but it's process as well).

Anyway, let's move on, and we can tinker more about these later.

[olamy]

some nit comments/question

[hboutemy]

LGTM: a good pass at cleanup that will prepare for next ones
I hope M6 will be the last milestone and we can after go to final

[michael-o]

LGTM: a good pass at cleanup that will prepare for next ones I hope M6 will be the last milestone and we can after go to final

I assume that SCM 2 will be in MRELEASE 4 only, no?

[olamy]

ship it!