Sorry for the delay. I forgot the details. We have tracked the task to detail the problems on the OpenTelemetry project: https://github.com/open-telemetry/opentelemetry-java-contrib/issues/149
I'll re-test ASAP. Cyrille On Thu, Dec 16, 2021 at 12:34 PM Tamás Cservenák <ta...@cservenak.net> wrote: > Howdy Cyrille, > > I'd love to hear more about your problems, and the limitations you have > hit. > > Thanks > Tamas > > On Thu, Dec 16, 2021 at 12:30 PM Cyrille Le Clerc > <cyrille.lecl...@elastic.co.invalid> wrote: > > > Dear Maven Community, > > > > As an infrequent Maven plugin author (Jenkins Pipeline Maven integration > > < > https://github.com/jenkinsci/pipeline-maven-plugin/tree/master/maven-spy> > > and OpenTelemetry Maven extension > > < > > > https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/maven-extension > > >), > > I can share that *it is confusing for infrequent plugin authors to have > > both @Inject and Plexus @Component with different behaviors*. > > > > For example, I tried first to implement the OpenTelemetry Maven extension > > with @Inject and faced limitations so I had to rewrite to use @Component. > > > > I would see the removal of @Inject or of @Component as an improvement > > thanks to simplification. As @Inject has limitations, it could make sense > > to deprecate it. > > > > I hope this feedback helps > > > > Cyrille > > > > > > > > > > On Mon, Dec 13, 2021 at 9:13 AM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > > > Hi all, > > > > > > Seems the fact to leak our IoC to mojo still has side effects since we > > are > > > scanned in mojos - and we can't say these mojos are not supported since > > it > > > is the whole goal of mojo to run the code users/mojo writers want > right? > > > The fact we use something official and mainstream and leak it to mojo > > > creates regularly side effects. Added to that the fact this part is not > > > really well stable and the contract not well defined accross versions > > makes > > > it hard for mojo writer to keep up with. > > > > > > Overall my proposal would be to drop any mainstream imports from maven > > mojo > > > leakgae - we don't care of maven core - it concerns javax/jakarta, can > be > > > slf4j, etc... > > > > > > The javax one is very impacting for 3.x so I think we should target any > > > future release, the other (slf4j) can be cleaned up for v4 I guess > since > > > right now it works by "luck" and can need a longer fix where our > > classreal > > > checks where is the binding - if in the app don't use maven, if in > maven, > > > use maven one and skip slf4j-api, in other words it requires an > > integration > > > for mojo of the libs we provide when used as libs but risk to still > break > > > or have side effects is not that low. > > > > > > Wdyt? How do we plan to get back to a stack which is not interferring > > with > > > mojo code as it almost was in maven 3.3? > > > > > > > > > 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 > > > > > > > > > > > > > -- > > Cyrille Le Clerc > > Product Management Director, Observability > > Paris, France > > > -- Cyrille Le Clerc Product Management Director, Observability Paris, France
