I haven't proposed any real change to the classloading in this discussion afair. Extensions can currently contribute packages and artifacts and that is ok. At some point, the stock maven should only expose the maven4 api with no additional packages. THis is currently not the case as the same classloader is used for maven 3 and maven 4 plugins.
If a plugin wants to communicate with a different plugin or with an extension, it should be doable through the Session#getSessionData() which can contain any kind of object. It may also be possible through Session#getService() if the extension has a bean that implements the Service interface. If that's not sufficient, we could add an explicit way to expose additional services I suppose. My proposal is simply to reduce the scope of the DI mechanism used to the classloader of the plugin (without even scanning the parent classloader), and maybe using a tiny DI mechanism to ease maintenance and debugging. Le dim. 20 nov. 2022 à 07:59, Christoph Läubrich <m...@laeubi-soft.de> a écrit : > This does not really answer the question. Extensions are made for > extending maven(-plugins) (either on the core or the project level) so > if plugins are only ever getting maven4-api available how will it be > possible then? > > Whether or not Extensions are "bad" or not "maven spirit" seems a > different topic for me. > > Am 19.11.22 um 14:51 schrieb Romain Manni-Bucau: > > Sounds like some code needing to move to extensions more than some mojo > > interactions to me to stick to a simple and maven spirit. > > > > Le sam. 19 nov. 2022 à 13:14, Christoph Läubrich <m...@laeubi-soft.de> a > > écrit : > > > >> > That's a good question. Plugins currently don't interact. > >> > Is that really something we want ? > >> > >> At least there are several places where I wish I could "plug" into an > >> existing plugin, curently for example surefire allows some limited > >> extension using test-frameworks but this requires special configuration. > >> > >> A good example might be the "set-version" plugin, where in the context > >> of Tycho one needs to also update versions not only in the > >> pom.xml/dependency part, the current approach is we actually > >> copy/replicate what set-version does, but this obviously is far from > >> optimal. The same applies to jar-plugin (where for example BND plugin > >> requires special setup/configuration) and even the release-plugin > >> currently would be something where one needs to do special enhancement > >> that are hard to maintain and manage. > >> > >> That's why I previously mentioned in a "we have one isolated mojo" > >> scenario everything might looks easy and great, but when it comes to > >> complex setups it gets complicated fast. > >> > >> > I'd rather keep things simple if possible. They can use the Session > >> > >> I as well but the problem arises if you want to share more than a simple > >> string or integer. For example currently Tycho has a project-extension > >> and also a core-extension part and then people can configure different > >> mojos ... for sure one can put everything in one big fat jar but that's > >> really hard to manage and configure, so we have split this up into > >> smaller mojos. > >> > >> Still they need to interact (e.g. to not calculate the same stuff over > >> and over again)... this mostly works as we export some packages that are > >> kind of "tycho-api" but as one don't write all from scratch there are of > >> course other dependencies to consider. Even that works, but we always > >> see issues with classpath incompatibilities that are really hard to > >> track, e.g. if version of core-extension do not match 100% version of > >> plugin used in the pom... And i have totally no clue what would happen > >> if there is another extension also exporting the same dependency ... > >> > >> > >> Am 19.11.22 um 09:37 schrieb Guillaume Nodet: > >>> Requiring OSGi for anything user facing in maven is a no-go for me. > >>> > >>> Le sam. 19 nov. 2022 à 05:01, Christoph Läubrich <m...@laeubi-soft.de> > a > >>> écrit : > >>> > >>>> > Dreaming: but what if not a flag, but some filter(s) for > >> "capabilities"? > >>>> > >>>> OSGi support generic capabilities/requirements model: > >>>> > https://blog.osgi.org/2015/12/using-requirements-and-capabilities.html > >>>> > >>>> Just mentioning it ... for sure we one can re-implement this (again) > in > >>>> maven as well, as a prime goal seems not to reuse existing techniques > >> ;-) > >>>> > >>> > >>> I've been working full time on OSGi for 10 years or so. So I'm quite > >> aware > >>> of the benefits... and the costs. > >>> I don't think we need maven to provide any choice here. > >>> > >>> > >>>> > >>>> With all this perfect "only m4api" world I'm just wondering how will > >>>> this work together with extensions (either core or project ones) and > how > >>>> is it supposed to allow different plugins to interact? > >>>> > >>> > >>> That's a good question. Plugins currently don't interact. Is that > really > >>> something we want ? > >>> I'd rather keep things simple if possible. They can use the Session > >>> > >>> > >>>> Am 18.11.22 um 19:10 schrieb Tamás Cservenák: > >>>>> 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"). > >>>> > >>>> Sounds good to me. > >>> > >>> > >>>>> 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). > >>>> > >>>> Not sure there's any benefit. If we use a custom package for a few DI > >>> annotation, > >>> there will be no conflict, so if there's no maven component defined, > >>> nothing will be done > >>> and the plugin is still free to use its own DI if it needs. > >>> > >>> > >>>>> === > >>>>> > >>>>> 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 :) > >>>> > >>> > >>> Simple is good. > >>> > >>> Not touching maven 3 plugins or they way they are loaded at all, I'd > >>> propose: > >>> * define a few annotations in org.apache.maven.api.di package, we > >> really > >>> don't need many, maybe just @Inject, @Bean > >>> * make sure the plugin classloader does only expose the api to > maven > >>> plugins > >>> * write a simplistic DI framework > >>> * make sure plugin can use a different DI framework if they need > >>> > >>> Guillaume > >>> > >>>> 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 > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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
