Le lun. 28 déc. 2020 à 16:44, Markus KARG <mar...@headcrashing.eu> a écrit :
> I don't like the idea of simply keeping javax "and period" as it looks
> like us not moving forward, since people will learn about the history and
> future of that namespace; it is just NOT ours but that of Oracle / JCP /
> EF. We can keep it, but we definitively should add jakarta as an
> alternative.
>
This is not really true, jakarta was allowed (is still ;)) to keep javax
for all the [;8] specs, including jsr330. Jakarta decided to not do that
and add new features in jakarta package but to break the world, their
choice.
In any case, using jakarta is not a sane option for maven (it shouldnt have
used javax as shown by the related threads on the list) so options are
either to revert to plexus API, introduce a new API or just stay like that
which is the less breaking option.
Since this namespace thing does not bring anything for users it sounds
quite fair for me.
What would be your proposed option? jakarta.inject?
To be explicit, here the options I see:
1. jakarta.inject ("forward"?): clearly -1 for the same reasons cdi-api
just got dropped from maven 4
2. plexus: it goes backward ;). Personally i'm not against it, was finding
it saner overall since it is for code in maven/lib but it is literally
about reverting work done.
3. create a new annotation set (kind of 2 but changing the API to look
"forward")
4. javax.inject: status quo, no regression, no user impact nor restriction.
When jakarta.inject will become adopted it will even make it split between
maven and user code/plugins which is good and what we should stick to IMHO.
This is why I think javax can surprisingly be the sanest for maven.
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Gesendet: Montag, 28. Dezember 2020 16:16
> An: Maven Developers List
> Betreff: Re: Maven 4 / @Inject
>
> We can also freeze it, jsr330 never moved and will likely never move (since
> it is the most of the overlapping of underlying vendors) so guess moving to
> jakarta will not halp anything - can only hurt us actually by creating a
> new gap or another "cdi-api" issue - and moving to org.apache.maven will
> require work on maven and all users (which is a ton). I'm also not fan to
> move back to @Requirement/@Component (which is the natural way we would
> solve it I guess since that's what we had before) so maybe just not doing
> anything is a good option. Since we don't use standard jsr330 impl we can
> consider it as part of maven API, period. What do you think?
>
> 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. 28 déc. 2020 à 15:51, Markus KARG <mar...@headcrashing.eu> a
> écrit :
>
> > With "dead" I mean: Nobody is allowed to add anything new in that
> namespace
> > -- neither classes nor interfaces nor even new parameters.
> >
> > I would like that Maven 4 accepts both (old and new namespace).
> >
> > -Markus
> >
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Michael Osipov [mailto:micha...@apache.org]
> > Gesendet: Montag, 28. Dezember 2020 14:59
> > An: dev@maven.apache.org
> > Betreff: Re: Maven 4 / @Inject
> >
> > Am 2020-12-28 um 14:56 schrieb Markus KARG:
> > > We are used to "import javax.inject.*" in Maven, but that namespace if
> > dead
> > > since Jakarta EE 9. Since November the new namespace is released
> "import
> > > jakarta.inject.*". I wonder if Maven 4 really still wants to stick with
> > the
> > > dead namespace instead, or whether it makes sense that we adopt the new
> > > namespace now?
> >
> > That statement is very harsh. Both will co-exist for at least 10 years
> > due to the massive amount of applications in companies. Maven tries to
> > clean up stuff. I think this needs to be spared to Maven 5.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
