Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <[email protected]> a écrit :
> On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <[email protected]> > wrote: > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <[email protected]> a > écrit > > : > > > > > I do wonder whether we're conflating the real issues of exposing the > CDI > > > API (for @Typed) with the much smaller JSR330 API > > > > > > > Yes as soon as you have a different version needed by a plugin and the > api > > exposed (parent first forced - and if not forced we dont know if it > works). > > > > There's only ever been one version of the JSR 330 API because it's so small > and complete (and I'd be surprised if the jakarta.inject API is any > different...) > We probably also thought javax.annotation would never get dead annotations nor build time annotations and it just did so not sure I would bet. Size is not much an issue too, actually new API are fine but modifying existing can create a mess, in particular with proxies. Last thing is that JSR 330 is not an user API anyway since it does not define the associated behavior so at the end, while it is small, it is worth keeping maven specific API IMHO for the user facing part of our deliverables. Side note: I never wrote it wouldnt be great to reuse a standard API for our own API, I just write it is not compatible with a plugin system in general until you forbid other usages of that API which is not what we want for maven plugins IMHO. > > > > So we shouldnt leak what others can use in the API - no parent ClassRealm > > access. > > > > > > > > > > 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] > > > > > > > > > > > > > >
