Le mer. 16 nov. 2022, 10:20, Konrad Windszus <k...@apache.org> a écrit :
> Hi, > Unfortunately Maven 3 didn’t define a proper API. In effect everything > somehow exposed through class loaders was considered API by > plugin/extension developers. > For Maven 4 a completely separate API was established in package > “org.apache.maven.api”, but what about the old packages used and exported > in Maven 3? > > For example in the context of > https://issues.apache.org/jira/browse/MNG-7588 < > https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the > package “org.apache.maven.plugin.descriptor”. > We already figured out that this particular package (although not part of > the Maven 4 API) is used from both Maven Core as well as Maven Plugin > Tools, therefore this probably needs to stay backwards compatible. > What about others like > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java? > < > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java > ?> > This interface should IMHO never been implemented outside Maven Core but > in fact it was exposed to all plugins/extensions (via > https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40 > < > https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40 > >). > > There are three options coming to my mind: > > 1. Deprecate the interfaces we don’t consider API and create new ones for > Maven 4 which are not exported! > I think that's the way to go. We'd also need to deprecate a bunch of jars and in maven-shared like m-artifact-transfer, maven-dependency-tree etc... One of the goal is also to completely hide the resolver. 2. Modify the existing interfaces in a backwards compatible way (but > somehow add a marker that they should not be implemented outside core) > 3. Modify the existing interfaces in a backwards compatible way (but > somehow add a marker that they should not be implemented outside core) > > For all three options we somehow need to come up with a list of > classes/interfaces currently being exported through the API class loader, > which should be considered private and agree on an Annotation/Javadoc for > that (something like > https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29 > < > https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29> > or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution < > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution> > > WDYT? > > Konrad > >
