I have used SLF4J and JSR330 in plugins for years without issue. They all still work and nothing has mysteriously stopped working even made 7+ years ago. I honestly don’t see much point in making our own annotations, and I’ve not encountered any of the issues Romain presents.
To Romain’s points: 1. I don’t see it as an issue that two entirely different universes of classes don’t work 100% in the same classloader. Just fork and use a separate process as these two universes were never meant to actually run in the same classloader. They don’t run that way in production so why would you try doing that during a build or testing. 2. I don’t think that’s an issue, if we wanted to augment what we do with another CI spec we can with Sisu. I think any of the standard CI specifications provide everything we might potentially need. We may not use them now, but Sisu would allow us to use which ever spec we wished, in whatever combination we wish. Stuart, correct me if I’m wrong. 3. It’s been fine for how many years? Sisu is our defense here, it can look at annotation A or B and provide the same behavior for the user. I’m sure Stuart can show us how to get javax.inject and jakarta.inject working simultaneously for a co-existence and/or transition. Again Stuart, correct me if I’m wrong. Jason > On May 16, 2022, at 1:14 PM, Slawomir Jaranowski <[email protected]> > wrote: > > But from other side we can use JSR-330 in Mojo [1] > > so we will: > > @Parameter( defaultValue = "${project}", readonly = true, required = > true ) > private MavenProject project; > > @Inject > public SuperMojo( Jsr330Component component ) > { > } > > From code perspective will be clear > > @Inject > public SuperMojo( MavenProject project, Jsr330Component component ) > { > } > > > [1] https://maven.apache.org/maven-jsr330.html > > pon., 16 maj 2022 o 18:42 Romain Manni-Bucau <[email protected]> > napisał(a): > >> Hi Sławomir, >> >> This is a complex topic, basically there is a will to get a real IoC for >> maven-core and keep a maven specific API for plugin writers so I'm tempted >> to say option 1 for mojo. >> >> As a reminder the issues exposing @Inject are: >> >> 1. We can conflict with plugins (it is the case already and a lot of >> servers have to workaround that with custom classloaders) >> 2. We have no guarantee next version of @Inject will be compatible - there >> is a trend to break at jakarta EE >> 3. When we'll want to migrate to jakarta.inject (or another API) we'll >> break all consumers if it is used outside maven project itself >> >> Where this policy has its limitations is that extensions are now kind of >> "plugins" in the sense it should only use a public API but currently it has >> to use internal one (@Inject). >> So while I think option 1 is really the way to go, we probably have some >> work to extend it to extension mid-term and clean the API for maven 4. >> >> Hope it helps. >> >> 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 lun. 16 mai 2022 à 18:13, Slawomir Jaranowski <[email protected]> >> a >> écrit : >> >>> Hi, >>> >>> We can inject Maven components into plugins in many ways ... >>> >>> We can use @Parameter, like: >>> >>> @Parameter( defaultValue = "${project}", readonly = true, required = >>> true ) >>> private MavenProject project; >>> >>> @Parameter( defaultValue = "${session}", readonly = true, required = >>> true ) >>> private MavenSession session; >>> >>> @Parameter( defaultValue = "${mojoExecution}", readonly = true, >>> required = true ) >>> private MojoExecution mojoExecution; >>> >>> We can use DI with @org.apache.maven.plugins.annotations.Component >>> >>> @Component >>> private MavenProject project; >>> >>> @Component >>> private MavenSession session; >>> >>> @Component >>> private MojoExecution mojoExecution; >>> >>> >>> We can use DI with @javax.inject.Inject on fields ... >>> >>> @Inject >>> private MavenProject project; >>> >>> @Inject >>> private MavenSession session; >>> >>> @Inject >>> private MojoExecution mojoExecution; >>> >>> And DI with constructor: >>> >>> @Inject >>> public SuperMojo( MavenProject project, MavenSession session, >>> MojoExecution execution ) >>> { >>> } >>> >>> Which way should be preferred, which one to avoid? And why? >>> Can we use DI for all Maven components? >>> >>> -- >>> Sławomir Jaranowski >>> >> > > > -- > Sławomir Jaranowski A master in the art of living draws no sharp distinction between his work and his play; his labor and his leisure; his mind and his body; his education and his recreation. He hardly knows which is which. He simply pursues his vision of excellence through whatever he is doing, and leaves others to determine whether he is working or playing. To himself, he always appears to be doing both. -- François-René de Chateaubriand --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
