I don't think would OSGi actually bring much in our case. The goal is to have maven-core only export a given set of packages to the plugins, with no libraries at all. Each plugin has its own classloader only importing the v4 api from maven-core.
Le mer. 16 nov. 2022 à 13:00, Christoph Läubrich <m...@laeubi-soft.de> a écrit : > If you really like to separate API and get out of the ClassRealm-Hell > OSGi would be much more suitable: > > https://issues.apache.org/jira/browse/MNG-7518 > > Am 16.11.22 um 12:30 schrieb Gary Gregory: > > 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 > >>> > >>> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
