Le ven. 18 nov. 2022 à 08:57, Christoph Läubrich <m...@laeubi-soft.de> a écrit :
> > I fully understand the "under the hood" idea but once again, > > classrealm usage in maven is a tree which is very close to a flat > > classpath behavior whereas OSGi is a graph requiring all libs to have > > metadata - > > This is no longer be the case with OSGi connect. A connect framework can > install bundles that have a custom classloader (in contrast to an OSGi > managed one) that can use whatever classloader model you want (including > class realms), Tycho uses this to shaddow current realms inside an > embedded framework. > connect is to run code aside OSGi and integrates with OSGi. Thread is not about a bridge. So I agree with you OSGi has great solutions but I fail to see how it can fit maven ecosystem in any way. > > So in a simplified case you can take the "plugin realm" as a > classlaoder, and use the groupid:artifactid:version as bundle symbolic > name and you have converted a traditional maven-plugin into a > connect-bundle. Neither the OSGi will notice that nor the maven-plugin > will ... just that now it possibly *could* access the OSGi framework if > desired, and one can allow that if a maven-plugin actually is a bundle > you do simply install it as such and do not shaddow that by a > connect-bundle. > Ok, what did you gain compared to what we have today? But you lost the simplicity and the standard testing until you just rely on IT even for mojo just creating a folder, dont think it is that great. > > > and making it accessible means enabling mojo or > > extensions to reload bundle so break others > > Well I currently can easily break "others" as well, I think a maven > build was never meant as a secured sand-box where nothing bad can happen > if you like so ... but as said, OSGi is flexible even to that point that > you can "shield" others, e.g. in embedded environments it is common that > a "consumer" bundle can not do everything but only certain well defined > actions, e.g you can even prevent it from doing "bad stuff" or things > you think should be forbidden (e.g. resister maven-core services) ... > something that currently you cannot really prevent, as plexus has no way > for such fine grained control, it will just load whatever it finds in > the linear classpath. > Not in the same way, the tree structure is really more reliable because it is not as dynamic as OSGi can be so no surprise. > > > > Indeed OSGi is done to be dynamic but it requires all the code > > to be - which is where random testing must happen and from what > > you answer you just dont test that so your deployment is random > > and can get concurrencies issues, > > We probably have a different understanding about "randomness", nothing > in OSGi is random ... and concurrency is not a concern of OSGi itself > but of any java application. That's why maven has 'isThreadsafe' > annotations ... what actually means nothing than getting a strange > warning most users have no clue at. > Ok, not random but not deterministic. OSGi start can never be replayed even if you relaunch it after dumps because it is fully depending on timing issues and assumes all the code relies on listeners which is not the case of 10% of the stack - even aries and karaf have issues to catch up as soon as you need to integrate 3rd parties. > > So from maven POV if you taken maven cli and say it starts the framework > and publish the core services then starts the plugin bundles and then > executes the maven life-cycle, it is completely static, nothing will > change "random" and concurrency will just work on the java level as it > works today! And if you are using a DI framework like DS you even have > not to worry about if something would change (again here, nothing > changes random) dynamically, what at laest from my POV I would not see > as something even usefull in context of maven (e.g. no one will install > a new bundle on the fly while the maven build is running...) > This is true if you don't use OSGi for this code as explained before there so why adding it? > > > Anyway, if we try to be concrete on your proposal: do you propose to > > do the work for maven-core, testing and all mojos? > > If there is enough interest I defiantly can help with that, the > mentioned JIRA issue already includes some remarks and possible > implementation paths, but of course it is a bit too much to came up with > a code-proposal if no one likes to really take it into consideration > because one thinks its "wrong" (for whatever reason). > > If one likes to can take a look at what Tycho does with its > sisu-osgi-connect[1] or more specifically where it maps realms to > connect bundles [2], the code is just a bit more complex than necessary > because it need to recover all data after-the-fact because maven (or > plexus?) obviously do not expose those internals in an extender-friendly > way :-) > > Also note that in sisu-osgi-connect even multiple frameworks can / will > be started (one for each plugin realm) so even that is possible if one > want to separate things even more and "shield" different actors. > If it comes with a full transparent and complete stack (api, dev, packaging, testing) and user does not have to see OSGi (bnd) I have to admit I don't care much what we use until it makes the distro of maven and the mojo fatter but have to also admit technically it will likely always surface - we did the exercise on other projects multiple times - until you don't rely on OSGi (connect) and therefore do not need to do that investment at all. So don't get my doubts as a "no" but more as a high level expectations in terms of results. > > > [1] > > https://github.com/eclipse-tycho/tycho/tree/master/sisu-osgi/sisu-osgi-connect/src/main/java/org/eclipse/sisu/osgi/connect > [2] > > https://github.com/eclipse-tycho/tycho/blob/master/sisu-osgi/sisu-osgi-connect/src/main/java/org/eclipse/sisu/osgi/connect/PlexusModuleConnector.java#L107 > > > Am 18.11.22 um 08:19 schrieb Romain Manni-Bucau: > > I fully understand the "under the hood" idea but once again, classrealm > > usage in maven is a tree which is very close to a flat classpath behavior > > whereas OSGi is a graph requiring all libs to have metadata - none have > > correct one as of today - and making it accessible means enabling mojo or > > extensions to reload bundle so break others not using a full OSGi > mecanism > > (listeners). Indeed OSGi is done to be dynamic but it requires all the > code > > to be - which is where random testing must happen and from what you > answer > > you just dont test that so your deployment is random and can get > > concurrencies issues, thing I'd like to avoid for maven core but more > > particular for end users who will probably never understand why the > import > > was not resolved or why a dependency is missing being in libs/system. > > Anyway, if we try to be concrete on your proposal: do you propose to do > the > > work for maven-core, testing and all mojos? > > > > > > Le ven. 18 nov. 2022 à 06:57, Christoph Läubrich <m...@laeubi-soft.de> a > > écrit : > > > >> > A new more modern spec was created because existing one(s) was not > >> > sufficient. > >> > >> DS is still widely used and much more lightweight, CDI is not > >> "superseeding" DS, beside that you can use CDI if you think it fits you > >> more, you can even use Blueprint if you more like "spring-xml" or any > >> other famous technique that might came up without the need for maven to > >> change a single line of code or any other plugin. > >> > >> The question just was "isn't it too complex" and I showed that there are > >> techniques that completely hide that and even are close to what people > >> know of today. Still this do not limit us to what was shown. > >> > >> > In IT you can always make everything working but does it help > >> > the ecosystem or users? > >> > >> At least it would help the most common pitfalls when it comes to more > >> than a simple mojo. Ans especially if it comes to API evolution and > >> alike like core-extensions versus project extensions ... > >> > >> > The defined lifecycle of OSGi is for a system with no linear > lifecycle > >> > but maven has one and this is what people tend to understand > >> > >> As said this is nothing where you have to choose one over the other its > >> even unclear to me what "the maven lifcycle" refers to? Maven CLI? How > >> many people can really explain/understand how it works with all the > >> setup of the realms and a like? > >> > >> > >> > (one reason no ee lib is really osgi friendly if you look closer) > >> > so the issue is not osgi -i like this system - but its people target > >> > for a build system I think. > >> > >> OSGi is a specification, and you can use as much (or less) as you desire > >> and with OSGi-Connect you can mix this with whatever you like, even JPMS > >> can be modeled as OSGi (see Felix Atomos). > >> > >> > Agree we can enhance maven but yout point about osgi is to not test > it > >> > (you forgot all the cases of this random lifecycle to cite just a > >> > trivial pitfall). > >> > >> I really don't get the point about "random lifecycle", there is nothing > >> "random" in OSGi (as it would be devastating in any software if it where > >> behaving random). > >> > >> > At least maven does not have that kind of issues and does not > >> > need to document the best you can fo is either not test or > >> > use some kind of chaos testing. > >> > >> Same here, in > 10 years of OSGi I never used "chaos testing" (what ever > >> that means), of course it always depend how testable you write your > >> code... and wasn't there recently a thread on the ML about the "chaos" > >> in Maven? Maven Invoker, vs Verifier, Maven-plugin-test requiring > >> discouraged maven-compat and then there are "more alternative > >> approaches" so I think maven is still far a way from been all > >> green-grasses and sunshine... > >> > >> Also please carefully read what was written in the Jira issue (and on > >> this thread), I never suggested to "trow all away and let people use > >> OSGi), the suggestion was to use OSGI under the hood to replace the > >> (hard to manage) realm concept for API handling, make it accessible to > >> the ones who likes to use it... > >> > >> > >> > >> Am 17.11.22 um 21:28 schrieb Romain Manni-Bucau: > >>> Le jeu. 17 nov. 2022 à 20:25, Christoph Läubrich <m...@laeubi-soft.de> > a > >>> écrit : > >>> > >>>> The great thing is that DS is not an "API" you use, it is just a > >>>> convenient way to express what you provide and what you need, so you > >>>> will never have any runtime dependency and thus can always choose > >>>> another, you can even code all this "by hand" ... anyways I never > heard > >>>> it is "superseeded" or "legacy" do you have any normative statement > >>>> about that? > >>>> > >>> > >>> A new more modern spec was created because existing one(s) was not > >>> sufficient. > >>> Phrase it as you want but DS is no more a default choice as of today > and > >> if > >>> you get back to the topic it is far to cover maven need. > >>> > >>> > >>> > >>>> > maven has a well defined lifecycle whereas OSGi wants to be ultra > >>>> dynamic > >>>> > >>>> OSGi can be used in a dynamic way but still has "well defined > lifecycle" > >>>> and you are not forced to use the dynamics. and you can define the > >>>> maven-lifecycle on top of it OSGi do not mandates any specific way to > >>>> use it. e.g. Tycho embedds OSGi into maven, while m2eclipse do the > other > >>>> way round: Running in OSGi and embedding maven ... > >>>> > >>> > >>> In IT you can always make everything working but does it help the > >> ecosystem > >>> or users? > >>> The defined lifecycle of OSGi is for a system with no linear lifecycle > >> but > >>> maven has one and this is what people tend to understand (one reason no > >> ee > >>> lib is really osgi friendly if you look closer) so the issue is not > osgi > >> - > >>> i like this system - but its people target for a build system I think. > >>> > >>> > >>> > >>>> > but almost untestable without sophisticated > >>>> > solutions for enterprises apps) > >>>> > >>>> OSGi actually allows better testing (through DI and service layer), > >>>> while the official maven-plugin-test still suffers from being bound to > >>>> maven-compat and JUnit 3 .... so I can't really say testing "maven" is > >>>> really anything I would call easy ;-) > >>>> > >>> > >>> Agree we can enhance maven but yout point about osgi is to not test it > >> (you > >>> forgot all the cases of this random lifecycle to cite just a trivial > >>> pitfall). At least maven does not have that kind of issues and does not > >>> need to document the best you can fo is either not test or use some > kind > >> of > >>> chaos testing. > >>> > >>> > >>> > >>>> > we should just stick to the excellent work Guillaume did and keep > >>>> > decoupling our internal impls/deps from the exposed API we should > >>>> > keep control now we have a real API we lacked for years. > >>>> > >>>> This work is actually nothing contradictory or "different" if one > would > >>>> use OSGi ... > >>>> > >>> > >>> Right but it is opposed to your sample using ds @Reference for ex. > >>> > >>> Anyway, guess nobody will spend time on making it so no need to discuss > >> it > >>> much, no? > >>> > >>> > >>>> > >>>> Am 17.11.22 um 19:58 schrieb Romain Manni-Bucau: > >>>>> Le jeu. 17 nov. 2022 à 19:23, Christoph Läubrich < > m...@laeubi-soft.de> > >> a > >>>>> écrit : > >>>>> > >>>>>> For OSGi there is a DI framework name "Declarative Services", that > is > >>>>>> (from users POV) not any "complex" or different than Plexus, e.g a > >> Mojo > >>>>>> might simply look like: > >>>>>> > >>>>>> @Component > >>>>>> MyMojo implements Mojo { > >>>>>> > >>>>>> @Reference > >>>>>> Logger logger; > >>>>>> > >>>>>> @Overide > >>>>>> void execute() { > >>>>>> ... do it ! ... > >>>>>> } > >>>>>> } > >>>>>> > >>>>>> for the rest, you simply has a maven plugin that generates all the > >> rest > >>>>>> for you ... so very similar to what we have today, but with much > more > >>>>>> flexibility (not shown here as not required for most cases). > >>>>>> > >>>>>> And for the "breakage", as outlined in the linked issue [1], Tycho > >>>>>> already use a Maven <-> OSGi bridge, so actually one can even > combine > >>>>>> both "worlds" ... > >>>>>> > >>>>> > >>>>> We saw multiple times by the past we shouldn't expose any used API > >> cause > >>>> it > >>>>> leads to conflicts, API incompatibilities etc... so reuse DS sounds > >> like > >>>>> redoing some previous errors (we got bitten by a single annotation > from > >>>>> cdi-api.jar so imagine if we use more ;)). > >>>>> Also DS is starting to be legacy now OSGi superseeded it by OSGi-CDI > so > >>>> not > >>>>> sure it is better than going back to plexus for end users. > >>>>> Last issue is that it has a whole set of API for dynamism maven will > >> not > >>>>> get (to not make the system overcomplex and since it has no real need > >> of > >>>> it > >>>>> - maven has a well defined lifecycle whereas OSGi wants to be ultra > >>>> dynamic > >>>>> which is good for some systems but almost untestable without > >>>> sophisticated > >>>>> solutions for enterprises apps) so think we should just stick to the > >>>>> excellent work Guillaume did and keep decoupling our internal > >> impls/deps > >>>>> from the exposed API we should keep control now we have a real API we > >>>>> lacked for years. > >>>>> > >>>>> > >>>>>> > >>>>>> [1] https://issues.apache.org/jira/browse/MNG-7518 > >>>>>> > >>>>>> Am 17.11.22 um 17:48 schrieb Guillaume Nodet: > >>>>>>> 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 > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>> 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 > >
