You misunderstood me. I wasn't thinking about changing the way the classloader is built, just the way the dependency injection mechanism is done for plugins (and/or maven-core).
Le ven. 18 nov. 2022 à 18:35, Tamás Cservenák <ta...@cservenak.net> a écrit : > Howdy, > > Am -1 on this. We just reached the point to (somewhat) undo the "Maven > downloads the whole world", at least latest plugins by putting Maven and > friends in provided scope will not download dozens of versions of > maven-core and friends... If we do this, at one point we would end up with > plugins downloading dozens of DI container (or their versions), as even ASF > plugins would not be in "lockstep". > > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag that > would say maven "I will be in charge of my components" (defaults to false, > Maven behaves as today). When true, it would mean Mojo wants to > bootstrap some DI/whatever container of its own, and then, for plugins like > these, Maven could even "narrow" the list of exported classes? (like > javax.inject?) > > T > > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gno...@apache.org> wrote: > > > Following up on my previous response, and in a more realistic way than > > switching to OSGi, I wonder if we should let maven 4 plugins do their own > > DI injection and only care about the mojos, i.e. not rely on sisu/plexus > to > > create and inject the mojo. Mojos using the v4 api do not need to be > > injected with other components from maven, they should all come from the > > api and should be retrieved using Session.getService(xx), or simply using > > session's shortcut methods. The injection of Project and Session is not > > controlled by sisu. For the ComponentConfigurator, we could change the > mojo > > descriptor to have the full configuration class name for mojos that > require > > custom configuration injection, the plugin manager being in charge of > > instantiating this class and using it as a ComponentConfigurator (which > is > > not part yet of the api btw). > > > > Complex plugins which rely on plexus/sisu to do some custom injection > would > > have to be changed to do their own DI, maybe using a simple Guice setup. > > > > If that sounds like too big a change for those plugins, we may be able to > > add a flag on the mojo descriptor so that those v4-enabled mojos would > > trigger a DI injection on behalf of the plugin. But if we have to > > implement something like that, I would go for a plain CDI-like api, > either > > using guice or another DI library supporting the javax.inject package, or > > rather the jakarta.inject package, as it would be nice to switch to the > > jakarta version at the same time. Or maybe even plexus if we really need > > to, but with a limited scope, i.e. no visibility on the maven components, > > so that plugins are better decoupled from maven-core. > > > > Thoughts ? > > > > Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gno...@apache.org> a > écrit > > : > > > > > 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 > > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > > -- ------------------------ Guillaume Nodet
