Le lun. 16 mai 2022 à 19:14, Slawomir Jaranowski <[email protected]> a
écrit :
> 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 )
> {
> }
>
We can but we just leaked an internal so guess it is not what we must
encourage and if we speak about mojo validation layer it should fail with
an error IMHO.
>
>
> [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
>
