Unsure we want to deprecate all of Maven :) But yes, in general, 3.x "Maven API" was "all that users can grab" sadly, and is probably our major source of problems and reason we started Maven 4 API.
IMO, I'd consider them as "whole", and just say "starting with Maven 4.100/5.0/whatever" the maven-core (any class out of it) is NOT ACCESSIBLE ANYMORE FROM PLUGINS. And done. Just as an example, here is what Maven Resolver has to say about same topic (part of not-yet-released, vote is in process 1.9.1 version): https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html HTH T On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <k...@apache.org> wrote: > I see now there is already > https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java > but to me the javadoc is not explicit enough. It should state: Only Maven > is allowed to implement/extend types with this annotation. > > Konrad > > On 2022/11/16 09:20:11 Konrad Windszus wrote: > > 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! > > 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
