I do agree that debugging the provisioning side is *very* complicated when there's a problem. I'd be happy to get rid of sisu/plexus and use a more simple DI framework, at least for simple plugins. However, I definitely don't think pushing OSGi to plugins would be a good idea : the cost and burden on plugin developers would outweigh the benefits.
For extensions, and for maven itself, that is a different story though. Maven and extensions could definitely benefit from OSGi, but this would be a complete breakage and it would be hard to keep some level of compatibility. Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <m...@laeubi-soft.de> a écrit : > > Guess classrealm is fine for maven, it does not bring much issues > > As long as it works, maybe, maybe even if you write a simple maven > plugin, but for any more complex it is just a complete mess. > > Last time I asked on the mailing list how to debug that stuff ... > complete silence ... > > Today I tried to refactor the name of one module of a more complex > maven-plugin (with core extension), now I end up with > > org.apache.maven.InternalErrorException: Internal error: > com.google.inject.ProvisionException: Unable to provision, see the > following errors: > 1) No implementation for org.eclipse.aether.RepositorySystem was bound. > > A whole bunch of stack trace but not a little info why the ***** it is > not happy. Now I need to add random "exportedArtifact" / > "exportedPackage" stuff to hope finding out where it has lost a > transitive dependency, also here absolutely no documentation what this > is supposed to do/work exactly beside some introduction that these xml > tags exits and reading the code... or probably add maven-compat > anywhere... or change provided to compile scope (even maven is jelling > at me that's bad and I will be punished soon)... not counting the many > times where I messed up the realms because I accidentally trying to use > XppDom objects in extensions and plugins and something between got > messed up. > > With OSGi i get clear errors for missing requirements, I can clearly > share API (or declare I don't want to share it) and can reliable use it > without classlaoding problems. > If one wan't can even implement service filtering that would hide all > "illegal implemented API" ... and you can even make sure API is > (backward) compatible with implementation without waiting for a method > not found exception or alike. > > Beside that I find it often more clear to distinguish between API (that > is only implemented by the framework) and SPI (that might be implemented > by extenders). So probably it would be good to have maven-api and > maven-spi (instead of "maven-core") to make this clear. > > Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau: > > 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 > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
