Upgrade Maven api to 3.2.5 - drop support for Maven 2.x

[slawekjaranowski]

To change - new way

• resolving artifacts
• resolving and manage repository meta-data
• resolving archetypes

[andrzejj0]

I can do that.

[slawekjaranowski]

I can do that.

Great - please try step by step

[andrzejj0]

Had a look.

Currently the project uses old-ish components (metadata and artifact resolver and not Maven Resolver etc) in its API - in the FactoryHelper interface. To be honest, I would put this interface in some "utils" module as I don't really see why it would be part of the API. But, if we want to keep this API unchanged, then there's no way to completely get rid of those old components.

Should we change this API? Or deprecate it? Personally, I think I would probably retire (i.e. stop using it in the plugin), and deprecate it.

There's no Maven Compat at all anymore.

[slawekjaranowski]

mrm-api - module looks like internal API for plugin, it contains implementations and so on ...
I we can break it, we can release next major version after Maven 2.x api will be removed and will be clear

[andrzejj0]

So far, the plugin is small, but it's a bit more intertwined than Versions or Enforcer. So, for the time being I'm going for the big bang, later on I may introduce gradual changes when I have it more or less done.

[andrzejj0]

for stage 2: https://issues.apache.org/jira/browse/MNG-7548

[andrzejj0]

@slawekjaranowski do you know if maven-artifact-manager is also to be replaced? (it provides a DefaultRepositoryMetadataManager and can be an alternative to maven-compat)

[andrzejj0]

If that is the case then this ticket can be resolved by #144 alone.

[slachiewicz]

@ajarmoniuk what left here to do?

[andrzejj0]

Right. I have no idea why I stopped with this.

archetype-common needs to be bumped.

Looking into it.

Old version of archetype-common brings in the old maven-artifact-manager as a transitive dependency and it's the Maven 2.0 cruft that we're using directly and needs to be get rid of.

[cstamas]

While investigating regarding this issue (unrelatd to this plugin) https://issues.apache.org/jira/browse/MNG-7705 I arrived here and found this: https://github.com/mojohaus/mrm/blob/master/mrm-maven-plugin/src/main/java/org/codehaus/mojo/mrm/plugin/DefaultFactoryHelper.java#L9

This is what "true legacy" means: this plugin completely circumvents resolver, and locking... it aged as a good milk 😄

[andrzejj0]

Howdy @cstamas

Yes, it's been there indeed and I didn't remove it. Should we rather use https://maven.apache.org/resolver/maven-resolver-api/apidocs/org/eclipse/aether/metadata/package-summary.html from Maven Resolver?

[cstamas]

The truth is, I am not quite knowledgeable what this plugin tries to do, BUT if it attempts to mimic remote repository, why would I choose this plugin over to fire up some HTTP server in my tests?

My point is: with plain HTTP sever you are in full control, moreover, is easy to check and validate what is being served to Maven (as HTTP Server would really just deliver laid down files via HTTP), while with even one breadcrumb of logic on "server side", you just complicate things, make them error prone and bug prone, and the worse way: the user of plugin wonders why it does not work, while the problem is on "server side", not in user plugin that is being tested.