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 <[email protected]> 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 <[email protected]> > 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 >
