Hi, after following the discussion, i still have no idea how to maintain a core-extension that needs to run on both maven 3 and 4. Could anyone plz give some suggestions?
On Fri, Nov 18, 2022 at 4:20 PM Guillaume Nodet <[email protected]> wrote: > Le mer. 16 nov. 2022, 10:20, Konrad Windszus <[email protected]> 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 > > > > >
