And what about shared libraries?  they can be used by plugins or even
externally.
Sylwester

pt., 20 maj 2022, 19:15 użytkownik Romain Manni-Bucau <[email protected]>
napisał:

> It is quite simple:
>
> Maven plugin: maven API or plexus annotations are preferred
> Maven core: JSR 330 is out internal API for IoC lookups/injections
>
> 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 ven. 20 mai 2022 à 18:08, Slawomir Jaranowski <[email protected]>
> a
> écrit :
>
> > Hi,
> >
> > I'm a little confused - what should be conclusions from this discussion?
> >
> > I asked about using JSR330 with maven components like MavenProject,
> > MavenSession ... in plugin Mojo code.
> > But I see discussion about using JSR330 at general in Maven plugins
> >
> > Currently we widely use  JSR330 in core Maven plugins as replacement for
> > plexus annotations.
> >
> > Can anybody else summarize it? ... Maybe I wrong understood this
> > discussion.
> >
> >
> > śr., 18 maj 2022 o 16:07 Romain Manni-Bucau <[email protected]>
> > napisał(a):
> >
> > > 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]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>

Reply via email to