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 >
