Hi Stuart,

Not really, they relate to cdi or atinject spec and explain why we must not
expose it to plugins - and more generally how exposing standard or
mainstream API does not reach our isolation goal for plugins.
Concretely our maven-core extension.xml file should not list any
javax/jakarta package and probably not widely used API (mentionned slf4j)
too, this is a general rule if we want to keep our plugin mecanism sane and
working for most people and in time.

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 jeu. 2 juin 2022 à 10:51, Stuart McCulloch <[email protected]> a écrit :

> Thanks - afaict those all relate to the CDI API which was previously only
> added so people could use the @Typed annotation during early migration away
> from Plexus specifics (this is not required by the container, it's an
> optional dependency)
>
> As mentioned before I only know of one external extension that was still
> using the @Typed annotation for one of its components, and it would be
> possible to alter that extension to not need that (if anyone still even
> uses it) - so it would be fine to remove the CDI API dependency from Maven.
>
> On Thu, 2 Jun 2022, 08:09 Romain Manni-Bucau, <[email protected]>
> wrote:
>
> > Hi
> >
> > Sorry for the delay.
> >
> > Here what I found back but an be worth checking other project mailing
> lists
> > since it often leads to dirty workarounds:
> >
> > - https://lists.apache.org/thread/wlocsqglzsn18g3o4vc8721gm3nmn99x
> > - https://lists.apache.org/thread/d9rhh61yy1mtorcc7n6v903rs24md649
> > - https://lists.apache.org/thread/oygsxwfr0t6j1bjj8gqw03fwnhst1281 /
> > https://lists.apache.org/thread/7cs0ptv293b0zddwg5zogqf4m0c81jv8 (this
> one
> > comes from tomee@)
> > - https://lists.apache.org/thread/pjxvmy4lwp7mxk8mvnzrd031rktvqgh1
> (when I
> > said it was reported quite a long time ago and broke quite quickly after
> it
> > was added)
> > - https://lists.apache.org/thread/w8f2k5ktfw4yzvo4y5zbszw3nnl636dy
> >
> > One interesting related tickets:
> >
> > - https://issues.apache.org/jira/browse/MNG-6354
> >
> > Side note: browsing plugin lists/chans can also be interesting (thinking
> to
> > TomEE, Meecrowave, Jetty which hit these conflicts by the past out of my
> > head).
> >
> > To summarize current state:
> >
> > - we depend and export JSR 330 (@inject) and JSR 250 (postconstruct etc),
> > these ones are frozen and legacy due to javax->jakarta renaming, it means
> > libraries we use and relying on them will likely move anytime soon to
> > jakarta so if we want to be able to upgrade without build hacks we'll
> need
> > to drop javax support and move to jakarta (not tomorrow but it will come
> > and likely for maven 4 to avoid to break multiple times?)
> > - anything we export from our maven.core realm can conflict with plugin
> > realms until we let mojo class realm strategy be configurable
> (parent/child
> > first) but it also means we take the risk the container features don't
> work
> > anymore if we do - no more injections in mojo for ex. So even if for
> > javax.* risk is low since it is not legacy dependencies, it is a rule we
> > should apply to most of our exported libraries (yes, slf4j I'm looking at
> > you for ex). General rule of thumb would be to only export packages we
> own
> > like org.apache.maven, org.codehaus.plexus etc...
> > - so overall the minimum risk solution is to NOT expose these API and
> > consider them internal to maven ecosystem (I don't see us breaking maven
> > plugins, it is too much work for the industry without any gain for end
> > users IMHO)
> >
> > Hope it helps a bit.
> >
> > 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 mar. 31 mai 2022 à 09:54, Slawomir Jaranowski <[email protected]
> >
> > a
> > écrit :
> >
> > > Hi Romain
> > >
> > > Did you find  - discussions and reported issues?
> > >
> > >
> > >
> > >
> > > pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <[email protected]>
> > > napisał(a):
> > >
> > > > Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <
> > [email protected]
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > I was convinced that plexus is deprecated [1] [2], but  you propose
> > > that
> > > > > users writing plugins outside the Maven core team should use it.
> > > > > Maybe I missed something?
> > > > >
> > > >
> > > > There are multiple discussions - can try to find them back next week
> if
> > > > needed - explaning why using JSR<xxx> does not comply to maven
> > pluggable
> > > > design and how an antipattern and a promise of issues it is.
> > > > So until we have a clean API we have to stay in the status-quo which
> is
> > > > plexus AFAIK today.
> > > >
> > > >
> > > > >
> > > > > There is no information [3] that JSR303 should be used only in
> Maven
> > > core
> > > > > plugins / components.
> > > > >
> > > >
> > > > Let's add that then :).
> > > >
> > > >
> > > > >
> > > > > [1] https://codehaus-plexus.github.io/plexus-containers/index.html
> > > > > [2]
> > > > >
> > > > >
> > > >
> > >
> >
> https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/
> > > > > [3] https://maven.apache.org/maven-jsr330.html
> > > > >
> > > > >
> > > > > pt., 20 maj 2022 o 21:13 Romain Manni-Bucau <[email protected]
> >
> > > > > napisał(a):
> > > > >
> > > > > > I'm not sure for shared, I always considered them as internals of
> > > maven
> > > > > > projects and rarely saw them reused except a very few times but
> > > > reasoning
> > > > > > is the same whatever module we speak about: does it impact
> external
> > > > > > consumer? If yes -> only org.apache.maven API or
> > > > assimilated/assimilable
> > > > > > (plexus is today I think), else we don't care and do what we like
> > > IMHO.
> > > > > >
> > > > > >
> > > > > > Le ven. 20 mai 2022 à 21:01, Sylwester Lachiewicz <
> > > > [email protected]
> > > > > >
> > > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > 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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sławomir Jaranowski
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>

Reply via email to