You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Slawomir Jaranowski <s....@gmail.com> on 2022/05/16 16:12:51 UTC
Maven plugins - injecting Maven components
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
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 18 mai 2022 à 11:52, Jason van Zyl <ja...@vanzyl.ca> a écrit :
> 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.
>
This is what was done until something like 7 years ago. It always have been
weird for users (and I have to include I was part of them years ago) to not
be able to debug these applications - note it can be servers but also just
plain libraries, don't only think about wildfly, tomee or open liberty ;) -
with mvnDebug. It is always way more complicated for plugins writers to
fork properly cause depending the OS, depending the process itself and a
bunch of other stuff, it is easy to leak the process or misconfigure it in
".".
Lastly it is also way faster to not fork and enables way more interactions
without weird patching and a client/server protocol whatever it is which
can break application or break features (think if you add a feature Filter
and the application adds a security filter for example whereas locally you
just have instances and do what you need).
So overall fork is not an option for our plugin writers IMHO but a
workaround.
>
> 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.
>
The issue is not enabling but sharing classes.
Look how leaking cdi-api broke people without adding used features to maven
ecosystem, it is the same for all the shared packages with potential
plugins so the leakage of javax.*, maybe tomrorrow jakarta.* is a bug for
maven plugins (+extensions?), not a feature.
>
> 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.
>
This is wrong, it had been wrong since the first release ;).
Once again the issue is not making work for us, this part is very trivial,
but making our extension (plugins) API working for extension writers and
not only te few plugins out there we do maintain ourselves.
>
> Jason
>
> > On May 16, 2022, at 1:14 PM, Slawomir Jaranowski <s....@gmail.com>
> 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 <rm...@gmail.com>
> > 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 <
> s.jaranowski@gmail.com>
> >> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 2 juin 2022 à 11:47, Stuart McCulloch <mc...@gmail.com> a écrit :
> Sorry, I was just struggling to see where exposing JSR330 has negatively
> impacted users in practice (ie excluding anything related to exposing CDI)
>
> For the CDI API sure, when that was exposed we didn't anticipate that the
> CDI spec would evolve how it did - so removing that is logical - but when
> there's a simple standard which has remained consistent (and the Jakarta
> variant is just a relocation due to naming issues) then I would have
> thought it would help users to let them use that rather than force them to
> use another API
>
Well at the risk to rewrite what was already:
1. so you assume API will stay immutable as we did for CDI, it got proven
wrong for CDI and slf4j by the past so no reason to assume it will not
generally speaking. Only exception being javax.* since now the namespace is
frozen
2. so thanks to 1. it is ok to use javax....until we migrate our guice
integration to use jakarta because guice upgrades or whatever reason we
have (be up to date, drop cve, ...). so overall it is a maven internal, not
an user API so forbidden from mojo and likely from external extension if we
propose a correct alternative for maven 4
>
> But regardless, the container will still work with whatever's exposed. So
> as Sylwester says the best way forward is probably with a
> design/requirement doc - then if there's any new annotations (over the
> existing Plexus or JSR330 ones) we can just update the container to support
> them.
>
The container will still work while there is no modification of these
packages....and it is an assumption we do which can be wrong, even for
javax.inject when mojo containers - user - extend this namespace for their
own need.
So overall we can never assume anything is stable in plugin classrealm.
side note: it is not something I like but something I sufferred from a lot
of times - from an user and core dev support guy - and I just try to ensure
we are not focused on ourselves and forget our users because technically it
looks fun. Our design is to support anything we can, in particular
mainstream code, which has the direct impact to forbid us to expose
anything mainstream at least as explained.
>
> --
> Cheers, Stuart
>
> On Thu, 2 Jun 2022, 10:21 Romain Manni-Bucau, <rm...@gmail.com>
> wrote:
>
> > @Stuart: api validating or enforcing classloader in mojo need workarounds
> > since you will use javax.inject from maven and not from your mojo
> > container/code (embedding an OSGi container can have this issue in some
> > cases without much hack but most container using classloaders will hit
> it,
> > I hit it at talend for component framework, some tomcat extensions as
> well
> > etc...). Nothing theorical and even if it would be theorical, we have to
> > respect out mojo design right? so we can't do that anyway until we assume
> > to maintain it and not move to jakarta anytime soon without a
> > classfiletransformer maintaining the mapping which is something which was
> > requested to be avoided on maven 4 path IIRC.
> >
> > 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 à 11:08, Sylwester Lachiewicz <slachiewicz@gmail.com
> >
> > a
> > écrit :
> >
> > > Maybe design document and later with PoC API, implementation is
> something
> > > that we missed and You can help here to solve this problem for users,
> > based
> > > on real case from You?
> > >
> > > Br
> > > Sylwester
> > >
> > >
> > > czw., 2 cze 2022, 10:57 użytkownik Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > napisał:
> > >
> > > > 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 <mc...@gmail.com> 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, <
> rmannibucau@gmail.com
> > >
> > > > > 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 <
> > > > s.jaranowski@gmail.com
> > > > > >
> > > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > Hi Romain
> > > > > > >
> > > > > > > Did you find - discussions and reported issues?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > > > > > napisał(a):
> > > > > > >
> > > > > > > > Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <
> > > > > > s.jaranowski@gmail.com
> > > > > > > >
> > > > > > > > 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 <
> > > > rmannibucau@gmail.com
> > > > > >
> > > > > > > > > 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 <
> > > > > > > > slachiewicz@gmail.com
> > > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > 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 <
> > > > > > > > > > s.jaranowski@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > > 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 <
> > > > > > > > rmannibucau@gmail.com
> > > > > > > > > >
> > > > > > > > > > > > > napisał(a):
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <
> > > > > > > > mcculls@gmail.com
> > > > > > > > > >
> > > > > > > > > > a
> > > > > > > > > > > > > écrit
> > > > > > > > > > > > > > :
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, 18 May 2022 at 14:15, Romain
> Manni-Bucau
> > <
> > > > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart
> McCulloch <
> > > > > > > > > > mcculls@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > > 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 <
> > > > > > > > > jason@vanzyl.ca
> > > > > > > > > > >
> > > > > > > > > > > > > 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
> > > > > > <
> > > > > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > > > > > 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
> > > > <
> > > > > > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > > > > > >> 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:
> > > > > > > > dev-unsubscribe@maven.apache.org
> > > > > > > > > > > > > > > > > > For additional commands, e-mail:
> > > > > > > > > dev-help@maven.apache.org
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Sławomir Jaranowski
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Sławomir Jaranowski
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sławomir Jaranowski
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Stuart McCulloch <mc...@gmail.com>.
Sorry, I was just struggling to see where exposing JSR330 has negatively
impacted users in practice (ie excluding anything related to exposing CDI)
For the CDI API sure, when that was exposed we didn't anticipate that the
CDI spec would evolve how it did - so removing that is logical - but when
there's a simple standard which has remained consistent (and the Jakarta
variant is just a relocation due to naming issues) then I would have
thought it would help users to let them use that rather than force them to
use another API
But regardless, the container will still work with whatever's exposed. So
as Sylwester says the best way forward is probably with a
design/requirement doc - then if there's any new annotations (over the
existing Plexus or JSR330 ones) we can just update the container to support
them.
--
Cheers, Stuart
On Thu, 2 Jun 2022, 10:21 Romain Manni-Bucau, <rm...@gmail.com> wrote:
> @Stuart: api validating or enforcing classloader in mojo need workarounds
> since you will use javax.inject from maven and not from your mojo
> container/code (embedding an OSGi container can have this issue in some
> cases without much hack but most container using classloaders will hit it,
> I hit it at talend for component framework, some tomcat extensions as well
> etc...). Nothing theorical and even if it would be theorical, we have to
> respect out mojo design right? so we can't do that anyway until we assume
> to maintain it and not move to jakarta anytime soon without a
> classfiletransformer maintaining the mapping which is something which was
> requested to be avoided on maven 4 path IIRC.
>
> 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 à 11:08, Sylwester Lachiewicz <sl...@gmail.com>
> a
> écrit :
>
> > Maybe design document and later with PoC API, implementation is something
> > that we missed and You can help here to solve this problem for users,
> based
> > on real case from You?
> >
> > Br
> > Sylwester
> >
> >
> > czw., 2 cze 2022, 10:57 użytkownik Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > napisał:
> >
> > > 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 <mc...@gmail.com> 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, <rmannibucau@gmail.com
> >
> > > > 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 <
> > > s.jaranowski@gmail.com
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > Hi Romain
> > > > > >
> > > > > > Did you find - discussions and reported issues?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > > > > > napisał(a):
> > > > > >
> > > > > > > Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <
> > > > > s.jaranowski@gmail.com
> > > > > > >
> > > > > > > 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 <
> > > rmannibucau@gmail.com
> > > > >
> > > > > > > > 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 <
> > > > > > > slachiewicz@gmail.com
> > > > > > > > >
> > > > > > > > > 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 <
> > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > 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 <
> > > > > > > > > s.jaranowski@gmail.com
> > > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > rmannibucau@gmail.com
> > > > > > > > >
> > > > > > > > > > > > napisał(a):
> > > > > > > > > > > >
> > > > > > > > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <
> > > > > > > mcculls@gmail.com
> > > > > > > > >
> > > > > > > > > a
> > > > > > > > > > > > écrit
> > > > > > > > > > > > > :
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau
> <
> > > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <
> > > > > > > > > mcculls@gmail.com
> > > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > jason@vanzyl.ca
> > > > > > > > > >
> > > > > > > > > > > > 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
> > > > > <
> > > > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > > > > 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
> > > <
> > > > > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > > > > >> 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:
> > > > > > > dev-unsubscribe@maven.apache.org
> > > > > > > > > > > > > > > > > For additional commands, e-mail:
> > > > > > > > dev-help@maven.apache.org
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Sławomir Jaranowski
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Sławomir Jaranowski
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sławomir Jaranowski
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Stuart: api validating or enforcing classloader in mojo need workarounds
since you will use javax.inject from maven and not from your mojo
container/code (embedding an OSGi container can have this issue in some
cases without much hack but most container using classloaders will hit it,
I hit it at talend for component framework, some tomcat extensions as well
etc...). Nothing theorical and even if it would be theorical, we have to
respect out mojo design right? so we can't do that anyway until we assume
to maintain it and not move to jakarta anytime soon without a
classfiletransformer maintaining the mapping which is something which was
requested to be avoided on maven 4 path IIRC.
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 à 11:08, Sylwester Lachiewicz <sl...@gmail.com> a
écrit :
> Maybe design document and later with PoC API, implementation is something
> that we missed and You can help here to solve this problem for users, based
> on real case from You?
>
> Br
> Sylwester
>
>
> czw., 2 cze 2022, 10:57 użytkownik Romain Manni-Bucau <
> rmannibucau@gmail.com>
> napisał:
>
> > 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 <mc...@gmail.com> 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, <rm...@gmail.com>
> > > 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 <
> > s.jaranowski@gmail.com
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > Hi Romain
> > > > >
> > > > > Did you find - discussions and reported issues?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > > > > napisał(a):
> > > > >
> > > > > > Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <
> > > > s.jaranowski@gmail.com
> > > > > >
> > > > > > 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 <
> > rmannibucau@gmail.com
> > > >
> > > > > > > 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 <
> > > > > > slachiewicz@gmail.com
> > > > > > > >
> > > > > > > > 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 <
> > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > 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 <
> > > > > > > > s.jaranowski@gmail.com
> > > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > rmannibucau@gmail.com
> > > > > > > >
> > > > > > > > > > > napisał(a):
> > > > > > > > > > >
> > > > > > > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <
> > > > > > mcculls@gmail.com
> > > > > > > >
> > > > > > > > a
> > > > > > > > > > > écrit
> > > > > > > > > > > > :
> > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <
> > > > > > > > mcculls@gmail.com
> > > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > jason@vanzyl.ca
> > > > > > > > >
> > > > > > > > > > > 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
> > > > <
> > > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > > > 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
> > <
> > > > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > > > >> 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:
> > > > > > dev-unsubscribe@maven.apache.org
> > > > > > > > > > > > > > > > For additional commands, e-mail:
> > > > > > > dev-help@maven.apache.org
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Sławomir Jaranowski
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sławomir Jaranowski
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sławomir Jaranowski
> > > > >
> > > >
> > >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Sylwester Lachiewicz <sl...@gmail.com>.
Maybe design document and later with PoC API, implementation is something
that we missed and You can help here to solve this problem for users, based
on real case from You?
Br
Sylwester
czw., 2 cze 2022, 10:57 użytkownik Romain Manni-Bucau <rm...@gmail.com>
napisał:
> 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 <mc...@gmail.com> 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, <rm...@gmail.com>
> > 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 <
> s.jaranowski@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > Hi Romain
> > > >
> > > > Did you find - discussions and reported issues?
> > > >
> > > >
> > > >
> > > >
> > > > pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <rm...@gmail.com>
> > > > napisał(a):
> > > >
> > > > > Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <
> > > s.jaranowski@gmail.com
> > > > >
> > > > > 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 <
> rmannibucau@gmail.com
> > >
> > > > > > 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 <
> > > > > slachiewicz@gmail.com
> > > > > > >
> > > > > > > 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 <
> > > > > > > > rmannibucau@gmail.com>
> > > > > > > > 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 <
> > > > > > > s.jaranowski@gmail.com
> > > > > > > > >
> > > > > > > > > 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 <
> > > > > rmannibucau@gmail.com
> > > > > > >
> > > > > > > > > > napisał(a):
> > > > > > > > > >
> > > > > > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <
> > > > > mcculls@gmail.com
> > > > > > >
> > > > > > > a
> > > > > > > > > > écrit
> > > > > > > > > > > :
> > > > > > > > > > >
> > > > > > > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <
> > > > > > > mcculls@gmail.com
> > > > > > > > >
> > > > > > > > > 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 <
> > > > > > jason@vanzyl.ca
> > > > > > > >
> > > > > > > > > > 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
> > > <
> > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > > 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
> <
> > > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > > >> 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:
> > > > > dev-unsubscribe@maven.apache.org
> > > > > > > > > > > > > > > For additional commands, e-mail:
> > > > > > dev-help@maven.apache.org
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Sławomir Jaranowski
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sławomir Jaranowski
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Sławomir Jaranowski
> > > >
> > >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Stuart McCulloch <mc...@gmail.com>.
Could you highlight which one was specifically an issue with JSR330 (ie. an
actual issue, not a theoretical one) and not the CDI API as I must have
missed it?
On Thu, 2 Jun 2022, 09:57 Romain Manni-Bucau, <rm...@gmail.com> wrote:
> 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 <mc...@gmail.com> 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, <rm...@gmail.com>
> > 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 <
> s.jaranowski@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > Hi Romain
> > > >
> > > > Did you find - discussions and reported issues?
> > > >
> > > >
> > > >
> > > >
> > > > pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <rm...@gmail.com>
> > > > napisał(a):
> > > >
> > > > > Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <
> > > s.jaranowski@gmail.com
> > > > >
> > > > > 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 <
> rmannibucau@gmail.com
> > >
> > > > > > 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 <
> > > > > slachiewicz@gmail.com
> > > > > > >
> > > > > > > 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 <
> > > > > > > > rmannibucau@gmail.com>
> > > > > > > > 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 <
> > > > > > > s.jaranowski@gmail.com
> > > > > > > > >
> > > > > > > > > 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 <
> > > > > rmannibucau@gmail.com
> > > > > > >
> > > > > > > > > > napisał(a):
> > > > > > > > > >
> > > > > > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <
> > > > > mcculls@gmail.com
> > > > > > >
> > > > > > > a
> > > > > > > > > > écrit
> > > > > > > > > > > :
> > > > > > > > > > >
> > > > > > > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <
> > > > > > > mcculls@gmail.com
> > > > > > > > >
> > > > > > > > > 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 <
> > > > > > jason@vanzyl.ca
> > > > > > > >
> > > > > > > > > > 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
> > > <
> > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > > 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
> <
> > > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > > >> 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:
> > > > > dev-unsubscribe@maven.apache.org
> > > > > > > > > > > > > > > For additional commands, e-mail:
> > > > > > dev-help@maven.apache.org
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Sławomir Jaranowski
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sławomir Jaranowski
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Sławomir Jaranowski
> > > >
> > >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <mc...@gmail.com> 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, <rm...@gmail.com>
> 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 <s.jaranowski@gmail.com
> >
> > a
> > écrit :
> >
> > > Hi Romain
> > >
> > > Did you find - discussions and reported issues?
> > >
> > >
> > >
> > >
> > > pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <rm...@gmail.com>
> > > napisał(a):
> > >
> > > > Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <
> > s.jaranowski@gmail.com
> > > >
> > > > 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 <rmannibucau@gmail.com
> >
> > > > > 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 <
> > > > slachiewicz@gmail.com
> > > > > >
> > > > > > 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 <
> > > > > > > rmannibucau@gmail.com>
> > > > > > > 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 <
> > > > > > s.jaranowski@gmail.com
> > > > > > > >
> > > > > > > > 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 <
> > > > rmannibucau@gmail.com
> > > > > >
> > > > > > > > > napisał(a):
> > > > > > > > >
> > > > > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <
> > > > mcculls@gmail.com
> > > > > >
> > > > > > a
> > > > > > > > > écrit
> > > > > > > > > > :
> > > > > > > > > >
> > > > > > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <
> > > > > > mcculls@gmail.com
> > > > > > > >
> > > > > > > > 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 <
> > > > > jason@vanzyl.ca
> > > > > > >
> > > > > > > > > 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
> > <
> > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > > >> 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:
> > > > dev-unsubscribe@maven.apache.org
> > > > > > > > > > > > > > For additional commands, e-mail:
> > > > > dev-help@maven.apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Sławomir Jaranowski
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sławomir Jaranowski
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Stuart McCulloch <mc...@gmail.com>.
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, <rm...@gmail.com> 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 <s....@gmail.com>
> a
> écrit :
>
> > Hi Romain
> >
> > Did you find - discussions and reported issues?
> >
> >
> >
> >
> > pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <rm...@gmail.com>
> > napisał(a):
> >
> > > Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <
> s.jaranowski@gmail.com
> > >
> > > 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 <rm...@gmail.com>
> > > > 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 <
> > > slachiewicz@gmail.com
> > > > >
> > > > > 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 <
> > > > > > rmannibucau@gmail.com>
> > > > > > 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 <
> > > > > s.jaranowski@gmail.com
> > > > > > >
> > > > > > > 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 <
> > > rmannibucau@gmail.com
> > > > >
> > > > > > > > napisał(a):
> > > > > > > >
> > > > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <
> > > mcculls@gmail.com
> > > > >
> > > > > a
> > > > > > > > écrit
> > > > > > > > > :
> > > > > > > > >
> > > > > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <
> > > > > mcculls@gmail.com
> > > > > > >
> > > > > > > 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 <
> > > > jason@vanzyl.ca
> > > > > >
> > > > > > > > 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
> <
> > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > > >> 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:
> > > dev-unsubscribe@maven.apache.org
> > > > > > > > > > > > > For additional commands, e-mail:
> > > > dev-help@maven.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Sławomir Jaranowski
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Sławomir Jaranowski
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <s....@gmail.com> a
écrit :
> Hi Romain
>
> Did you find - discussions and reported issues?
>
>
>
>
> pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <rm...@gmail.com>
> napisał(a):
>
> > Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <s.jaranowski@gmail.com
> >
> > 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 <rm...@gmail.com>
> > > 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 <
> > slachiewicz@gmail.com
> > > >
> > > > 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 <
> > > > > rmannibucau@gmail.com>
> > > > > 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 <
> > > > s.jaranowski@gmail.com
> > > > > >
> > > > > > 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 <
> > rmannibucau@gmail.com
> > > >
> > > > > > > napisał(a):
> > > > > > >
> > > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <
> > mcculls@gmail.com
> > > >
> > > > a
> > > > > > > écrit
> > > > > > > > :
> > > > > > > >
> > > > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > > > > > rmannibucau@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <
> > > > mcculls@gmail.com
> > > > > >
> > > > > > 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 <
> > > jason@vanzyl.ca
> > > > >
> > > > > > > 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 <
> > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > 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 <
> > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > > >> 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:
> > dev-unsubscribe@maven.apache.org
> > > > > > > > > > > > For additional commands, e-mail:
> > > dev-help@maven.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sławomir Jaranowski
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>
>
> --
> Sławomir Jaranowski
>
Re: Maven plugins - injecting Maven components
Posted by Slawomir Jaranowski <s....@gmail.com>.
Hi Romain
Did you find - discussions and reported issues?
pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <rm...@gmail.com>
napisał(a):
> Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <s....@gmail.com>
> 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 <rm...@gmail.com>
> > 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 <
> slachiewicz@gmail.com
> > >
> > > 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 <
> > > > rmannibucau@gmail.com>
> > > > 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 <
> > > s.jaranowski@gmail.com
> > > > >
> > > > > 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 <
> rmannibucau@gmail.com
> > >
> > > > > > napisał(a):
> > > > > >
> > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <
> mcculls@gmail.com
> > >
> > > a
> > > > > > écrit
> > > > > > > :
> > > > > > >
> > > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > > > > rmannibucau@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <
> > > mcculls@gmail.com
> > > > >
> > > > > 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 <
> > jason@vanzyl.ca
> > > >
> > > > > > 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 <
> > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > 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 <
> > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > 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 <
> > > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > > >> 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:
> dev-unsubscribe@maven.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > dev-help@maven.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sławomir Jaranowski
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
--
Sławomir Jaranowski
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <s....@gmail.com> 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 <rm...@gmail.com>
> 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 <slachiewicz@gmail.com
> >
> > 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 <
> > > rmannibucau@gmail.com>
> > > 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 <
> > s.jaranowski@gmail.com
> > > >
> > > > 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 <rmannibucau@gmail.com
> >
> > > > > napisał(a):
> > > > >
> > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <mcculls@gmail.com
> >
> > a
> > > > > écrit
> > > > > > :
> > > > > >
> > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <
> > mcculls@gmail.com
> > > >
> > > > 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 <
> jason@vanzyl.ca
> > >
> > > > > 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 <
> > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > 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 <
> > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > 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 <
> > > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > > >> 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: dev-unsubscribe@maven.apache.org
> > > > > > > > > > For additional commands, e-mail:
> dev-help@maven.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sławomir Jaranowski
> > > > >
> > > >
> > >
> >
>
>
> --
> Sławomir Jaranowski
>
Re: Maven plugins - injecting Maven components
Posted by Slawomir Jaranowski <s....@gmail.com>.
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 is no information [3] that JSR303 should be used only in Maven core
plugins / components.
[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 <rm...@gmail.com>
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 <sl...@gmail.com>
> 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 <
> > rmannibucau@gmail.com>
> > 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 <
> s.jaranowski@gmail.com
> > >
> > > 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 <rm...@gmail.com>
> > > > napisał(a):
> > > >
> > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <mc...@gmail.com>
> a
> > > > écrit
> > > > > :
> > > > >
> > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > > rmannibucau@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <
> mcculls@gmail.com
> > >
> > > 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 <jason@vanzyl.ca
> >
> > > > 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 <
> > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > 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 <
> > > > > > rmannibucau@gmail.com>
> > > > > > > > > > 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 <
> > > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > > >> 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: dev-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Sławomir Jaranowski
> > > >
> > >
> >
>
--
Sławomir Jaranowski
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <sl...@gmail.com> 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 <
> rmannibucau@gmail.com>
> 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 <s.jaranowski@gmail.com
> >
> > 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 <rm...@gmail.com>
> > > napisał(a):
> > >
> > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <mc...@gmail.com> a
> > > écrit
> > > > :
> > > >
> > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <mcculls@gmail.com
> >
> > 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 <ja...@vanzyl.ca>
> > > 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 <
> > > > > > > s.jaranowski@gmail.com>
> > > > > > > > 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 <
> > > > > rmannibucau@gmail.com>
> > > > > > > > > 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 <
> > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > >> 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: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Sylwester Lachiewicz <sl...@gmail.com>.
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 <rm...@gmail.com>
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 <s....@gmail.com>
> 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 <rm...@gmail.com>
> > napisał(a):
> >
> > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <mc...@gmail.com> a
> > écrit
> > > :
> > >
> > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <mc...@gmail.com>
> 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 <ja...@vanzyl.ca>
> > 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 <
> > > > > > s.jaranowski@gmail.com>
> > > > > > > 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 <
> > > > rmannibucau@gmail.com>
> > > > > > > > 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 <
> > > > > > > s.jaranowski@gmail.com>
> > > > > > > >> 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: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, can be but it does not change the answer to Sławomir since
javax.*/jakarta.* are no-go for mojo (and hopefully extensions soon)
outside maven project (understand maintained by maven committers), does it?
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 à 19:32, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Romain, I think you completely misinterpreted what Jason and Stuart meant.
>
>
> T
>
> On Fri, May 20, 2022, 19:15 Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > 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 <s.jaranowski@gmail.com
> >
> > 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 <rm...@gmail.com>
> > > napisał(a):
> > >
> > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <mc...@gmail.com> a
> > > écrit
> > > > :
> > > >
> > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <mcculls@gmail.com
> >
> > 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 <ja...@vanzyl.ca>
> > > 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 <
> > > > > > > s.jaranowski@gmail.com>
> > > > > > > > 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 <
> > > > > rmannibucau@gmail.com>
> > > > > > > > > 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 <
> > > > > > > > s.jaranowski@gmail.com>
> > > > > > > > >> 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: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Tamás Cservenák <ta...@cservenak.net>.
Romain, I think you completely misinterpreted what Jason and Stuart meant.
T
On Fri, May 20, 2022, 19:15 Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 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 <s....@gmail.com>
> 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 <rm...@gmail.com>
> > napisał(a):
> >
> > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <mc...@gmail.com> a
> > écrit
> > > :
> > >
> > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <mc...@gmail.com>
> 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 <ja...@vanzyl.ca>
> > 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 <
> > > > > > s.jaranowski@gmail.com>
> > > > > > > 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 <
> > > > rmannibucau@gmail.com>
> > > > > > > > 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 <
> > > > > > > s.jaranowski@gmail.com>
> > > > > > > >> 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: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <s....@gmail.com> 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 <rm...@gmail.com>
> napisał(a):
>
> > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <mc...@gmail.com> a
> écrit
> > :
> >
> > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <mc...@gmail.com> 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 <ja...@vanzyl.ca>
> 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 <
> > > > > s.jaranowski@gmail.com>
> > > > > > 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 <
> > > rmannibucau@gmail.com>
> > > > > > > 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 <
> > > > > > s.jaranowski@gmail.com>
> > > > > > >> 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: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Sławomir Jaranowski
>
Re: Maven plugins - injecting Maven components
Posted by Slawomir Jaranowski <s....@gmail.com>.
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 <rm...@gmail.com>
napisał(a):
> Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <mc...@gmail.com> a écrit
> :
>
> > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> >
> > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <mc...@gmail.com> 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 <ja...@vanzyl.ca> 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 <
> > > > s.jaranowski@gmail.com>
> > > > > 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 <
> > rmannibucau@gmail.com>
> > > > > > 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 <
> > > > > s.jaranowski@gmail.com>
> > > > > >> 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: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
--
Sławomir Jaranowski
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <mc...@gmail.com> a écrit :
> On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <mc...@gmail.com> 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 <ja...@vanzyl.ca> 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 <
> > > s.jaranowski@gmail.com>
> > > > 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 <
> rmannibucau@gmail.com>
> > > > > 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 <
> > > > s.jaranowski@gmail.com>
> > > > >> 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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Stuart McCulloch <mc...@gmail.com>.
On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <mc...@gmail.com> 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...)
> 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 <ja...@vanzyl.ca> 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 <
> > s.jaranowski@gmail.com>
> > > 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 <rm...@gmail.com>
> > > > 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 <
> > > s.jaranowski@gmail.com>
> > > >> 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 18 mai 2022 à 15:03, Stuart McCulloch <mc...@gmail.com> 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).
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 <ja...@vanzyl.ca> 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 <
> s.jaranowski@gmail.com>
> > 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 <rm...@gmail.com>
> > > 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 <
> > s.jaranowski@gmail.com>
> > >> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven plugins - injecting Maven components
Posted by Stuart McCulloch <mc...@gmail.com>.
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 <ja...@vanzyl.ca> 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 <s....@gmail.com>
> 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 <rm...@gmail.com>
> > 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 <
> s.jaranowski@gmail.com>
> >> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven plugins - injecting Maven components
Posted by Jason van Zyl <ja...@vanzyl.ca>.
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.
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.
Jason
> On May 16, 2022, at 1:14 PM, Slawomir Jaranowski <s....@gmail.com> 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 <rm...@gmail.com>
> 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 <s....@gmail.com>
>> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
So clearly -1 for @inject then.
Le mar. 17 mai 2022 à 22:49, Slawomir Jaranowski <s....@gmail.com> a
écrit :
> pon., 16 maj 2022 o 20:44 Romain Manni-Bucau <rm...@gmail.com>
> napisał(a):
>
> > Le lun. 16 mai 2022 à 19:14, Slawomir Jaranowski <s.jaranowski@gmail.com
> >
> > 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.
> >
> >
> I don't ask about the validation layer.
>
> I want to find the "best practices" for plugin development.
>
> Our site documentation about it [1] should be refreshed, so I try to
> collect info.
>
> [1] https://maven.apache.org/plugin-developers/index.html
>
>
> >
> > >
> > >
> > > [1] https://maven.apache.org/maven-jsr330.html
> > >
> > > pon., 16 maj 2022 o 18:42 Romain Manni-Bucau <rm...@gmail.com>
> > > 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 <
> > s.jaranowski@gmail.com
> > > >
> > > > 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
> > >
> >
>
>
> --
> Sławomir Jaranowski
>
Re: Maven plugins - injecting Maven components
Posted by Slawomir Jaranowski <s....@gmail.com>.
pon., 16 maj 2022 o 20:44 Romain Manni-Bucau <rm...@gmail.com>
napisał(a):
> Le lun. 16 mai 2022 à 19:14, Slawomir Jaranowski <s....@gmail.com>
> 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.
>
>
I don't ask about the validation layer.
I want to find the "best practices" for plugin development.
Our site documentation about it [1] should be refreshed, so I try to
collect info.
[1] https://maven.apache.org/plugin-developers/index.html
>
> >
> >
> > [1] https://maven.apache.org/maven-jsr330.html
> >
> > pon., 16 maj 2022 o 18:42 Romain Manni-Bucau <rm...@gmail.com>
> > 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 <
> s.jaranowski@gmail.com
> > >
> > > 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
> >
>
--
Sławomir Jaranowski
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le lun. 16 mai 2022 à 19:14, Slawomir Jaranowski <s....@gmail.com> 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 <rm...@gmail.com>
> 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 <s.jaranowski@gmail.com
> >
> > 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
>
Re: Maven plugins - injecting Maven components
Posted by Slawomir Jaranowski <s....@gmail.com>.
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 <rm...@gmail.com>
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 <s....@gmail.com>
> 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
Re: Maven plugins - injecting Maven components
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <s....@gmail.com> 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
>