Hi Sorry for the delay.
Here what I found back but an be worth checking other project mailing lists since it often leads to dirty workarounds: - https://lists.apache.org/thread/wlocsqglzsn18g3o4vc8721gm3nmn99x - https://lists.apache.org/thread/d9rhh61yy1mtorcc7n6v903rs24md649 - https://lists.apache.org/thread/oygsxwfr0t6j1bjj8gqw03fwnhst1281 / https://lists.apache.org/thread/7cs0ptv293b0zddwg5zogqf4m0c81jv8 (this one comes from tomee@) - https://lists.apache.org/thread/pjxvmy4lwp7mxk8mvnzrd031rktvqgh1 (when I said it was reported quite a long time ago and broke quite quickly after it was added) - https://lists.apache.org/thread/w8f2k5ktfw4yzvo4y5zbszw3nnl636dy One interesting related tickets: - https://issues.apache.org/jira/browse/MNG-6354 Side note: browsing plugin lists/chans can also be interesting (thinking to TomEE, Meecrowave, Jetty which hit these conflicts by the past out of my head). To summarize current state: - we depend and export JSR 330 (@inject) and JSR 250 (postconstruct etc), these ones are frozen and legacy due to javax->jakarta renaming, it means libraries we use and relying on them will likely move anytime soon to jakarta so if we want to be able to upgrade without build hacks we'll need to drop javax support and move to jakarta (not tomorrow but it will come and likely for maven 4 to avoid to break multiple times?) - anything we export from our maven.core realm can conflict with plugin realms until we let mojo class realm strategy be configurable (parent/child first) but it also means we take the risk the container features don't work anymore if we do - no more injections in mojo for ex. So even if for javax.* risk is low since it is not legacy dependencies, it is a rule we should apply to most of our exported libraries (yes, slf4j I'm looking at you for ex). General rule of thumb would be to only export packages we own like org.apache.maven, org.codehaus.plexus etc... - so overall the minimum risk solution is to NOT expose these API and consider them internal to maven ecosystem (I don't see us breaking maven plugins, it is too much work for the industry without any gain for end users IMHO) Hope it helps a bit. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 31 mai 2022 à 09:54, Slawomir Jaranowski <[email protected]> a écrit : > Hi Romain > > Did you find - discussions and reported issues? > > > > > pt., 20 maj 2022 o 23:18 Romain Manni-Bucau <[email protected]> > napisał(a): > > > Le ven. 20 mai 2022 à 22:21, Slawomir Jaranowski <[email protected] > > > > a > > écrit : > > > > > I was convinced that plexus is deprecated [1] [2], but you propose > that > > > users writing plugins outside the Maven core team should use it. > > > Maybe I missed something? > > > > > > > There are multiple discussions - can try to find them back next week if > > needed - explaning why using JSR<xxx> does not comply to maven pluggable > > design and how an antipattern and a promise of issues it is. > > So until we have a clean API we have to stay in the status-quo which is > > plexus AFAIK today. > > > > > > > > > > There is no information [3] that JSR303 should be used only in Maven > core > > > plugins / components. > > > > > > > Let's add that then :). > > > > > > > > > > [1] https://codehaus-plexus.github.io/plexus-containers/index.html > > > [2] > > > > > > > > > https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/ > > > [3] https://maven.apache.org/maven-jsr330.html > > > > > > > > > pt., 20 maj 2022 o 21:13 Romain Manni-Bucau <[email protected]> > > > napisał(a): > > > > > > > I'm not sure for shared, I always considered them as internals of > maven > > > > projects and rarely saw them reused except a very few times but > > reasoning > > > > is the same whatever module we speak about: does it impact external > > > > consumer? If yes -> only org.apache.maven API or > > assimilated/assimilable > > > > (plexus is today I think), else we don't care and do what we like > IMHO. > > > > > > > > > > > > Le ven. 20 mai 2022 à 21:01, Sylwester Lachiewicz < > > [email protected] > > > > > > > > a > > > > écrit : > > > > > > > > > And what about shared libraries? they can be used by plugins or > even > > > > > externally. > > > > > Sylwester > > > > > > > > > > pt., 20 maj 2022, 19:15 użytkownik Romain Manni-Bucau < > > > > > [email protected]> > > > > > napisał: > > > > > > > > > > > It is quite simple: > > > > > > > > > > > > Maven plugin: maven API or plexus annotations are preferred > > > > > > Maven core: JSR 330 is out internal API for IoC > lookups/injections > > > > > > > > > > > > Romain Manni-Bucau > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > > > > <http://rmannibucau.wordpress.com> | Github < > > > > > > https://github.com/rmannibucau> | > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > > > < > > > > > > > > > > > > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > > > > > > > > > > > > > > Le ven. 20 mai 2022 à 18:08, Slawomir Jaranowski < > > > > [email protected] > > > > > > > > > > > > a > > > > > > écrit : > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I'm a little confused - what should be conclusions from this > > > > > discussion? > > > > > > > > > > > > > > I asked about using JSR330 with maven components like > > MavenProject, > > > > > > > MavenSession ... in plugin Mojo code. > > > > > > > But I see discussion about using JSR330 at general in Maven > > plugins > > > > > > > > > > > > > > Currently we widely use JSR330 in core Maven plugins as > > > replacement > > > > > for > > > > > > > plexus annotations. > > > > > > > > > > > > > > Can anybody else summarize it? ... Maybe I wrong understood > this > > > > > > > discussion. > > > > > > > > > > > > > > > > > > > > > śr., 18 maj 2022 o 16:07 Romain Manni-Bucau < > > [email protected] > > > > > > > > > > > napisał(a): > > > > > > > > > > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch < > > [email protected] > > > > > > > > a > > > > > > > écrit > > > > > > > > : > > > > > > > > > > > > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau < > > > > > > > [email protected]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Le mer. 18 mai 2022 à 15:03, Stuart McCulloch < > > > > [email protected] > > > > > > > > > > > > a > > > > > > > > > écrit > > > > > > > > > > : > > > > > > > > > > > > > > > > > > > > > I do wonder whether we're conflating the real issues of > > > > > exposing > > > > > > > the > > > > > > > > > CDI > > > > > > > > > > > API (for @Typed) with the much smaller JSR330 API > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes as soon as you have a different version needed by a > > > plugin > > > > > and > > > > > > > the > > > > > > > > > api > > > > > > > > > > exposed (parent first forced - and if not forced we dont > > know > > > > if > > > > > it > > > > > > > > > works). > > > > > > > > > > > > > > > > > > > > > > > > > > > > There's only ever been one version of the JSR 330 API > because > > > > it's > > > > > so > > > > > > > > small > > > > > > > > > and complete (and I'd be surprised if the jakarta.inject > API > > is > > > > any > > > > > > > > > different...) > > > > > > > > > > > > > > > > > > > > > > > > > We probably also thought javax.annotation would never get > dead > > > > > > > annotations > > > > > > > > nor build time annotations and it just did so not sure I > would > > > bet. > > > > > > > > Size is not much an issue too, actually new API are fine but > > > > > modifying > > > > > > > > existing can create a mess, in particular with proxies. > > > > > > > > Last thing is that JSR 330 is not an user API anyway since it > > > does > > > > > not > > > > > > > > define the associated behavior so at the end, while it is > > small, > > > it > > > > > is > > > > > > > > worth keeping maven specific API IMHO for the user facing > part > > of > > > > our > > > > > > > > deliverables. > > > > > > > > > > > > > > > > Side note: I never wrote it wouldnt be great to reuse a > > standard > > > > API > > > > > > for > > > > > > > > our own API, I just write it is not compatible with a plugin > > > system > > > > > in > > > > > > > > general until you forbid other usages of that API which is > not > > > what > > > > > we > > > > > > > want > > > > > > > > for maven plugins IMHO. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So we shouldnt leak what others can use in the API - no > > > parent > > > > > > > > ClassRealm > > > > > > > > > > access. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Does anyone have a link to an issue that specifically > > > > involved > > > > > > > > > exporting > > > > > > > > > > > the JSR330 API (I did a quick search but the threads I > > > found > > > > > were > > > > > > > all > > > > > > > > > > about > > > > > > > > > > > the CDI API) > > > > > > > > > > > IIRC there was only one external plugin/extension that > > ever > > > > > used > > > > > > > > > @Typed, > > > > > > > > > > so > > > > > > > > > > > we could easily just stop exporting the CDI API while > > > > > continuing > > > > > > to > > > > > > > > > > export > > > > > > > > > > > JSR330 > > > > > > > > > > > > > > > > > > > > > > (other comments inline below...) > > > > > > > > > > > > > > > > > > > > > > On Wed, 18 May 2022 at 10:52, Jason van Zyl < > > > [email protected] > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > I have used SLF4J and JSR330 in plugins for years > > without > > > > > > issue. > > > > > > > > They > > > > > > > > > > all > > > > > > > > > > > > still work and nothing has mysteriously stopped > working > > > > even > > > > > > made > > > > > > > > 7+ > > > > > > > > > > > years > > > > > > > > > > > > ago. I honestly don’t see much point in making our > own > > > > > > > annotations, > > > > > > > > > and > > > > > > > > > > > > I’ve not encountered any of the issues Romain > presents. > > > > > > > > > > > > > > > > > > > > > > > > To Romain’s points: > > > > > > > > > > > > > > > > > > > > > > > > 1. I don’t see it as an issue that two entirely > > different > > > > > > > universes > > > > > > > > > of > > > > > > > > > > > > classes don’t work 100% in the same classloader. Just > > > fork > > > > > and > > > > > > > use > > > > > > > > a > > > > > > > > > > > > separate process as these two universes were never > > meant > > > to > > > > > > > > actually > > > > > > > > > > run > > > > > > > > > > > in > > > > > > > > > > > > the same classloader. They don’t run that way in > > > production > > > > > so > > > > > > > why > > > > > > > > > > would > > > > > > > > > > > > you try doing that during a build or testing. > > > > > > > > > > > > > > > > > > > > > > > > 2. I don’t think that’s an issue, if we wanted to > > augment > > > > > what > > > > > > we > > > > > > > > do > > > > > > > > > > with > > > > > > > > > > > > another CI spec we can with Sisu. I think any of the > > > > standard > > > > > > CI > > > > > > > > > > > > specifications provide everything we might > potentially > > > > need. > > > > > We > > > > > > > may > > > > > > > > > not > > > > > > > > > > > use > > > > > > > > > > > > them now, but Sisu would allow us to use which ever > > spec > > > we > > > > > > > wished, > > > > > > > > > in > > > > > > > > > > > > whatever combination we wish. Stuart, correct me if > I’m > > > > > wrong. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, supporting different annotations is one of the > main > > > > > features > > > > > > > of > > > > > > > > > > Sisu - > > > > > > > > > > > it doesn't force you to export a particular API (the > > > previous > > > > > > > > decision > > > > > > > > > to > > > > > > > > > > > export JSR330 to plugins was because it was a standard, > > so > > > it > > > > > > made > > > > > > > it > > > > > > > > > > > easier to share injectable components between Maven and > > > other > > > > > > > > > ecosystems > > > > > > > > > > > without having to continually write adapters - but it's > > > not a > > > > > > > > > fundamental > > > > > > > > > > > requirement) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3. It’s been fine for how many years? Sisu is our > > defense > > > > > here, > > > > > > > it > > > > > > > > > can > > > > > > > > > > > > look at annotation A or B and provide the same > behavior > > > for > > > > > the > > > > > > > > user. > > > > > > > > > > I’m > > > > > > > > > > > > sure Stuart can show us how to get javax.inject and > > > > > > > jakarta.inject > > > > > > > > > > > working > > > > > > > > > > > > simultaneously for a co-existence and/or transition. > > > Again > > > > > > > Stuart, > > > > > > > > > > > correct > > > > > > > > > > > > me if I’m wrong. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There's an initial PR to add jakarta.inject support to > > > Guice > > > > > > which > > > > > > > > > people > > > > > > > > > > > are working on - once that's in the changes needed in > > Sisu > > > > are > > > > > > > > > relatively > > > > > > > > > > > small. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jason > > > > > > > > > > > > > > > > > > > > > > > > > On May 16, 2022, at 1:14 PM, Slawomir Jaranowski < > > > > > > > > > > > [email protected]> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > But from other side we can use JSR-330 in Mojo [1] > > > > > > > > > > > > > > > > > > > > > > > > > > so we will: > > > > > > > > > > > > > > > > > > > > > > > > > > @Parameter( defaultValue = "${project}", > readonly = > > > > true, > > > > > > > > > required > > > > > > > > > > = > > > > > > > > > > > > > true ) > > > > > > > > > > > > > private MavenProject project; > > > > > > > > > > > > > > > > > > > > > > > > > > @Inject > > > > > > > > > > > > > public SuperMojo( Jsr330Component component ) > > > > > > > > > > > > > { > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > From code perspective will be clear > > > > > > > > > > > > > > > > > > > > > > > > > > @Inject > > > > > > > > > > > > > public SuperMojo( MavenProject project, > > > > Jsr330Component > > > > > > > > > component > > > > > > > > > > ) > > > > > > > > > > > > > { > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] https://maven.apache.org/maven-jsr330.html > > > > > > > > > > > > > > > > > > > > > > > > > > pon., 16 maj 2022 o 18:42 Romain Manni-Bucau < > > > > > > > > > [email protected]> > > > > > > > > > > > > > napisał(a): > > > > > > > > > > > > > > > > > > > > > > > > > >> Hi Sławomir, > > > > > > > > > > > > >> > > > > > > > > > > > > >> This is a complex topic, basically there is a will > > to > > > > get > > > > > a > > > > > > > real > > > > > > > > > IoC > > > > > > > > > > > for > > > > > > > > > > > > >> maven-core and keep a maven specific API for > plugin > > > > > writers > > > > > > so > > > > > > > > I'm > > > > > > > > > > > > tempted > > > > > > > > > > > > >> to say option 1 for mojo. > > > > > > > > > > > > >> > > > > > > > > > > > > >> As a reminder the issues exposing @Inject are: > > > > > > > > > > > > >> > > > > > > > > > > > > >> 1. We can conflict with plugins (it is the case > > > already > > > > > and > > > > > > a > > > > > > > > lot > > > > > > > > > of > > > > > > > > > > > > >> servers have to workaround that with custom > > > > classloaders) > > > > > > > > > > > > >> 2. We have no guarantee next version of @Inject > will > > > be > > > > > > > > > compatible - > > > > > > > > > > > > there > > > > > > > > > > > > >> is a trend to break at jakarta EE > > > > > > > > > > > > >> 3. When we'll want to migrate to jakarta.inject > (or > > > > > another > > > > > > > API) > > > > > > > > > > we'll > > > > > > > > > > > > >> break all consumers if it is used outside maven > > > project > > > > > > itself > > > > > > > > > > > > >> > > > > > > > > > > > > >> Where this policy has its limitations is that > > > extensions > > > > > are > > > > > > > now > > > > > > > > > > kind > > > > > > > > > > > of > > > > > > > > > > > > >> "plugins" in the sense it should only use a public > > API > > > > but > > > > > > > > > currently > > > > > > > > > > > it > > > > > > > > > > > > has > > > > > > > > > > > > >> to use internal one (@Inject). > > > > > > > > > > > > >> So while I think option 1 is really the way to go, > > we > > > > > > probably > > > > > > > > > have > > > > > > > > > > > some > > > > > > > > > > > > >> work to extend it to extension mid-term and clean > > the > > > > API > > > > > > for > > > > > > > > > maven > > > > > > > > > > 4. > > > > > > > > > > > > >> > > > > > > > > > > > > >> Hope it helps. > > > > > > > > > > > > >> > > > > > > > > > > > > >> Romain Manni-Bucau > > > > > > > > > > > > >> @rmannibucau <https://twitter.com/rmannibucau> | > > > Blog > > > > > > > > > > > > >> <https://rmannibucau.metawerx.net/> | Old Blog > > > > > > > > > > > > >> <http://rmannibucau.wordpress.com> | Github < > > > > > > > > > > > > >> https://github.com/rmannibucau> | > > > > > > > > > > > > >> LinkedIn <https://www.linkedin.com/in/rmannibucau > > > > | > > > > Book > > > > > > > > > > > > >> < > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > >>> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> Le lun. 16 mai 2022 à 18:13, Slawomir Jaranowski < > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > >> a > > > > > > > > > > > > >> écrit : > > > > > > > > > > > > >> > > > > > > > > > > > > >>> Hi, > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> We can inject Maven components into plugins in > many > > > > ways > > > > > > ... > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> We can use @Parameter, like: > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> @Parameter( defaultValue = "${project}", > > readonly > > > = > > > > > > true, > > > > > > > > > > > required = > > > > > > > > > > > > >>> true ) > > > > > > > > > > > > >>> private MavenProject project; > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> @Parameter( defaultValue = "${session}", > > readonly > > > = > > > > > > true, > > > > > > > > > > > required = > > > > > > > > > > > > >>> true ) > > > > > > > > > > > > >>> private MavenSession session; > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> @Parameter( defaultValue = "${mojoExecution}", > > > > > readonly > > > > > > = > > > > > > > > > true, > > > > > > > > > > > > >>> required = true ) > > > > > > > > > > > > >>> private MojoExecution mojoExecution; > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> We can use DI with > > > > > > > > > @org.apache.maven.plugins.annotations.Component > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> @Component > > > > > > > > > > > > >>> private MavenProject project; > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> @Component > > > > > > > > > > > > >>> private MavenSession session; > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> @Component > > > > > > > > > > > > >>> private MojoExecution mojoExecution; > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> We can use DI with @javax.inject.Inject on fields > > ... > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> @Inject > > > > > > > > > > > > >>> private MavenProject project; > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> @Inject > > > > > > > > > > > > >>> private MavenSession session; > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> @Inject > > > > > > > > > > > > >>> private MojoExecution mojoExecution; > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> And DI with constructor: > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> @Inject > > > > > > > > > > > > >>> public SuperMojo( MavenProject project, > > > MavenSession > > > > > > > > session, > > > > > > > > > > > > >>> MojoExecution execution ) > > > > > > > > > > > > >>> { > > > > > > > > > > > > >>> } > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> Which way should be preferred, which one to > avoid? > > > And > > > > > why? > > > > > > > > > > > > >>> Can we use DI for all Maven components? > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> -- > > > > > > > > > > > > >>> Sławomir Jaranowski > > > > > > > > > > > > >>> > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > Sławomir Jaranowski > > > > > > > > > > > > > > > > > > > > > > > > A master in the art of living draws no sharp > > distinction > > > > > > between > > > > > > > > his > > > > > > > > > > work > > > > > > > > > > > > and his play; his labor and his leisure; his mind and > > his > > > > > body; > > > > > > > his > > > > > > > > > > > > education and his recreation. He hardly knows which > is > > > > which. > > > > > > He > > > > > > > > > simply > > > > > > > > > > > > pursues his vision of excellence through whatever he > is > > > > > doing, > > > > > > > and > > > > > > > > > > leaves > > > > > > > > > > > > others to determine whether he is working or playing. > > To > > > > > > himself, > > > > > > > > he > > > > > > > > > > > always > > > > > > > > > > > > appears to be doing both. > > > > > > > > > > > > > > > > > > > > > > > > -- François-René de Chateaubriand > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > To unsubscribe, e-mail: > > [email protected] > > > > > > > > > > > > For additional commands, e-mail: > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Sławomir Jaranowski > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Sławomir Jaranowski > > > > > > > > -- > Sławomir Jaranowski >
