As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11 and adopt JPMS to better define its public APIs.
Gary On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net> wrote: > 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 > > > > >
