I do wonder whether we're conflating the real issues of exposing the CDI API (for @Typed) with the much smaller JSR330 API
Does anyone have a link to an issue that specifically involved exporting the JSR330 API (I did a quick search but the threads I found were all about the CDI API) IIRC there was only one external plugin/extension that ever used @Typed, so we could easily just stop exporting the CDI API while continuing to export JSR330 (other comments inline below...) On Wed, 18 May 2022 at 10:52, Jason van Zyl <[email protected]> wrote: > 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. > Yes, supporting different annotations is one of the main features of Sisu - it doesn't force you to export a particular API (the previous decision to export JSR330 to plugins was because it was a standard, so it made it easier to share injectable components between Maven and other ecosystems without having to continually write adapters - but it's not a fundamental requirement) > 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. > There's an initial PR to add jakarta.inject support to Guice which people are working on - once that's in the changes needed in Sisu are relatively small. > 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] > >
