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

Reply via email to