Get rid of maven API

[laeubi]

Currently m2e uses some maven "api" in connectors and code, especially MavenProject.

We should encapsulate these (like we did with the ArcheType API) so it is always possible to exchange the backing model, this will be especially important if we want to support maven3/4.

[HannesWell]

I don't think that is feasible to do to the full extend. AFAIK in Maven 3.x almost everything effectively is API because in pre Java-9/module-system there is now way to enforce strong encapsulation of internals.
So the question would be where to start and where to end, because actually Connectors can use anything from Maven.

[laeubi]

Connectors can't use "everything" they can only use what m2e offers them. So if we have good API facade for whats really needed there won't be a problem at all. This also has nothing to do with module-system (maven already hides some things from plugins).

[mickaelistria]

I also am unsure it's a good thing here to design and expose yet-another-API, when the target audience (m2e connectors developers) are most likely already familiar with Maven APIs.
Every layer of indirection is adding cognitive and maintenance complexity, if there is no strong need for it, I think it's better to avoid that and stick to upstream API from Maven.

[laeubi]

if there is no strong need for it

If we ever want to support more than one maven version it actually is required. Connectors are not directly affected here as these can be specific to one version of a plugin (that uses a certain maven-api version), but m2e should work without these specila mven types that are completely out of our control. They might change, or even vanish completely.

Because of this, I think all API we expose should not contain any maven types (e.g. MavenProject, MavenSession, Maven...), but one might adapt such type to a particular special type (e.g. IMavenProjectFacade > MavenProject) but should be aware it might not be possible and act accordingly.

[laeubi]

Just to collect a first place DefaultClasspathManagerDelegate.addClasspathEntries(IClasspathDescriptor, IMavenProjectFacade, int, IProgressMonitor) calls getMavenProject to get all artifacts:

m2e-core/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/DefaultClasspathManagerDelegate.java

Lines 103 to 104 in 2ca5d4b

	MavenProject mavenProject = facade.getMavenProject(monitor);
	Set<Artifact> artifacts = mavenProject.getArtifacts();

This can be replaced by having a IMavenProjectFacade#getArtifacts(IProgressMonitor) returning and IMavenArtifact that encapsulates the relevant attributes (here a GAV, a scope and a location and if it should be added to the classpath).

This will then allow us to even perform performance improvements like parallel downloads using the resolver API and makes the classpath computation independent from the maven Version/API.

[laeubi]

Another place is AbstractJavaProjectConfigurator.addProjectSourceFolders(IClasspathDescriptor, Map<String, String>, ProjectConfigurationRequest, IProgressMonitor) where the maven project is used to get the output and test output directories, something that cis already provided by the facade:

m2e-core/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/AbstractJavaProjectConfigurator.java

Lines 303 to 304 in 2ca5d4b

	IFolder classes = getFolder(project, mavenProject.getBuild().getOutputDirectory());
	IFolder testClasses = getFolder(project, mavenProject.getBuild().getTestOutputDirectory());

• org.eclipse.m2e.core.project.IMavenProjectFacade.getOutputLocation()
• org.eclipse.m2e.core.project.IMavenProjectFacade.getTestOutputLocation()