[SUREFIRE-1628] fix compatibility with maven 3.0.5

[joergsesterhenn]

As advised by @rfscholte and suggested by @Tibor17 I created this pull request to fix compatibility with maven 3.0.5 by replacing injection of LocationManager with instantiation.

[Tibor17]

Have you tried to install (i.e. mvn install -DskipTests) this patch in your local repo? How does it work for you (i.e. mvn -nsu test on your own project)?

[eolivelli]

I am not sure this is the right fix.
You are bypassing dependency injection.

Why do you want this plugin to be compatible with obsolete Maven 3.0.5 ?
Can't you use a previous version ?

[Tibor17]

@rfscholte
Do you expect any injection points in the class LocationManager (plexus-java)?
In the future?
Should it be a plain POJO?
Should it be a bean?

[Tibor17]

@eolivelli
Robert mentioned this option of instantiating this LocationManager instead of injecting it.
If Robert guarantees that future versions wouldn't use injections in the class LocationManager then we are on the safe side.

[rfscholte]

I won't guarantee anything. Having it available as a bean gives me the freedom to inject other beans. So far there hasn't been a reason to do so.
I would suggest to try and get the LocationManager as bean. If it is null, create one yourself via the constructor. Once surefire requires Maven 3.1, you can drop the null-check.

[Tibor17]

@eolivelli
@rfscholte
Do you think that it helps if we generate component.xml via plexus-component-metadata:generate-metadata in Maven 3.0.5? If we do not use JSR-330 in the MOJO, and we use Component annotation then this can be fixed by generating the component.xml. WDYT?

[michael-o]

I'd go the simplest route: require 3.1 for Surefire 3.x
@joergsesterhenn Do you rely on Maven 3.0.x?

[joergsesterhenn]

We do currently. Would have been nice to see this working in 3.0.5. If this is a big issue please see to it that at least the compatibility level is documented and implemented correctly for surefire. And maybe announce 3.0.5 as EOL. TIA Jörg Michael Osipov <notifications@github.com> schrieb am Mo., 6. Apr. 2020, 14:02:

…

I'd go the simplest route: require 3.1 for Surefire 3.x @joergsesterhenn <https://github.com/joergsesterhenn> Do you rely on Maven 3.0.x? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#274 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHN6SS7DXKKATPTGYCZMLDRLHAF3ANCNFSM4LDAVNEQ> .

[eolivelli]

Don't know sorry.

[Tibor17]

Unfortunately the Maven 3.0.x is not EOF yet, see the history:
http://maven.apache.org/docs/history.html

[michael-o]

Unfortunately the Maven 3.0.x is not EOF yet, see the history:
http://maven.apache.org/docs/history.html

This is one of our serious problems I have raised on dev@ some months ago. We have no please policy how long something is support officially or at best effort. 7 years old release are more than enough.

@joergsesterhenn Can you tell why you still rely on it? Old product?

[Tibor17]

@joergsesterhenn
I have checked the code. Surefire does not generate components.xml using plexus-component-metadata. Pls rewrite the commit to generate this metadata file. I hope this would be the fix.

[Tibor17]

I think the injection point should be moved from SurefireMojo to SurefirePlugin and IntegrationTestMojo. Try to add it in the POM in maven-surefire-common , and if it does not work then it would mean that you have to move it directly to the module of every MOJO class. Let's see what will happen...

[Tibor17]

@michael-o
Let's post this on @dev and require deprecating the MVN 3.0.x.
We have couple of reasons (JSR330, component injection) why it should be deprecated version.

[mosabua]

Totally agree with deprecating 3.0 .. in fact I would deprecate 3.1 and probably 3.2 as well

[Tibor17]

@mosabua
yes, I would doo it too, even 3.3.x as well. We have updated all plugins to 3.0 and it was not easy job. IMO doing it with 3.1 would be as simple as updating the dependencies only and much easier than before. If we would do it systemematically, we would deprecate also 3.2, I am sure.

[elharo]

There's at least one plugin still back in 2.x somewhere, I forget which.

Updating from 3.0 to 3.1 is not simple in most cases. So far I've found one plugin where it was a one-liner. Usually it requires major work on the integration tests.

[Tibor17]

@elharo
Right, but here we can take the easier path. i.e. to update the documentation as a starting point and wait for deprecating the Maven 3.0.x on Maven pages.
IMO the real fix for this issue would be simple. So I am not strictly against the fix either.

[slawekjaranowski]

Maven 3.0.x is EOL
https://maven.apache.org/docs/history.html#maven-3-0-x

[Tibor17]

Closing due to the project is currently based on Maven API 3.2.x.