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 > >
