Le 2024-07-23 à 01 h 15, Guillaume Nodet a écrit :
Awesome work ! Does ECJ implement javax.tools API too ?
Thanks! I did not tested the Eclipse compiler, but from my search on
internet, I got the impression that yes it implements the javax.tools
API too. If not the case, it should be possible to create a wrapper.
The org.eclipse.aether.graph.Dependency objects should not be used and
will not even be exposed once/if [1] is merged. One of the goals of
the Maven 4 API was to hide the resolver completely, so I'm not sure
how to not wrap those. But if you have some suggestions...
Maybe, after Aether became completely hidden from users point of view,
copy the code to the Maven core module (as internal packages), then
delete Aether interfaces one-by-one by replacing them by their Maven API
equivalent? But we can keep that work for later.
For this particular point, there are really only two implementations
of org.apache.maven.api.DependencyCoordinate which are
org.apache.maven.internal.impl.DefaultDependencyCoordinate and the
anonymous class defined in
org.apache.maven.internal.impl.DefaultProject, which wraps a
org.apache.maven.api.model.Dependency. Both should have the getType()
return a correct value, so passing null to the
org.eclipse.aether.artifact.DefaultArtifact constructor [2] definitely
looks like a bug.
Actually `getType()` returns the correct value, but that value is not
given to the Aether object. It is decomposed in two strings: the
classifier and the file extension. The file extension is "jar", which is
maybe the reason why "test-jar" become confused as "jar" type, and the
classifier is "" (empty string). I suspect that the issue is with the
latter, which should probably be "tests". I will try this weekend to
modify the implementation so that if
`DependencyCoordinate.getClassifier()` is "", then
`DependencyCoordinate.getType().getClassifier()` is used as a fallback.
Martin
