Re: Maven 4 / @Inject

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4 / @Inject

Romain Manni-Bucau
I agree javax will stay for years and doing any breaking change today would
just be bad for end users, that said we can already encourage plugins to
not use it and log a warning in maven plugin plugin.
For maven core we don't care much since we can change it when we want, it
will just impact extensions - and I agree again maven 5 can be the time to
do 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 lun. 28 déc. 2020 à 14:59, Michael Osipov <[hidden email]> a écrit :

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4 / @Inject

Slawomir Jaranowski
If you think about such a change - Maven 4 should support both namespaces
with warning about deprecating javax.inject.
In this way developers will have more time and possibility to switch their
plugins/extensions to new namespaces.
Finally Maven 5 can support only new namespaces.

pon., 28 gru 2020 o 15:02 Romain Manni-Bucau <[hidden email]>
napisał(a):

> I agree javax will stay for years and doing any breaking change today would
> just be bad for end users, that said we can already encourage plugins to
> not use it and log a warning in maven plugin plugin.
> For maven core we don't care much since we can change it when we want, it
> will just impact extensions - and I agree again maven 5 can be the time to
> do 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 lun. 28 déc. 2020 à 14:59, Michael Osipov <[hidden email]> a
> écrit :
>
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>


--
Sławomir Jaranowski
Reply | Threaded
Open this post in threaded view
|

Re: Maven 4 / @Inject

Romain Manni-Bucau
In reply to this post by Romain Manni-Bucau
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 <[hidden email]> 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:[hidden email]]
> Gesendet: Montag, 28. Dezember 2020 14:59
> An: [hidden email]
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

AW: Maven 4 / @Inject

Markus KARG-3
Regarding javax: No, this was not the free decision of the Jakarta EE WG, this was the SOLE CHOICE we had due to Oracle, as they forbid ALL changes to the javax namespace, so the were FORCED to rename the workspace. Believe me, nobody in the Jakarta EE WG thought that this is a good idea, but we had no other choice.

Well, we simply have different opinions here. I clearly am +1 for adopting jakarta.inject, simply because it is the de-facto cross-vendor API the major stakeholders agreed upon at the Jakarta EE WG (which, BTW, is free for Apache to join) and it will develop further in future while javax does not, and I do not see why Apache needs to go with something special instead of simply adopting the natural successor IN ADDITION to javax.

I would love if Apache would help making Jakarta a success by adopting it and ACTIVELY influencing it instead of ignoring or fighting it. That will definitively put Apache in a bad situation one day. I do not like the EF, too, but in the end, Oracle dictates Java and the EF dictates post-JEE, so we should simply live with that truth and make the best out of it in a way that most people would just expect.

-Markus


-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:[hidden email]]
Gesendet: Montag, 28. Dezember 2020 17:14
An: Maven Developers List
Betreff: Re: Maven 4 / @Inject

Le lun. 28 déc. 2020 à 16:44, Markus KARG <[hidden email]> 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:[hidden email]]
> 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 <[hidden email]> 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:[hidden email]]
> > Gesendet: Montag, 28. Dezember 2020 14:59
> > An: [hidden email]
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 4 / @Inject

Romain Manni-Bucau
Le lun. 28 déc. 2020 à 17:53, Markus KARG <[hidden email]> a écrit :

> Regarding javax: No, this was not the free decision of the Jakarta EE WG,
> this was the SOLE CHOICE we had due to Oracle, as they forbid ALL changes
> to the javax namespace, so the were FORCED to rename the workspace. Believe
> me, nobody in the Jakarta EE WG thought that this is a good idea, but we
> had no other choice.
>

Factually it is not true, this is also why there was some polls about
keeping javax for existing API and use another namespace for new ones.
This is perfectly legal and oracle had nothing to say about that, just
plain law and it was clearly stated by EE leaders.
Anyway, now jakarta got changed I'm not sure it brings much to the maven
topic so let's put it aside - at least for this thread.


>
> Well, we simply have different opinions here. I clearly am +1 for adopting
> jakarta.inject, simply because it is the de-facto cross-vendor API the
> major stakeholders agreed upon at the Jakarta EE WG (which, BTW, is free
> for Apache to join) and it will develop further in future while javax does
> not, and I do not see why Apache needs to go with something special instead
> of simply adopting the natural successor IN ADDITION to javax.
>

Ok, so on this clearly -1, not because of jakarta but because maven must
not import in its leaked core classpath libs plugins can use (this is
structural and always bites us for a few libs).
This is not about Apache but Maven design as explained in previous messages.

Also note that Maven does not use the spec, it uses the API with an
implementation which is unrelated to the spec so it is bad already and
better to not make it worse faking to move to the new spec too.


>
> I would love if Apache would help making Jakarta a success by adopting it
> and ACTIVELY influencing it instead of ignoring or fighting it. That will
> definitively put Apache in a bad situation one day. I do not like the EF,
> too, but in the end, Oracle dictates Java and the EF dictates post-JEE, so
> we should simply live with that truth and make the best out of it in a way
> that most people would just expect.
>

We do Markus, not sure you noticed but several EE impl already provide
jakarta flavors from openwebbeans to tomee without forgetting johnzon and a
few others.
But for maven the topic is really structurally different.


>
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:[hidden email]]
> Gesendet: Montag, 28. Dezember 2020 17:14
> An: Maven Developers List
> Betreff: Re: Maven 4 / @Inject
>
> Le lun. 28 déc. 2020 à 16:44, Markus KARG <[hidden email]> 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:[hidden email]]
> > 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 <[hidden email]> 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:[hidden email]]
> > > Gesendet: Montag, 28. Dezember 2020 14:59
> > > An: [hidden email]
> > > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>