Yes, to define rules is quite easy, but to make our users to obey them is tricky :D
In general, I guess, we should. For this reason JapiCmp has been used in Resolver since 1.9.0 (as noted on refd page end). But while this was "kinda simple" to achieve in Resolver, I am really unsure if it is doable in Maven (sans 4 API) :( Ultimately, this was the whole reason for API: - users "grabbed" whatever could get hold on and used - maven progress was really hindered by this, as that meant modifying (even internal) interfaces without breaking clients was impossible, so we went with tricks, and more tricks and even more tricks that now pays back. The other day we had a question on ML about 4-alpha compatibility breakage, and from mail it was clear that the package of the referred class was having "internal" in it. I mean, developers should really take care of what they import. This is another huge plus for Takari lifecycle, it FORBIDS compilation against "encapsulated" internal classes.... http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation T On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <k...@apache.org> wrote: > I guess this is the easy part, the tricky question remains: Do we need to > make sure that all Maven 3 API interfaces/classes stay 100% backwards > compatible until we reach 4.100/5.0/whatever? > > This wasn't handled consistently in master till now, e.g. the classes > generated from > https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo > are now immutable, i.e. lack setter methods in Maven 4. > My change in > https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77 > was not backwards compatible (removed a method on an interface which may > have been implemented by extensions...) > > Konrad > > On 2022/11/16 09:35:15 Tamás Cservenák wrote: > > 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 > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
