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? > Hopefully it will not cause it breaks plugin design as explained. > Whether or not Extensions are "bad" or not "maven spirit" seems a > different topic for me. > Didnt say any of both, said it was and the way to go to achieve what you want to do at plugin level against maven spirit. > 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 > >
