Hi, Guess classrealm is fine for maven, it does not bring much issues (less than OSGi or JPMS to be concrete), the real issue is the stability of the exposed API. Thanks the hard work Guillaume did on that for maven 4 I guess it is mainly a matter of deciding what we do for maven 3. Due to the resources and work needed I assume we can just play the status-quo for maven 3. Remaining question is for maven 4 do we drop the compatibilty. I don't like much the idea but a compat layer can solve that smoothly for maven >= 4 and limit the work needed, no?
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> 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 > >
