Now imports. But somewhat "named capabilities". Most of the plugins (vast majority) would use the default of "*" (give me whatever you have).
If I look at this file: https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/maven/extension.xml I see "capabilities" like: - m4 api - m3 api x - wagon x? - resolver x - classworlds x? - plexus-xml x? <- Guillaume? - plexus-container x - jsr330 - jsr250 - slf4j - jansi Note: in some future maven 4.5/5/whatever entries marked with "x" are gone. Those with "?" capabilities are unsure if I am right or not (that will be gone), Guillaume will chime in hopefully. The vast majority of plugins will not bother with these settings at all (will have default value of "*"). Some may want to tune it, like not having jsr330 or slf4j, or purist plugins may ask only for "m4api". Point is (whether enum or not) is: if a plugin asks for capability that maven runtime does not have (for example m3api in maven 5) -> leads to breakage. === BUT, I said this would be a "dream" :) Do not stick to it. Am completely fine with a flag as I described before. T On Fri, Nov 18, 2022 at 7:36 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Guess if you start to enable imports of components outside the API all the > API work done for m4 disappear and you get back in current state, ie a mojo > is not able to know what it can rely on from maven until we create an enum > and it would be we put jsr330 (note this one does not mean much since the > injected type will be the most important), slf4j are part of the API and we > said we don't want that - for goods so sounds like we should stick to the > API respect IMHO and if needed promote some new API, 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 ven. 18 nov. 2022 à 19:11, Tamás Cservenák <ta...@cservenak.net> a > écrit : > > > Howdy, > > > > just to describe a bit what I meant under "reversed flag": > > > > default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as today. > > Plugin classrealm gets (from memory, might be incomplete or wrong): > > - m4 API > > - m3 "plugin-api" > > - javax.inject > > - resolver api > > - etc as today > > > > consider that MANY plugins have components, and creating components in > > MAJORITY of plugins is easy and should remain easy (and offered "out of > the > > box"). > > > > but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin realm > > that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the > > plugin can do whatever it wants, but still has access to m4 API (that is > > heaven vs earth when compared to m3 state of affairs). > > > > === > > > > in future, when we drop m3 support, this could mean: > > > > false (default) > > - m4 API > > - javax.inject > > > > true > > -m4 API > > > > === > > > > Dreaming: but what if not a flag, but some filter(s) for "capabilities"? > > values: > > - * <- plugin classrealm should have all "capabilities" current Maven > > runtime provides > > - m4api <- I want maven 4 api ONLY > > - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that > drops > > m3 backward compat), slf4j logging and would use jsr330 components > > "capability" > > > > But this is getting too wild maybe :) > > > > > > T > > > > On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net> > > wrote: > > > > > 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 > > >> > > > > > >
