You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Gurkan Erdogdu <cg...@gmail.com> on 2020/06/07 08:25:49 UTC
Jakarta EE 9 Support
Hi
After the 2.x release, can we get the master to 3.0.0 to support upcoming
Jakarta EE 9 release with jakarta.* namespace?
I also favor to use the Jakarta EE CDI API instead of using the Apache
based api.
Regards
Gurkan
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 7 juin 2020 à 19:47, Gurkan Erdogdu <cg...@gmail.com> a
écrit :
> >
> > Tomcat works with branches since years without any issue.
> > All projects we tried to use branches we abandoned branches just after
> > having done them.
> > It is fine if the old branch is no more used but here we know we will
> > maintain javax branch more than jakarta one for some time so I think we
> > should avoid it while it is not justified or one of the 2 branches
> (javax)
> > is "almost dead".
>
> Working with branches always happens in all open source projects. And
> there are times when it is logical to create the branch. Jakarta EE 9 API
> migration is the best time to create such a branch. Eventually, we will
> create such a branch in Jakarta EE 10.
>
All the point is in your eventually, there is nothing certain but the cost
is known upfront, not the gain whereas today we gain on both side, just
facts. We can revise this anytime if anything changes as mentionned.
>
> Fact there will be no more javax is useless IMHO, only question we should
> > care about is "do we have javax users?" and should we work on javax
> branch
> > enough to care about having 2 duplicate branches. Answer is obviously yes
> > and more than jakarta users today, therefore I think for some months
> (maybe
> > a few years) we should stick to javax as our primary branch and ensure
> the
> > alignments and bugfixes can trivially - == without any action from dev -
> be
> > ported. It is what we have today.
> >
> What could be more natural than maintaining branches (with backporting from
> master only if necessary). With Jakarta EE 10, we will eventually create
> the branch for supporting the EE 8. Also, for the release versioning, it is
> nice to have a 3.x release. The community will notice that 3.x is the
> starting point of Jakarta EE support. Will you release 2.x with the
> intention of supporting Jakarta EE 9? I am personally not positive on this.
> I think, 3.x release will also get more interest even if the functionality
> and API stay the same. We can prepare the press release for it.
>
versioning is not linked to branches, we can do a 3 because we passed
officially jakarta 9 tck, nothing linked to code/scm organization.
>
> Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
> > nor as transitive dep so this change must stay a noop for consumers).
> >
> What is the problem of depending on the official Jakarta EE CDI API? It is
> an Apache friendly license. Instead of maintaining the Geronimo CDI API
> internally, it is more logical to use Jakarta EE official CDI API and
> maintain this API with EE4J community.
>
> would also appreciate if you do a vote if you can point out the breaking
> > changes - except the package renaming - justifying to fork ourself and
> what
> > does not work with current solution, can ease the decision/vote.
> > Today using jakarta/EE9 API is quite easy (
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > ).
> > We should absolutely enhance the pom experience though but it is trivial
> to
> > do at maven level - I was envisionning to do it in shade plugin to be
> more
> > precise.
> >
> I know that there will be no functional change. But, I am also against
> shading for jakarta.*. If there will be no change on Jakarta EE 10, will we
> continue to shade? What happens when there will be a change in EJB, JMS
> etc specifications but no change in CDI in Jakarta EE 10? Also, VOTING is
> the natural thing to do for the community decision. If the community would
> like to keep it as it is via shading, it is fine.
>
What happens? it works today, just give it a try, Thomas did support jsf
stack with this solution and btw tomee runs fine like that too - it is just
not upstream.
Why would it change anything?
These inegrations are not in OWB anyway (the modules we have don't work for
EE and poorly work in standalone since it does not respect the spec
properly).
Not sure what you are thinking about but this is not an issue. Also note
that the integration can be superseeded with recent OWB SPI (injection one
in particular).
>
> >
> > To try to rephrase/clarify my questionning today: you ask for jakarta
> > support, we already have it in a dev and project efficient way so why
> > should we change since I don't hink there is anything new - once again if
> > API starts to fully break discussion is different but github doesnt
> reflect
> > that?
> >
> This is not just for Jakarta EE 9 support. As we know, there will be no API
> (functional) change, only package renaming. But, I want to emphasize that
> with such turning points, it is so logical to integrate official Jakarta
> CDI API into our master (removing the geronimo-cdi), and release our new
> 3.x version and let the public know that OWB supports official CDI API
> beginning with 3.x release. Yeah, shading is an option for package renaming
> but think long term. Also, I am really against the shading. It really
> disturbs the users which depend on OWB implementation. For example,
> currently Glassfish supports Weld integration but one can also implement
> OWB to replace Weld in Glassfish. Therefore, instead of using the shaded
> version, it is really important to have the full Jakarta EE CDI API in our
> poms. You will still have javax.* dependency in ur POMs even if doing a
> shade. This is not good idea to still maintain javax.* in our POM files.
>
Why we keep geronimo spec jas? cause they enable us to support properly
OSGi and our defaults, nothing will change on that.
It is NOT important to build against jakarta artifacts - and will likely
not happen, it is important to have the right manifest in our spec jars and
if it is not the case we must fix it.
I don't understand why you said "You will still have javax.* dependency in
ur POMs even if doing a shade". We fix shade plugin for that, we just need
to configure it I think.
Do you have any fact where branching is needed and costs less in time than
shading for the coming years?
>
> What are other opinions before formal voting?
> Regards.
> Gurkan
>
>
>
> On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <cg...@gmail.com> a
> > écrit :
> >
> > > Tomcat created branch 10 for jakarta ee 9. Glassfish is also on master.
> > >
> >
> > Tomcat works with branches since years without any issue.
> > All projects we tried to use branches we abandoned branches just after
> > having done them.
> > It is fine if the old branch is no more used but here we know we will
> > maintain javax branch more than jakarta one for some time so I think we
> > should avoid it while it is not justified or one of the 2 branches
> (javax)
> > is "almost dead".
> >
> >
> > > sorry but not understand the resistance on this? will you always shade
> ?
> > >
> >
> > As mentionned, until API needs changes we can't easily handle - today
> there
> > is no change.
> >
> >
> > > creating the new master and maintain the 2.x branch, is the best
> logical
> > > way. there will be no javax.* any more. Tomcat maintains 3 branches
> and
> > 1
> > > master. only maintains 1 branch and 1 master is totally fine.
> > >
> >
> > Fact there will be no more javax is useless IMHO, only question we should
> > care about is "do we have javax users?" and should we work on javax
> branch
> > enough to care about having 2 duplicate branches. Answer is obviously yes
> > and more than jakarta users today, therefore I think for some months
> (maybe
> > a few years) we should stick to javax as our primary branch and ensure
> the
> > alignments and bugfixes can trivially - == without any action from dev -
> be
> > ported. It is what we have today.
> >
> >
> > >
> > > I will propose a vote shortly to decide on to create a master with 3.x
> > with
> > > fully support of jakarta with a normal pom dependency with jakarta api.
> > >
> >
> > Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
> > nor as transitive dep so this change must stay a noop for consumers).
> > I would also appreciate if you do a vote if you can point out the
> breaking
> > changes - except the package renaming - justifying to fork ourself and
> what
> > does not work with current solution, can ease the decision/vote.
> > Today using jakarta/EE9 API is quite easy (
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > ).
> > We should absolutely enhance the pom experience though but it is trivial
> to
> > do at maven level - I was envisionning to do it in shade plugin to be
> more
> > precise.
> >
> > To try to rephrase/clarify my questionning today: you ask for jakarta
> > support, we already have it in a dev and project efficient way so why
> > should we change since I don't hink there is anything new - once again if
> > API starts to fully break discussion is different but github doesnt
> reflect
> > that?
> >
> >
> > >
> > > Regs
> > > Gurkan
> > >
> > >
> > > On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <rm...@gmail.com>
> > > wrote:
> > >
> > > > Today we don't need, tomorrow I don't know but while API does not
> > change
> > > > (except the package) we shouldn't fork ourself IMHO (cause it is what
> > you
> > > > propose as a consequence).
> > > > If it becomes necessary let's do it but my vote is to stay lazy on
> > that.
> > > >
> > > >
> > > > side note for G API discussion belongs to dev@G but it is less an
> > issue
> > > to
> > > > fork from now since we rarely update the API, the side note here is
> > that
> > > > CDI SE is already fully runnable on ASF stack with jakarta package
> > since
> > > > some weeks or months, we did all the needed releases.
> > > >
> > > > 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > > > andraschko.thomas@gmail.com>
> > > > a écrit :
> > > >
> > > > > AFAIR we dont need it as we shade a -jakarta.jar via our build.
> > > > > As EE9 just changes the namespace, it's perfectly fine.
> > > > >
> > > > > I'm actually also a supporter of doing a hard cut but it's not
> > required
> > > > and
> > > > > we can do it for EE 10.
> > > > >
> > > > > <
> > > > >
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > > >
> > > > > Virenfrei.
> > > > > www.avast.com
> > > > > <
> > > > >
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > > >
> > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > >
> > > > > Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> > > > > cgurkanerdogdu@gmail.com>:
> > > > >
> > > > > > We need to maintain two branches
> > > > > >
> > > > > > EE 8 for javax.* package 2.x branch
> > > > > > EE 9 for jakarta.* package 3.x master
> > > > > >
> > > > > > On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'll probably restate my position on that: if EE 9 brings
> > > > > significatively
> > > > > > > new API yes - a quick review shows it is 1-1 with EE 8 but I
> can
> > > have
> > > > > > > missed sthg, looked quite fast. if EE9==EE8 then we can stay as
> > we
> > > > are
> > > > > I
> > > > > > > think avoiding to maintain two branches we can't merge
> regularly.
> > > > > > >
> > > > > > > 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > > > cgurkanerdogdu@gmail.com>
> > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > Hi
> > > > > > > > After the 2.x release, can we get the master to 3.0.0 to
> > support
> > > > > > upcoming
> > > > > > > > Jakarta EE 9 release with jakarta.* namespace?
> > > > > > > >
> > > > > > > > I also favor to use the Jakarta EE CDI API instead of using
> the
> > > > > Apache
> > > > > > > > based api.
> > > > > > > > Regards
> > > > > > > > Gurkan
> > > > > > > >
> > > > > > > > --
> > > > > > > > Gurkan Erdogdu
> > > > > > > > http://gurkanerdogdu.blogspot.com
> > > > > > > >
> > > > > > >
> > > > > > --
> > > > > > Gurkan Erdogdu
> > > > > > http://gurkanerdogdu.blogspot.com
> > > > > >
> > > > >
> > > >
> > > --
> > > Gurkan Erdogdu
> > > http://gurkanerdogdu.blogspot.com
> > >
> >
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
PS: for ref, the original thread on this topic
https://markmail.org/message/76uveuuvvhxx6b3v
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 dim. 7 juin 2020 à 20:25, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
>
>
> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cg...@gmail.com> a
> écrit :
>
>> Hi David
>>
>> I’m not sure exactly how it impacts this decision, but IIUC the geronimo
>> > cdi spec jar is rather essential for some uses as it has OSGI support
>> > whereas IIUC the eclipse/jakarta one doesn’t.
>> >
>> No, it is not correct. It has OSGI support. GlassFish is an OSGI based
>> server.You can grap the code from https://github.com/eclipse-ee4j/cdi and
>> build. It has OSGI enabled MANIFEST.MF file.
>>
>
> Not, it is not correct Gurkan ;).
> jakarta does NOT support OSGi properly, it does it the old way and break
> several rules. For instance last CDI spec jar contains:
>
> Manifest-Version: 1.0
> Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
> r Java)
> Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
> Bundle-SymbolicName: jakarta.enterprise.cdi-api
> Built-By: default
> Bnd-LastModified: 1590678420932
> Bundle-ManifestVersion: 2
> Bundle-DocURL: https://jboss.org
> Bundle-Vendor: JBoss by Red Hat, Inc.
> Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> 3)",jakarta.interceptor;version="[2.0,3)"
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Tool: Bnd-2.4.1.201501161923
> Originally-Created-By: Apache Maven Bundle Plugin
> Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> ise.util",jakarta.enterprise.util;version="3.0"
> Bundle-Name: CDI APIs
> Bundle-Version: 3.0.0.M4
> Build-Jdk-Spec: 1.8
> Created-By: Apache Maven Bundle Plugin
> Build-Jdk: 1.8.0_202
>
> Where are the osgi.serviceloader and osgi.contract ?
> This is important and used by OSGi-CDI for example (even if it can be
> worked around).
>
> So to conclude on this point not belonging to OWB, we still need our fork
> and eclipse always answered saying "yes we want OSGi [but we don't really
> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> work on that factually so OSGi is done at minimal cost.
>
>
>>
>> Gurkan’s proposal will only add difficulty for developers and probably
>> > users.
>> >
>> What is the difficulty? The change will only affect maintaining the
>> javax.*
>> branch and fully renamed jakarta.* dependencies in master.
>>
>
> Ok Gurkan, let's be concrete, do you - you as you personally - accept and
> commit yourself to port any commit to one of the two branches to the other
> for all the time the project is at apache?
> if so fine, if not -1 to create us unneeded (+ still unjustified by facts)
> work.
>
>
>>
>> Regards.
>> Gurkan
>>
>> On Sun, Jun 7, 2020 at 8:58 PM David Jencks <da...@gmail.com>
>> wrote:
>>
>> > I’m not sure exactly how it impacts this decision, but IIUC the geronimo
>> > cdi spec jar is rather essential for some uses as it has OSGI support
>> > whereas IIUC the eclipse/jakarta one doesn’t.
>> >
>> > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT
>> Gurkan’s
>> > proposal will only add difficulty for developers and probably users.
>> > Although I haven’t been active here for years I might even vote.
>> >
>> > thanks
>> > David Jencks
>> >
>> > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <cgurkanerdogdu@gmail.com
>> >
>> > wrote:
>> > >
>> > >>
>> > >> Tomcat works with branches since years without any issue.
>> > >> All projects we tried to use branches we abandoned branches just
>> after
>> > >> having done them.
>> > >> It is fine if the old branch is no more used but here we know we will
>> > >> maintain javax branch more than jakarta one for some time so I think
>> we
>> > >> should avoid it while it is not justified or one of the 2 branches
>> > (javax)
>> > >> is "almost dead".
>> > >
>> > > Working with branches always happens in all open source projects. And
>> > > there are times when it is logical to create the branch. Jakarta EE 9
>> API
>> > > migration is the best time to create such a branch. Eventually, we
>> will
>> > > create such a branch in Jakarta EE 10.
>> > >
>> > > Fact there will be no more javax is useless IMHO, only question we
>> should
>> > >> care about is "do we have javax users?" and should we work on javax
>> > branch
>> > >> enough to care about having 2 duplicate branches. Answer is obviously
>> > yes
>> > >> and more than jakarta users today, therefore I think for some months
>> > (maybe
>> > >> a few years) we should stick to javax as our primary branch and
>> ensure
>> > the
>> > >> alignments and bugfixes can trivially - == without any action from
>> dev
>> > - be
>> > >> ported. It is what we have today.
>> > >>
>> > > What could be more natural than maintaining branches (with backporting
>> > from
>> > > master only if necessary). With Jakarta EE 10, we will eventually
>> create
>> > > the branch for supporting the EE 8. Also, for the release versioning,
>> it
>> > is
>> > > nice to have a 3.x release. The community will notice that 3.x is the
>> > > starting point of Jakarta EE support. Will you release 2.x with the
>> > > intention of supporting Jakarta EE 9? I am personally not positive on
>> > this.
>> > > I think, 3.x release will also get more interest even if the
>> > functionality
>> > > and API stay the same. We can prepare the press release for it.
>> > >
>> > > Note we shouldn't depend on jakarta/javax api anyway (neither as
>> groupId
>> > >> nor as transitive dep so this change must stay a noop for consumers).
>> > >>
>> > > What is the problem of depending on the official Jakarta EE CDI API?
>> It
>> > is
>> > > an Apache friendly license. Instead of maintaining the Geronimo CDI
>> API
>> > > internally, it is more logical to use Jakarta EE official CDI API and
>> > > maintain this API with EE4J community.
>> > >
>> > > would also appreciate if you do a vote if you can point out the
>> breaking
>> > >> changes - except the package renaming - justifying to fork ourself
>> and
>> > what
>> > >> does not work with current solution, can ease the decision/vote.
>> > >> Today using jakarta/EE9 API is quite easy (
>> > >>
>> >
>> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
>> > >> ).
>> > >> We should absolutely enhance the pom experience though but it is
>> > trivial to
>> > >> do at maven level - I was envisionning to do it in shade plugin to be
>> > more
>> > >> precise.
>> > >>
>> > > I know that there will be no functional change. But, I am also against
>> > > shading for jakarta.*. If there will be no change on Jakarta EE 10,
>> will
>> > we
>> > > continue to shade? What happens when there will be a change in EJB,
>> JMS
>> > > etc specifications but no change in CDI in Jakarta EE 10? Also,
>> VOTING is
>> > > the natural thing to do for the community decision. If the community
>> > would
>> > > like to keep it as it is via shading, it is fine.
>> > >
>> > >>
>> > >> To try to rephrase/clarify my questionning today: you ask for jakarta
>> > >> support, we already have it in a dev and project efficient way so why
>> > >> should we change since I don't hink there is anything new - once
>> again
>> > if
>> > >> API starts to fully break discussion is different but github doesnt
>> > reflect
>> > >> that?
>> > >>
>> > > This is not just for Jakarta EE 9 support. As we know, there will be
>> no
>> > API
>> > > (functional) change, only package renaming. But, I want to emphasize
>> that
>> > > with such turning points, it is so logical to integrate official
>> Jakarta
>> > > CDI API into our master (removing the geronimo-cdi), and release our
>> new
>> > > 3.x version and let the public know that OWB supports official CDI API
>> > > beginning with 3.x release. Yeah, shading is an option for package
>> > renaming
>> > > but think long term. Also, I am really against the shading. It really
>> > > disturbs the users which depend on OWB implementation. For example,
>> > > currently Glassfish supports Weld integration but one can also
>> implement
>> > > OWB to replace Weld in Glassfish. Therefore, instead of using the
>> shaded
>> > > version, it is really important to have the full Jakarta EE CDI API in
>> > our
>> > > poms. You will still have javax.* dependency in ur POMs even if doing
>> a
>> > > shade. This is not good idea to still maintain javax.* in our POM
>> files.
>> > >
>> > > What are other opinions before formal voting?
>> > > Regards.
>> > > Gurkan
>> > >
>> > >
>> > >
>> > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com
>> > >
>> > > wrote:
>> > >
>> > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
>> cgurkanerdogdu@gmail.com>
>> > a
>> > >> écrit :
>> > >>
>> > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on
>> master.
>> > >>>
>> > >>
>> > >> Tomcat works with branches since years without any issue.
>> > >> All projects we tried to use branches we abandoned branches just
>> after
>> > >> having done them.
>> > >> It is fine if the old branch is no more used but here we know we will
>> > >> maintain javax branch more than jakarta one for some time so I think
>> we
>> > >> should avoid it while it is not justified or one of the 2 branches
>> > (javax)
>> > >> is "almost dead".
>> > >>
>> > >>
>> > >>> sorry but not understand the resistance on this? will you always
>> shade
>> > ?
>> > >>>
>> > >>
>> > >> As mentionned, until API needs changes we can't easily handle - today
>> > there
>> > >> is no change.
>> > >>
>> > >>
>> > >>> creating the new master and maintain the 2.x branch, is the best
>> > logical
>> > >>> way. there will be no javax.* any more. Tomcat maintains 3 branches
>> > and
>> > >> 1
>> > >>> master. only maintains 1 branch and 1 master is totally fine.
>> > >>>
>> > >>
>> > >> Fact there will be no more javax is useless IMHO, only question we
>> > should
>> > >> care about is "do we have javax users?" and should we work on javax
>> > branch
>> > >> enough to care about having 2 duplicate branches. Answer is obviously
>> > yes
>> > >> and more than jakarta users today, therefore I think for some months
>> > (maybe
>> > >> a few years) we should stick to javax as our primary branch and
>> ensure
>> > the
>> > >> alignments and bugfixes can trivially - == without any action from
>> dev
>> > - be
>> > >> ported. It is what we have today.
>> > >>
>> > >>
>> > >>>
>> > >>> I will propose a vote shortly to decide on to create a master with
>> 3.x
>> > >> with
>> > >>> fully support of jakarta with a normal pom dependency with jakarta
>> api.
>> > >>>
>> > >>
>> > >> Note we shouldn't depend on jakarta/javax api anyway (neither as
>> groupId
>> > >> nor as transitive dep so this change must stay a noop for consumers).
>> > >> I would also appreciate if you do a vote if you can point out the
>> > breaking
>> > >> changes - except the package renaming - justifying to fork ourself
>> and
>> > what
>> > >> does not work with current solution, can ease the decision/vote.
>> > >> Today using jakarta/EE9 API is quite easy (
>> > >>
>> >
>> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
>> > >> ).
>> > >> We should absolutely enhance the pom experience though but it is
>> > trivial to
>> > >> do at maven level - I was envisionning to do it in shade plugin to be
>> > more
>> > >> precise.
>> > >>
>> > >> To try to rephrase/clarify my questionning today: you ask for jakarta
>> > >> support, we already have it in a dev and project efficient way so why
>> > >> should we change since I don't hink there is anything new - once
>> again
>> > if
>> > >> API starts to fully break discussion is different but github doesnt
>> > reflect
>> > >> that?
>> > >>
>> > >>
>> > >>>
>> > >>> Regs
>> > >>> Gurkan
>> > >>>
>> > >>>
>> > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > >>> wrote:
>> > >>>
>> > >>>> Today we don't need, tomorrow I don't know but while API does not
>> > >> change
>> > >>>> (except the package) we shouldn't fork ourself IMHO (cause it is
>> what
>> > >> you
>> > >>>> propose as a consequence).
>> > >>>> If it becomes necessary let's do it but my vote is to stay lazy on
>> > >> that.
>> > >>>>
>> > >>>>
>> > >>>> side note for G API discussion belongs to dev@G but it is less an
>> > >> issue
>> > >>> to
>> > >>>> fork from now since we rarely update the API, the side note here is
>> > >> that
>> > >>>> CDI SE is already fully runnable on ASF stack with jakarta package
>> > >> since
>> > >>>> some weeks or months, we did all the needed releases.
>> > >>>>
>> > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
>> > >>>> andraschko.thomas@gmail.com>
>> > >>>> a écrit :
>> > >>>>
>> > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our build.
>> > >>>>> As EE9 just changes the namespace, it's perfectly fine.
>> > >>>>>
>> > >>>>> I'm actually also a supporter of doing a hard cut but it's not
>> > >> required
>> > >>>> and
>> > >>>>> we can do it for EE 10.
>> > >>>>>
>> > >>>>> <
>> > >>>>>
>> > >>>>
>> > >>>
>> > >>
>> >
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>> > >>>>>>
>> > >>>>> Virenfrei.
>> > >>>>> www.avast.com
>> > >>>>> <
>> > >>>>>
>> > >>>>
>> > >>>
>> > >>
>> >
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>> > >>>>>>
>> > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> > >>>>>
>> > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
>> > >>>>> cgurkanerdogdu@gmail.com>:
>> > >>>>>
>> > >>>>>> We need to maintain two branches
>> > >>>>>>
>> > >>>>>> EE 8 for javax.* package 2.x branch
>> > >>>>>> EE 9 for jakarta.* package 3.x master
>> > >>>>>>
>> > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
>> > >> rmannibucau@gmail.com
>> > >>>>
>> > >>>>>> wrote:
>> > >>>>>>
>> > >>>>>>> Hi,
>> > >>>>>>>
>> > >>>>>>> I'll probably restate my position on that: if EE 9 brings
>> > >>>>> significatively
>> > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but I can
>> > >>> have
>> > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can stay as
>> > >> we
>> > >>>> are
>> > >>>>> I
>> > >>>>>>> think avoiding to maintain two branches we can't merge
>> regularly.
>> > >>>>>>>
>> > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
>> > >>>> cgurkanerdogdu@gmail.com>
>> > >>>>> a
>> > >>>>>>> écrit :
>> > >>>>>>>
>> > >>>>>>>> Hi
>> > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
>> > >> support
>> > >>>>>> upcoming
>> > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
>> > >>>>>>>>
>> > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of using the
>> > >>>>> Apache
>> > >>>>>>>> based api.
>> > >>>>>>>> Regards
>> > >>>>>>>> Gurkan
>> > >>>>>>>>
>> > >>>>>>>> --
>> > >>>>>>>> Gurkan Erdogdu
>> > >>>>>>>> http://gurkanerdogdu.blogspot.com
>> > >>>>>>>>
>> > >>>>>>>
>> > >>>>>> --
>> > >>>>>> Gurkan Erdogdu
>> > >>>>>> http://gurkanerdogdu.blogspot.com
>> > >>>>>>
>> > >>>>>
>> > >>>>
>> > >>> --
>> > >>> Gurkan Erdogdu
>> > >>> http://gurkanerdogdu.blogspot.com
>> > >>>
>> > >>
>> > >
>> > >
>> > > --
>> > > Gurkan Erdogdu
>> > > http://gurkanerdogdu.blogspot.com
>> >
>> >
>>
>> --
>> Gurkan Erdogdu
>> http://gurkanerdogdu.blogspot.com
>>
>
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 10 juin 2020 à 11:18, Gurkan Erdogdu <cg...@gmail.com> a
écrit :
> >
> > When required we'll do, today there is really nothing justifying it.
>
> If one integrates the OWB via POM dependency in his jakarta project, it is
> a problem to see javax.* everywhere in OWB POM files. He needs to solve
> problems via some exotic POM operations. For example, I did not able to
> run TEstNG
>
Don't think both are correlated. Typically it is done in jakarta tck module
and it is not crazy.
Same happens when you integrate it in an app or even tomee, nothing fancy
or undoable.
Now the fact the IDE is lost in some cases is something else...but keep in
mind you don't have code in owb for that so you shouldn't need to code
there.
> Probably, you will do it shortly because Jakarta EE 10 will start
>
To be honest I don't know yet. I'm not sure CDI needs new features,
clarifications for sure but seems it is a solid IoC and adding to CDI is
not really promishing a future to EE (it is more about using it as a
backbone and adding services/interceptors in other specs).
Future will say I think ;).
> Anyway, keep the good work. Also, we need to extend the community around
> OWB. Community projects grow with community and decisions are made by the
> community.
>
I agree and as with any EE issue, the main problem we are facing is that
there are mainly activity only with new spec release (and big changes), in
between we prooved to be stable enough to not attract people - which is
"normal".
Even small tools like jupiter integration is good enough to not need more.
I suspect we should probably work toward more noise about our hidden
features like our CDI SE main (really nice for batches apps), our testing
tooling with its optimizations (reusable), and work more about tooling like
graalsupport which is not trivial to impl (think Alex will tackle that this
summer ;)).
I'm not sure - and not the best one - to drive a comm track but it is
likely what we can miss the most today IMHO.
That said, weld too - which has for it the fact to be the RI - does not
have much PR so guess there wouldn't be any miracle but attracting more
users is good anyway, and discussion can lead to improving us which is
positive in all cases.
Hope it makes sense.
> Gurkan
>
>
> On Wed, Jun 10, 2020 at 12:08 PM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > Le mer. 10 juin 2020 à 09:55, Gurkan Erdogdu <cg...@gmail.com>
> a
> > écrit :
> >
> > > This javax to jakarta has already created problems in running for
> example
> > > TestNG tests in eclipse :)
> > > Also, keep in mind that OWB also depends on several Geronimo EE APIs
> and
> > > must be sure that there is no String usage of javax. in any of these
> > APIs.
> > >
> >
> > We did :)
> >
> >
> > > I am still not convinced of using shaded artifacts. For me the best
> thing
> > > is to do one big single conversion from javax. to jakarta. and create a
> > > branch and also using Jakarta EE APIs. I don't see any reason to use
> > > Geronimo APIs. (except some simple OSGI artifacts)
> > >
> >
> > Well in front of that I can say "I don't see any reason to use jakarta
> > artifacts".
> > Both are true except we control G ones, we don't control jakarta one and
> it
> > happens they have bugs.
> > We - at asf - also generally run with G ones so it is better to harness G
> > ones than jakarta ones.
> > It is not a big +1 for G but a +0.1 and -0.1 for jakarta.
> > Finally, since we don't really provide these artifacts in owb itself it
> > does not change anything but we do in meecrowave (an owb project - and
> here
> > it is not a choice since we must have the right defaults) so it is
> > consistent to use the same accross projects of the same family IMHO.
> >
> >
> > > As I see, there are no other opinions, I will not create a VOTE for
> this
> > > and keep this way. But, it will finally need to be done.
> > >
> >
> > When required we'll do, today there is really nothing justifying it.
> >
> >
> > > Gurkan
> > >
> > >
> > > On Mon, Jun 8, 2020 at 12:40 PM Thomas Andraschko <
> > > andraschko.thomas@gmail.com> wrote:
> > >
> > > > Nice work romain!
> > > >
> > > > Am Mo., 8. Juni 2020 um 11:29 Uhr schrieb Romain Manni-Bucau <
> > > > rmannibucau@gmail.com>:
> > > >
> > > > > FYI we run jakarta tck now with
> > > > > https://issues.apache.org/jira/browse/OWB-1327
> > > > > As expected it works fine
> > > > >
> > > > > 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. 8 juin 2020 à 08:33, Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > > a
> > > > > écrit :
> > > > >
> > > > > >
> > > > > >
> > > > > > Le dim. 7 juin 2020 à 20:48, Gurkan Erdogdu <
> > > cgurkanerdogdu@gmail.com>
> > > > a
> > > > > > écrit :
> > > > > >
> > > > > >> > Not, it is not correct Gurkan ;).
> > > > > >> > jakarta does NOT support OSGi properly, it does it the old way
> > and
> > > > > break
> > > > > >> > several rules. For instance last CDI spec jar contains:
> > > > > >>
> > > > > >> As I said in my previous email, I am not an OSGI expert. But,
> > what I
> > > > can
> > > > > >> do
> > > > > >> is that I can ping the CDI team in EE4J to add features to
> support
> > > > > >> OWB-OSGI
> > > > > >> or other ASF projects? Could you explain in detail?
> > > > > >>
> > > > > >
> > > > > > OSGi-CDI not OWB-CDI, it is an OSGi spec ;)
> > > > > > It is mainly the metadata.
> > > > > > Point is we already contacted the spec leaders, even for
> > Microprofile
> > > > if
> > > > > > you want to get the full story (same people more or less) and it
> > > didn't
> > > > > go
> > > > > > well enough even if people were willing to do it.
> > > > > > So factually today it is saner to keep it here and it is not an
> > issue
> > > > for
> > > > > > G project anyway since we do it for years and we will keep doing
> it
> > > for
> > > > > > defaults at least.
> > > > > > Once again not an OWB discussion and decision had been taken
> > already
> > > on
> > > > > > this one so don't want to loop on the same topic again and again,
> > in
> > > > > > particular from the wrong list ;).
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> Regards.
> > > > > >> Gurkan
> > > > > >>
> > > > > >> On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu <
> > > > cgurkanerdogdu@gmail.com
> > > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > So to conclude on this point not belonging to OWB, we still
> need
> > > our
> > > > > >> fork
> > > > > >> >> and eclipse always answered saying "yes we want OSGi [but we
> > > don't
> > > > > >> really
> > > > > >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but
> > they
> > > > > don't
> > > > > >> >> work on that factually so OSGi is done at minimal cost.
> > > > > >> >
> > > > > >> > OK thanks for the clarification. I am not an OSGI expert.
> > > > > >> >
> > > > > >> > Ok Gurkan, let's be concrete, do you - you as you personally -
> > > > accept
> > > > > >> and
> > > > > >> >> commit yourself to port any commit to one of the two branches
> > to
> > > > the
> > > > > >> other
> > > > > >> >> for all the time the project is at apache?
> > > > > >> >> if so fine, if not -1 to create us unneeded (+ still
> > unjustified
> > > by
> > > > > >> facts)
> > > > > >> >> work.
> > > > > >> >
> > > > > >> > :=)
> > > > > >> > Hey, I'm just proposing what I think about. If nobody cares
> > about
> > > > it
> > > > > or
> > > > > >> > is not beneficial, it is ok, and also there is no need to VOTE
> > > (This
> > > > > is
> > > > > >> why
> > > > > >> > I'd like to get more opinions on it). But look at Weld, they
> did
> > > the
> > > > > >> > update, https://github.com/weld and full of updating their
> pom
> > to
> > > > use
> > > > > >> > jakarta.*
> > > > > >> >
> > > > > >> > Currently all of the OWB modules (webbeans-ee, webbeans-el22
> > etc),
> > > > use
> > > > > >> > geronimo-...specs which depend on javax.*. Today or tomorrow,
> > we
> > > > will
> > > > > >> > eventually move to jakarta.* namespace. Instead of working
> with
> > > > such
> > > > > >> > shading plugin stuff as a workaround, I just offer to take the
> > > > master
> > > > > to
> > > > > >> > jakarta.* and update all OWB modules' dependency from javax.*
> > to
> > > > > >> jakarta.*
> > > > > >> > official APIS. This is not related to who will maintain the
> > > > branches.
> > > > > >> You
> > > > > >> > know that ASF works as a voluntary based approach. You can not
> > > push
> > > > > >> anybody
> > > > > >> > to work on anything as in commercial companies.
> > > > > >> >
> > > > > >> > Also, regarding the cost and energy you mention to maintain
> the
> > > > > branch,
> > > > > >> > via Geronimo specs, you will need to update all of the
> Geronimo
> > > > Specs
> > > > > >> and
> > > > > >> > maintain them. I think this is not rational because now,
> > jakarta.*
> > > > > >> official
> > > > > >> > API license is EPL and Apache friendly. Why do I need to
> > maintain
> > > > for
> > > > > >> > example Geronimo EL?
> > > > > >> >
> > > > > >> > Regards.
> > > > > >> > Gurkan
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <
> > > > > >> rmannibucau@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <
> > > > > cgurkanerdogdu@gmail.com>
> > > > > >> a
> > > > > >> >> écrit :
> > > > > >> >>
> > > > > >> >> > Hi David
> > > > > >> >> >
> > > > > >> >> > I’m not sure exactly how it impacts this decision, but IIUC
> > the
> > > > > >> geronimo
> > > > > >> >> > > cdi spec jar is rather essential for some uses as it has
> > OSGI
> > > > > >> support
> > > > > >> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > > > > >> >> > >
> > > > > >> >> > No, it is not correct. It has OSGI support. GlassFish is an
> > > OSGI
> > > > > >> based
> > > > > >> >> > server.You can grap the code from
> > > > > >> https://github.com/eclipse-ee4j/cdi
> > > > > >> >> and
> > > > > >> >> > build. It has OSGI enabled MANIFEST.MF file.
> > > > > >> >> >
> > > > > >> >>
> > > > > >> >> Not, it is not correct Gurkan ;).
> > > > > >> >> jakarta does NOT support OSGi properly, it does it the old
> way
> > > and
> > > > > >> break
> > > > > >> >> several rules. For instance last CDI spec jar contains:
> > > > > >> >>
> > > > > >> >> Manifest-Version: 1.0
> > > > > >> >> Bundle-Description: APIs for CDI (Contexts and Dependency
> > > Injection
> > > > > fo
> > > > > >> >> r Java)
> > > > > >> >> Bundle-License:
> > > > https://repository.jboss.org/licenses/apache-2.0.txt
> > > > > >> >> Bundle-SymbolicName: jakarta.enterprise.cdi-api
> > > > > >> >> Built-By: default
> > > > > >> >> Bnd-LastModified: 1590678420932
> > > > > >> >> Bundle-ManifestVersion: 2
> > > > > >> >> Bundle-DocURL: https://jboss.org
> > > > > >> >> Bundle-Vendor: JBoss by Red Hat, Inc.
> > > > > >> >> Import-Package:
> > > > > jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> > > > > >> >> 3)",jakarta.interceptor;version="[2.0,3)"
> > > > > >> >> Require-Capability: osgi.ee;filter:="(&(osgi.ee
> > > > > =JavaSE)(version=1.8))"
> > > > > >> >> Tool: Bnd-2.4.1.201501161923
> > > > > >> >> Originally-Created-By: Apache Maven Bundle Plugin
> > > > > >> >> Export-Package:
> > > > > jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> > > > > >> >>
> > > > >
> ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> > > > > >> >>
> > > > >
> nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> > > > > >> >>
> > > > >
> sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> > > > > >> >>
> > > > >
> arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> > > > > >> >>
> > > > >
> rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> > > > > >> >>
> > > > >
> ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> > > > > >> >>
> > > > >
> til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> > > > > >> >>
> > > > >
> ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> > > > > >> >> ct.se
> > > > > ;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> > > > > >> >>
> > > > >
> se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> > > > > >> >>
> > > > >
> arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> > > > > >> >>
> > > > >
> ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> > > > > >> >>
> > > > >
> ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> > > > > >> >>
> > > > >
> .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> > > > > >> >>
> > > > >
> karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> > > > > >> >> ise.util",jakarta.enterprise.util;version="3.0"
> > > > > >> >> Bundle-Name: CDI APIs
> > > > > >> >> Bundle-Version: 3.0.0.M4
> > > > > >> >> Build-Jdk-Spec: 1.8
> > > > > >> >> Created-By: Apache Maven Bundle Plugin
> > > > > >> >> Build-Jdk: 1.8.0_202
> > > > > >> >>
> > > > > >> >> Where are the osgi.serviceloader and osgi.contract ?
> > > > > >> >> This is important and used by OSGi-CDI for example (even if
> it
> > > can
> > > > be
> > > > > >> >> worked around).
> > > > > >> >>
> > > > > >> >> So to conclude on this point not belonging to OWB, we still
> > need
> > > > our
> > > > > >> fork
> > > > > >> >> and eclipse always answered saying "yes we want OSGi [but we
> > > don't
> > > > > >> really
> > > > > >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but
> > they
> > > > > don't
> > > > > >> >> work on that factually so OSGi is done at minimal cost.
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> >
> > > > > >> >> > Gurkan’s proposal will only add difficulty for developers
> and
> > > > > >> probably
> > > > > >> >> > > users.
> > > > > >> >> > >
> > > > > >> >> > What is the difficulty? The change will only affect
> > maintaining
> > > > the
> > > > > >> >> javax.*
> > > > > >> >> > branch and fully renamed jakarta.* dependencies in master.
> > > > > >> >> >
> > > > > >> >>
> > > > > >> >> Ok Gurkan, let's be concrete, do you - you as you personally
> -
> > > > accept
> > > > > >> and
> > > > > >> >> commit yourself to port any commit to one of the two branches
> > to
> > > > the
> > > > > >> other
> > > > > >> >> for all the time the project is at apache?
> > > > > >> >> if so fine, if not -1 to create us unneeded (+ still
> > unjustified
> > > by
> > > > > >> facts)
> > > > > >> >> work.
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> >
> > > > > >> >> > Regards.
> > > > > >> >> > Gurkan
> > > > > >> >> >
> > > > > >> >> > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <
> > > > > >> david.a.jencks@gmail.com>
> > > > > >> >> > wrote:
> > > > > >> >> >
> > > > > >> >> > > I’m not sure exactly how it impacts this decision, but
> IIUC
> > > the
> > > > > >> >> geronimo
> > > > > >> >> > > cdi spec jar is rather essential for some uses as it has
> > OSGI
> > > > > >> support
> > > > > >> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > > > > >> >> > >
> > > > > >> >> > > Personally I’m afraid I’m totally on Romain’s side so
> far,
> > > > AFAICT
> > > > > >> >> > Gurkan’s
> > > > > >> >> > > proposal will only add difficulty for developers and
> > probably
> > > > > >> users.
> > > > > >> >> > > Although I haven’t been active here for years I might
> even
> > > > vote.
> > > > > >> >> > >
> > > > > >> >> > > thanks
> > > > > >> >> > > David Jencks
> > > > > >> >> > >
> > > > > >> >> > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
> > > > > >> >> cgurkanerdogdu@gmail.com>
> > > > > >> >> > > wrote:
> > > > > >> >> > > >
> > > > > >> >> > > >>
> > > > > >> >> > > >> Tomcat works with branches since years without any
> > issue.
> > > > > >> >> > > >> All projects we tried to use branches we abandoned
> > > branches
> > > > > just
> > > > > >> >> after
> > > > > >> >> > > >> having done them.
> > > > > >> >> > > >> It is fine if the old branch is no more used but here
> we
> > > > know
> > > > > we
> > > > > >> >> will
> > > > > >> >> > > >> maintain javax branch more than jakarta one for some
> > time
> > > > so I
> > > > > >> >> think
> > > > > >> >> > we
> > > > > >> >> > > >> should avoid it while it is not justified or one of
> the
> > 2
> > > > > >> branches
> > > > > >> >> > > (javax)
> > > > > >> >> > > >> is "almost dead".
> > > > > >> >> > > >
> > > > > >> >> > > > Working with branches always happens in all open source
> > > > > projects.
> > > > > >> >> And
> > > > > >> >> > > > there are times when it is logical to create the
> branch.
> > > > > Jakarta
> > > > > >> EE
> > > > > >> >> 9
> > > > > >> >> > API
> > > > > >> >> > > > migration is the best time to create such a branch.
> > > > Eventually,
> > > > > >> we
> > > > > >> >> will
> > > > > >> >> > > > create such a branch in Jakarta EE 10.
> > > > > >> >> > > >
> > > > > >> >> > > > Fact there will be no more javax is useless IMHO, only
> > > > question
> > > > > >> we
> > > > > >> >> > should
> > > > > >> >> > > >> care about is "do we have javax users?" and should we
> > > work
> > > > on
> > > > > >> >> javax
> > > > > >> >> > > branch
> > > > > >> >> > > >> enough to care about having 2 duplicate branches.
> Answer
> > > is
> > > > > >> >> obviously
> > > > > >> >> > > yes
> > > > > >> >> > > >> and more than jakarta users today, therefore I think
> for
> > > > some
> > > > > >> >> months
> > > > > >> >> > > (maybe
> > > > > >> >> > > >> a few years) we should stick to javax as our primary
> > > branch
> > > > > and
> > > > > >> >> ensure
> > > > > >> >> > > the
> > > > > >> >> > > >> alignments and bugfixes can trivially - == without any
> > > > action
> > > > > >> from
> > > > > >> >> dev
> > > > > >> >> > > - be
> > > > > >> >> > > >> ported. It is what we have today.
> > > > > >> >> > > >>
> > > > > >> >> > > > What could be more natural than maintaining branches
> > (with
> > > > > >> >> backporting
> > > > > >> >> > > from
> > > > > >> >> > > > master only if necessary). With Jakarta EE 10, we will
> > > > > eventually
> > > > > >> >> > create
> > > > > >> >> > > > the branch for supporting the EE 8. Also, for the
> release
> > > > > >> >> versioning,
> > > > > >> >> > it
> > > > > >> >> > > is
> > > > > >> >> > > > nice to have a 3.x release. The community will notice
> > that
> > > > 3.x
> > > > > is
> > > > > >> >> the
> > > > > >> >> > > > starting point of Jakarta EE support. Will you release
> > 2.x
> > > > with
> > > > > >> the
> > > > > >> >> > > > intention of supporting Jakarta EE 9? I am personally
> not
> > > > > >> positive
> > > > > >> >> on
> > > > > >> >> > > this.
> > > > > >> >> > > > I think, 3.x release will also get more interest even
> if
> > > the
> > > > > >> >> > > functionality
> > > > > >> >> > > > and API stay the same. We can prepare the press release
> > for
> > > > it.
> > > > > >> >> > > >
> > > > > >> >> > > > Note we shouldn't depend on jakarta/javax api anyway
> > > (neither
> > > > > as
> > > > > >> >> > groupId
> > > > > >> >> > > >> nor as transitive dep so this change must stay a noop
> > for
> > > > > >> >> consumers).
> > > > > >> >> > > >>
> > > > > >> >> > > > What is the problem of depending on the official
> Jakarta
> > EE
> > > > CDI
> > > > > >> >> API? It
> > > > > >> >> > > is
> > > > > >> >> > > > an Apache friendly license. Instead of maintaining the
> > > > Geronimo
> > > > > >> CDI
> > > > > >> >> API
> > > > > >> >> > > > internally, it is more logical to use Jakarta EE
> official
> > > CDI
> > > > > API
> > > > > >> >> and
> > > > > >> >> > > > maintain this API with EE4J community.
> > > > > >> >> > > >
> > > > > >> >> > > > would also appreciate if you do a vote if you can point
> > out
> > > > the
> > > > > >> >> > breaking
> > > > > >> >> > > >> changes - except the package renaming - justifying to
> > fork
> > > > > >> ourself
> > > > > >> >> and
> > > > > >> >> > > what
> > > > > >> >> > > >> does not work with current solution, can ease the
> > > > > decision/vote.
> > > > > >> >> > > >> Today using jakarta/EE9 API is quite easy (
> > > > > >> >> > > >>
> > > > > >> >> > >
> > > > > >> >> >
> > > > > >> >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > > > >> >> > > >> ).
> > > > > >> >> > > >> We should absolutely enhance the pom experience though
> > but
> > > > it
> > > > > is
> > > > > >> >> > > trivial to
> > > > > >> >> > > >> do at maven level - I was envisionning to do it in
> shade
> > > > > plugin
> > > > > >> to
> > > > > >> >> be
> > > > > >> >> > > more
> > > > > >> >> > > >> precise.
> > > > > >> >> > > >>
> > > > > >> >> > > > I know that there will be no functional change. But, I
> am
> > > > also
> > > > > >> >> against
> > > > > >> >> > > > shading for jakarta.*. If there will be no change on
> > > Jakarta
> > > > EE
> > > > > >> 10,
> > > > > >> >> > will
> > > > > >> >> > > we
> > > > > >> >> > > > continue to shade? What happens when there will be a
> > > change
> > > > in
> > > > > >> EJB,
> > > > > >> >> > JMS
> > > > > >> >> > > > etc specifications but no change in CDI in Jakarta EE
> 10?
> > > > Also,
> > > > > >> >> VOTING
> > > > > >> >> > is
> > > > > >> >> > > > the natural thing to do for the community decision. If
> > the
> > > > > >> community
> > > > > >> >> > > would
> > > > > >> >> > > > like to keep it as it is via shading, it is fine.
> > > > > >> >> > > >
> > > > > >> >> > > >>
> > > > > >> >> > > >> To try to rephrase/clarify my questionning today: you
> > ask
> > > > for
> > > > > >> >> jakarta
> > > > > >> >> > > >> support, we already have it in a dev and project
> > efficient
> > > > way
> > > > > >> so
> > > > > >> >> why
> > > > > >> >> > > >> should we change since I don't hink there is anything
> > new
> > > -
> > > > > once
> > > > > >> >> again
> > > > > >> >> > > if
> > > > > >> >> > > >> API starts to fully break discussion is different but
> > > github
> > > > > >> doesnt
> > > > > >> >> > > reflect
> > > > > >> >> > > >> that?
> > > > > >> >> > > >>
> > > > > >> >> > > > This is not just for Jakarta EE 9 support. As we know,
> > > there
> > > > > will
> > > > > >> >> be no
> > > > > >> >> > > API
> > > > > >> >> > > > (functional) change, only package renaming. But, I want
> > to
> > > > > >> emphasize
> > > > > >> >> > that
> > > > > >> >> > > > with such turning points, it is so logical to integrate
> > > > > official
> > > > > >> >> > Jakarta
> > > > > >> >> > > > CDI API into our master (removing the geronimo-cdi),
> and
> > > > > release
> > > > > >> our
> > > > > >> >> > new
> > > > > >> >> > > > 3.x version and let the public know that OWB supports
> > > > official
> > > > > >> CDI
> > > > > >> >> API
> > > > > >> >> > > > beginning with 3.x release. Yeah, shading is an option
> > for
> > > > > >> package
> > > > > >> >> > > renaming
> > > > > >> >> > > > but think long term. Also, I am really against the
> > shading.
> > > > It
> > > > > >> >> really
> > > > > >> >> > > > disturbs the users which depend on OWB implementation.
> > For
> > > > > >> example,
> > > > > >> >> > > > currently Glassfish supports Weld integration but one
> can
> > > > also
> > > > > >> >> > implement
> > > > > >> >> > > > OWB to replace Weld in Glassfish. Therefore, instead of
> > > using
> > > > > the
> > > > > >> >> > shaded
> > > > > >> >> > > > version, it is really important to have the full
> Jakarta
> > EE
> > > > CDI
> > > > > >> API
> > > > > >> >> in
> > > > > >> >> > > our
> > > > > >> >> > > > poms. You will still have javax.* dependency in ur POMs
> > > even
> > > > if
> > > > > >> >> doing a
> > > > > >> >> > > > shade. This is not good idea to still maintain javax.*
> in
> > > our
> > > > > POM
> > > > > >> >> > files.
> > > > > >> >> > > >
> > > > > >> >> > > > What are other opinions before formal voting?
> > > > > >> >> > > > Regards.
> > > > > >> >> > > > Gurkan
> > > > > >> >> > > >
> > > > > >> >> > > >
> > > > > >> >> > > >
> > > > > >> >> > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> > > > > >> >> > rmannibucau@gmail.com
> > > > > >> >> > > >
> > > > > >> >> > > > wrote:
> > > > > >> >> > > >
> > > > > >> >> > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> > > > > >> >> cgurkanerdogdu@gmail.com
> > > > > >> >> > >
> > > > > >> >> > > a
> > > > > >> >> > > >> écrit :
> > > > > >> >> > > >>
> > > > > >> >> > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish
> is
> > > > also
> > > > > on
> > > > > >> >> > master.
> > > > > >> >> > > >>>
> > > > > >> >> > > >>
> > > > > >> >> > > >> Tomcat works with branches since years without any
> > issue.
> > > > > >> >> > > >> All projects we tried to use branches we abandoned
> > > branches
> > > > > just
> > > > > >> >> after
> > > > > >> >> > > >> having done them.
> > > > > >> >> > > >> It is fine if the old branch is no more used but here
> we
> > > > know
> > > > > we
> > > > > >> >> will
> > > > > >> >> > > >> maintain javax branch more than jakarta one for some
> > time
> > > > so I
> > > > > >> >> think
> > > > > >> >> > we
> > > > > >> >> > > >> should avoid it while it is not justified or one of
> the
> > 2
> > > > > >> branches
> > > > > >> >> > > (javax)
> > > > > >> >> > > >> is "almost dead".
> > > > > >> >> > > >>
> > > > > >> >> > > >>
> > > > > >> >> > > >>> sorry but not understand the resistance on this? will
> > you
> > > > > >> always
> > > > > >> >> > shade
> > > > > >> >> > > ?
> > > > > >> >> > > >>>
> > > > > >> >> > > >>
> > > > > >> >> > > >> As mentionned, until API needs changes we can't easily
> > > > handle
> > > > > -
> > > > > >> >> today
> > > > > >> >> > > there
> > > > > >> >> > > >> is no change.
> > > > > >> >> > > >>
> > > > > >> >> > > >>
> > > > > >> >> > > >>> creating the new master and maintain the 2.x branch,
> is
> > > the
> > > > > >> best
> > > > > >> >> > > logical
> > > > > >> >> > > >>> way. there will be no javax.* any more. Tomcat
> > maintains
> > > 3
> > > > > >> >> branches
> > > > > >> >> > > and
> > > > > >> >> > > >> 1
> > > > > >> >> > > >>> master. only maintains 1 branch and 1 master is
> totally
> > > > fine.
> > > > > >> >> > > >>>
> > > > > >> >> > > >>
> > > > > >> >> > > >> Fact there will be no more javax is useless IMHO, only
> > > > > question
> > > > > >> we
> > > > > >> >> > > should
> > > > > >> >> > > >> care about is "do we have javax users?" and should we
> > > work
> > > > on
> > > > > >> >> javax
> > > > > >> >> > > branch
> > > > > >> >> > > >> enough to care about having 2 duplicate branches.
> Answer
> > > is
> > > > > >> >> obviously
> > > > > >> >> > > yes
> > > > > >> >> > > >> and more than jakarta users today, therefore I think
> for
> > > > some
> > > > > >> >> months
> > > > > >> >> > > (maybe
> > > > > >> >> > > >> a few years) we should stick to javax as our primary
> > > branch
> > > > > and
> > > > > >> >> ensure
> > > > > >> >> > > the
> > > > > >> >> > > >> alignments and bugfixes can trivially - == without any
> > > > action
> > > > > >> from
> > > > > >> >> dev
> > > > > >> >> > > - be
> > > > > >> >> > > >> ported. It is what we have today.
> > > > > >> >> > > >>
> > > > > >> >> > > >>
> > > > > >> >> > > >>>
> > > > > >> >> > > >>> I will propose a vote shortly to decide on to create
> a
> > > > master
> > > > > >> with
> > > > > >> >> > 3.x
> > > > > >> >> > > >> with
> > > > > >> >> > > >>> fully support of jakarta with a normal pom dependency
> > > with
> > > > > >> jakarta
> > > > > >> >> > api.
> > > > > >> >> > > >>>
> > > > > >> >> > > >>
> > > > > >> >> > > >> Note we shouldn't depend on jakarta/javax api anyway
> > > > (neither
> > > > > as
> > > > > >> >> > groupId
> > > > > >> >> > > >> nor as transitive dep so this change must stay a noop
> > for
> > > > > >> >> consumers).
> > > > > >> >> > > >> I would also appreciate if you do a vote if you can
> > point
> > > > out
> > > > > >> the
> > > > > >> >> > > breaking
> > > > > >> >> > > >> changes - except the package renaming - justifying to
> > fork
> > > > > >> ourself
> > > > > >> >> and
> > > > > >> >> > > what
> > > > > >> >> > > >> does not work with current solution, can ease the
> > > > > decision/vote.
> > > > > >> >> > > >> Today using jakarta/EE9 API is quite easy (
> > > > > >> >> > > >>
> > > > > >> >> > >
> > > > > >> >> >
> > > > > >> >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > > > >> >> > > >> ).
> > > > > >> >> > > >> We should absolutely enhance the pom experience though
> > but
> > > > it
> > > > > is
> > > > > >> >> > > trivial to
> > > > > >> >> > > >> do at maven level - I was envisionning to do it in
> shade
> > > > > plugin
> > > > > >> to
> > > > > >> >> be
> > > > > >> >> > > more
> > > > > >> >> > > >> precise.
> > > > > >> >> > > >>
> > > > > >> >> > > >> To try to rephrase/clarify my questionning today: you
> > ask
> > > > for
> > > > > >> >> jakarta
> > > > > >> >> > > >> support, we already have it in a dev and project
> > efficient
> > > > way
> > > > > >> so
> > > > > >> >> why
> > > > > >> >> > > >> should we change since I don't hink there is anything
> > new
> > > -
> > > > > once
> > > > > >> >> again
> > > > > >> >> > > if
> > > > > >> >> > > >> API starts to fully break discussion is different but
> > > github
> > > > > >> doesnt
> > > > > >> >> > > reflect
> > > > > >> >> > > >> that?
> > > > > >> >> > > >>
> > > > > >> >> > > >>
> > > > > >> >> > > >>>
> > > > > >> >> > > >>> Regs
> > > > > >> >> > > >>> Gurkan
> > > > > >> >> > > >>>
> > > > > >> >> > > >>>
> > > > > >> >> > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
> > > > > >> >> rmannibucau@gmail.com
> > > > > >> >> > >
> > > > > >> >> > > >>> wrote:
> > > > > >> >> > > >>>
> > > > > >> >> > > >>>> Today we don't need, tomorrow I don't know but while
> > API
> > > > > does
> > > > > >> not
> > > > > >> >> > > >> change
> > > > > >> >> > > >>>> (except the package) we shouldn't fork ourself IMHO
> > > (cause
> > > > > it
> > > > > >> is
> > > > > >> >> > what
> > > > > >> >> > > >> you
> > > > > >> >> > > >>>> propose as a consequence).
> > > > > >> >> > > >>>> If it becomes necessary let's do it but my vote is
> to
> > > stay
> > > > > >> lazy
> > > > > >> >> on
> > > > > >> >> > > >> that.
> > > > > >> >> > > >>>>
> > > > > >> >> > > >>>>
> > > > > >> >> > > >>>> side note for G API discussion belongs to dev@G but
> > it
> > > is
> > > > > >> less
> > > > > >> >> an
> > > > > >> >> > > >> issue
> > > > > >> >> > > >>> to
> > > > > >> >> > > >>>> fork from now since we rarely update the API, the
> side
> > > > note
> > > > > >> here
> > > > > >> >> is
> > > > > >> >> > > >> that
> > > > > >> >> > > >>>> CDI SE is already fully runnable on ASF stack with
> > > jakarta
> > > > > >> >> package
> > > > > >> >> > > >> since
> > > > > >> >> > > >>>> some weeks or months, we did all the needed
> releases.
> > > > > >> >> > > >>>>
> > > > > >> >> > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > > > > >> >> > > >>>> andraschko.thomas@gmail.com>
> > > > > >> >> > > >>>> a écrit :
> > > > > >> >> > > >>>>
> > > > > >> >> > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar
> via
> > > our
> > > > > >> build.
> > > > > >> >> > > >>>>> As EE9 just changes the namespace, it's perfectly
> > fine.
> > > > > >> >> > > >>>>>
> > > > > >> >> > > >>>>> I'm actually also a supporter of doing a hard cut
> but
> > > > it's
> > > > > >> not
> > > > > >> >> > > >> required
> > > > > >> >> > > >>>> and
> > > > > >> >> > > >>>>> we can do it for EE 10.
> > > > > >> >> > > >>>>>
> > > > > >> >> > > >>>>> <
> > > > > >> >> > > >>>>>
> > > > > >> >> > > >>>>
> > > > > >> >> > > >>>
> > > > > >> >> > > >>
> > > > > >> >> > >
> > > > > >> >> >
> > > > > >> >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > > >> >> > > >>>>>>
> > > > > >> >> > > >>>>> Virenfrei.
> > > > > >> >> > > >>>>> www.avast.com
> > > > > >> >> > > >>>>> <
> > > > > >> >> > > >>>>>
> > > > > >> >> > > >>>>
> > > > > >> >> > > >>>
> > > > > >> >> > > >>
> > > > > >> >> > >
> > > > > >> >> >
> > > > > >> >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > > >> >> > > >>>>>>
> > > > > >> >> > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > > >> >> > > >>>>>
> > > > > >> >> > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan
> > > Erdogdu
> > > > <
> > > > > >> >> > > >>>>> cgurkanerdogdu@gmail.com>:
> > > > > >> >> > > >>>>>
> > > > > >> >> > > >>>>>> We need to maintain two branches
> > > > > >> >> > > >>>>>>
> > > > > >> >> > > >>>>>> EE 8 for javax.* package 2.x branch
> > > > > >> >> > > >>>>>> EE 9 for jakarta.* package 3.x master
> > > > > >> >> > > >>>>>>
> > > > > >> >> > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> > > > > >> >> > > >> rmannibucau@gmail.com
> > > > > >> >> > > >>>>
> > > > > >> >> > > >>>>>> wrote:
> > > > > >> >> > > >>>>>>
> > > > > >> >> > > >>>>>>> Hi,
> > > > > >> >> > > >>>>>>>
> > > > > >> >> > > >>>>>>> I'll probably restate my position on that: if EE
> 9
> > > > brings
> > > > > >> >> > > >>>>> significatively
> > > > > >> >> > > >>>>>>> new API yes - a quick review shows it is 1-1 with
> > EE
> > > 8
> > > > > but
> > > > > >> I
> > > > > >> >> can
> > > > > >> >> > > >>> have
> > > > > >> >> > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then
> we
> > > can
> > > > > >> stay
> > > > > >> >> as
> > > > > >> >> > > >> we
> > > > > >> >> > > >>>> are
> > > > > >> >> > > >>>>> I
> > > > > >> >> > > >>>>>>> think avoiding to maintain two branches we can't
> > > merge
> > > > > >> >> regularly.
> > > > > >> >> > > >>>>>>>
> > > > > >> >> > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > > > > >> >> > > >>>> cgurkanerdogdu@gmail.com>
> > > > > >> >> > > >>>>> a
> > > > > >> >> > > >>>>>>> écrit :
> > > > > >> >> > > >>>>>>>
> > > > > >> >> > > >>>>>>>> Hi
> > > > > >> >> > > >>>>>>>> After the 2.x release, can we get the master to
> > > 3.0.0
> > > > to
> > > > > >> >> > > >> support
> > > > > >> >> > > >>>>>> upcoming
> > > > > >> >> > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> > > > > >> >> > > >>>>>>>>
> > > > > >> >> > > >>>>>>>> I also favor to use the Jakarta EE CDI API
> instead
> > > of
> > > > > >> using
> > > > > >> >> the
> > > > > >> >> > > >>>>> Apache
> > > > > >> >> > > >>>>>>>> based api.
> > > > > >> >> > > >>>>>>>> Regards
> > > > > >> >> > > >>>>>>>> Gurkan
> > > > > >> >> > > >>>>>>>>
> > > > > >> >> > > >>>>>>>> --
> > > > > >> >> > > >>>>>>>> Gurkan Erdogdu
> > > > > >> >> > > >>>>>>>> http://gurkanerdogdu.blogspot.com
> > > > > >> >> > > >>>>>>>>
> > > > > >> >> > > >>>>>>>
> > > > > >> >> > > >>>>>> --
> > > > > >> >> > > >>>>>> Gurkan Erdogdu
> > > > > >> >> > > >>>>>> http://gurkanerdogdu.blogspot.com
> > > > > >> >> > > >>>>>>
> > > > > >> >> > > >>>>>
> > > > > >> >> > > >>>>
> > > > > >> >> > > >>> --
> > > > > >> >> > > >>> Gurkan Erdogdu
> > > > > >> >> > > >>> http://gurkanerdogdu.blogspot.com
> > > > > >> >> > > >>>
> > > > > >> >> > > >>
> > > > > >> >> > > >
> > > > > >> >> > > >
> > > > > >> >> > > > --
> > > > > >> >> > > > Gurkan Erdogdu
> > > > > >> >> > > > http://gurkanerdogdu.blogspot.com
> > > > > >> >> > >
> > > > > >> >> > >
> > > > > >> >> >
> > > > > >> >> > --
> > > > > >> >> > Gurkan Erdogdu
> > > > > >> >> > http://gurkanerdogdu.blogspot.com
> > > > > >> >> >
> > > > > >> >>
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Gurkan Erdogdu
> > > > > >> > http://gurkanerdogdu.blogspot.com
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Gurkan Erdogdu
> > > > > >> http://gurkanerdogdu.blogspot.com
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Gurkan Erdogdu
> > > http://gurkanerdogdu.blogspot.com
> > >
> >
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
Re: Jakarta EE 9 Support
Posted by Gurkan Erdogdu <cg...@gmail.com>.
>
> When required we'll do, today there is really nothing justifying it.
If one integrates the OWB via POM dependency in his jakarta project, it is
a problem to see javax.* everywhere in OWB POM files. He needs to solve
problems via some exotic POM operations. For example, I did not able to
run TEstNG
Probably, you will do it shortly because Jakarta EE 10 will start
Anyway, keep the good work. Also, we need to extend the community around
OWB. Community projects grow with community and decisions are made by the
community.
Gurkan
On Wed, Jun 10, 2020 at 12:08 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le mer. 10 juin 2020 à 09:55, Gurkan Erdogdu <cg...@gmail.com> a
> écrit :
>
> > This javax to jakarta has already created problems in running for example
> > TestNG tests in eclipse :)
> > Also, keep in mind that OWB also depends on several Geronimo EE APIs and
> > must be sure that there is no String usage of javax. in any of these
> APIs.
> >
>
> We did :)
>
>
> > I am still not convinced of using shaded artifacts. For me the best thing
> > is to do one big single conversion from javax. to jakarta. and create a
> > branch and also using Jakarta EE APIs. I don't see any reason to use
> > Geronimo APIs. (except some simple OSGI artifacts)
> >
>
> Well in front of that I can say "I don't see any reason to use jakarta
> artifacts".
> Both are true except we control G ones, we don't control jakarta one and it
> happens they have bugs.
> We - at asf - also generally run with G ones so it is better to harness G
> ones than jakarta ones.
> It is not a big +1 for G but a +0.1 and -0.1 for jakarta.
> Finally, since we don't really provide these artifacts in owb itself it
> does not change anything but we do in meecrowave (an owb project - and here
> it is not a choice since we must have the right defaults) so it is
> consistent to use the same accross projects of the same family IMHO.
>
>
> > As I see, there are no other opinions, I will not create a VOTE for this
> > and keep this way. But, it will finally need to be done.
> >
>
> When required we'll do, today there is really nothing justifying it.
>
>
> > Gurkan
> >
> >
> > On Mon, Jun 8, 2020 at 12:40 PM Thomas Andraschko <
> > andraschko.thomas@gmail.com> wrote:
> >
> > > Nice work romain!
> > >
> > > Am Mo., 8. Juni 2020 um 11:29 Uhr schrieb Romain Manni-Bucau <
> > > rmannibucau@gmail.com>:
> > >
> > > > FYI we run jakarta tck now with
> > > > https://issues.apache.org/jira/browse/OWB-1327
> > > > As expected it works fine
> > > >
> > > > 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. 8 juin 2020 à 08:33, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > > a
> > > > écrit :
> > > >
> > > > >
> > > > >
> > > > > Le dim. 7 juin 2020 à 20:48, Gurkan Erdogdu <
> > cgurkanerdogdu@gmail.com>
> > > a
> > > > > écrit :
> > > > >
> > > > >> > Not, it is not correct Gurkan ;).
> > > > >> > jakarta does NOT support OSGi properly, it does it the old way
> and
> > > > break
> > > > >> > several rules. For instance last CDI spec jar contains:
> > > > >>
> > > > >> As I said in my previous email, I am not an OSGI expert. But,
> what I
> > > can
> > > > >> do
> > > > >> is that I can ping the CDI team in EE4J to add features to support
> > > > >> OWB-OSGI
> > > > >> or other ASF projects? Could you explain in detail?
> > > > >>
> > > > >
> > > > > OSGi-CDI not OWB-CDI, it is an OSGi spec ;)
> > > > > It is mainly the metadata.
> > > > > Point is we already contacted the spec leaders, even for
> Microprofile
> > > if
> > > > > you want to get the full story (same people more or less) and it
> > didn't
> > > > go
> > > > > well enough even if people were willing to do it.
> > > > > So factually today it is saner to keep it here and it is not an
> issue
> > > for
> > > > > G project anyway since we do it for years and we will keep doing it
> > for
> > > > > defaults at least.
> > > > > Once again not an OWB discussion and decision had been taken
> already
> > on
> > > > > this one so don't want to loop on the same topic again and again,
> in
> > > > > particular from the wrong list ;).
> > > > >
> > > > >
> > > > >>
> > > > >> Regards.
> > > > >> Gurkan
> > > > >>
> > > > >> On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu <
> > > cgurkanerdogdu@gmail.com
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >> > So to conclude on this point not belonging to OWB, we still need
> > our
> > > > >> fork
> > > > >> >> and eclipse always answered saying "yes we want OSGi [but we
> > don't
> > > > >> really
> > > > >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but
> they
> > > > don't
> > > > >> >> work on that factually so OSGi is done at minimal cost.
> > > > >> >
> > > > >> > OK thanks for the clarification. I am not an OSGI expert.
> > > > >> >
> > > > >> > Ok Gurkan, let's be concrete, do you - you as you personally -
> > > accept
> > > > >> and
> > > > >> >> commit yourself to port any commit to one of the two branches
> to
> > > the
> > > > >> other
> > > > >> >> for all the time the project is at apache?
> > > > >> >> if so fine, if not -1 to create us unneeded (+ still
> unjustified
> > by
> > > > >> facts)
> > > > >> >> work.
> > > > >> >
> > > > >> > :=)
> > > > >> > Hey, I'm just proposing what I think about. If nobody cares
> about
> > > it
> > > > or
> > > > >> > is not beneficial, it is ok, and also there is no need to VOTE
> > (This
> > > > is
> > > > >> why
> > > > >> > I'd like to get more opinions on it). But look at Weld, they did
> > the
> > > > >> > update, https://github.com/weld and full of updating their pom
> to
> > > use
> > > > >> > jakarta.*
> > > > >> >
> > > > >> > Currently all of the OWB modules (webbeans-ee, webbeans-el22
> etc),
> > > use
> > > > >> > geronimo-...specs which depend on javax.*. Today or tomorrow,
> we
> > > will
> > > > >> > eventually move to jakarta.* namespace. Instead of working with
> > > such
> > > > >> > shading plugin stuff as a workaround, I just offer to take the
> > > master
> > > > to
> > > > >> > jakarta.* and update all OWB modules' dependency from javax.*
> to
> > > > >> jakarta.*
> > > > >> > official APIS. This is not related to who will maintain the
> > > branches.
> > > > >> You
> > > > >> > know that ASF works as a voluntary based approach. You can not
> > push
> > > > >> anybody
> > > > >> > to work on anything as in commercial companies.
> > > > >> >
> > > > >> > Also, regarding the cost and energy you mention to maintain the
> > > > branch,
> > > > >> > via Geronimo specs, you will need to update all of the Geronimo
> > > Specs
> > > > >> and
> > > > >> > maintain them. I think this is not rational because now,
> jakarta.*
> > > > >> official
> > > > >> > API license is EPL and Apache friendly. Why do I need to
> maintain
> > > for
> > > > >> > example Geronimo EL?
> > > > >> >
> > > > >> > Regards.
> > > > >> > Gurkan
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <
> > > > >> rmannibucau@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <
> > > > cgurkanerdogdu@gmail.com>
> > > > >> a
> > > > >> >> écrit :
> > > > >> >>
> > > > >> >> > Hi David
> > > > >> >> >
> > > > >> >> > I’m not sure exactly how it impacts this decision, but IIUC
> the
> > > > >> geronimo
> > > > >> >> > > cdi spec jar is rather essential for some uses as it has
> OSGI
> > > > >> support
> > > > >> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > > > >> >> > >
> > > > >> >> > No, it is not correct. It has OSGI support. GlassFish is an
> > OSGI
> > > > >> based
> > > > >> >> > server.You can grap the code from
> > > > >> https://github.com/eclipse-ee4j/cdi
> > > > >> >> and
> > > > >> >> > build. It has OSGI enabled MANIFEST.MF file.
> > > > >> >> >
> > > > >> >>
> > > > >> >> Not, it is not correct Gurkan ;).
> > > > >> >> jakarta does NOT support OSGi properly, it does it the old way
> > and
> > > > >> break
> > > > >> >> several rules. For instance last CDI spec jar contains:
> > > > >> >>
> > > > >> >> Manifest-Version: 1.0
> > > > >> >> Bundle-Description: APIs for CDI (Contexts and Dependency
> > Injection
> > > > fo
> > > > >> >> r Java)
> > > > >> >> Bundle-License:
> > > https://repository.jboss.org/licenses/apache-2.0.txt
> > > > >> >> Bundle-SymbolicName: jakarta.enterprise.cdi-api
> > > > >> >> Built-By: default
> > > > >> >> Bnd-LastModified: 1590678420932
> > > > >> >> Bundle-ManifestVersion: 2
> > > > >> >> Bundle-DocURL: https://jboss.org
> > > > >> >> Bundle-Vendor: JBoss by Red Hat, Inc.
> > > > >> >> Import-Package:
> > > > jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> > > > >> >> 3)",jakarta.interceptor;version="[2.0,3)"
> > > > >> >> Require-Capability: osgi.ee;filter:="(&(osgi.ee
> > > > =JavaSE)(version=1.8))"
> > > > >> >> Tool: Bnd-2.4.1.201501161923
> > > > >> >> Originally-Created-By: Apache Maven Bundle Plugin
> > > > >> >> Export-Package:
> > > > jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> > > > >> >>
> > > > ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> > > > >> >>
> > > > nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> > > > >> >>
> > > > sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> > > > >> >>
> > > > arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> > > > >> >>
> > > > rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> > > > >> >>
> > > > ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> > > > >> >>
> > > > til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> > > > >> >>
> > > > ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> > > > >> >> ct.se
> > > > ;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> > > > >> >>
> > > > se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> > > > >> >>
> > > > arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> > > > >> >>
> > > > ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> > > > >> >>
> > > > ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> > > > >> >>
> > > > .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> > > > >> >>
> > > > karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> > > > >> >> ise.util",jakarta.enterprise.util;version="3.0"
> > > > >> >> Bundle-Name: CDI APIs
> > > > >> >> Bundle-Version: 3.0.0.M4
> > > > >> >> Build-Jdk-Spec: 1.8
> > > > >> >> Created-By: Apache Maven Bundle Plugin
> > > > >> >> Build-Jdk: 1.8.0_202
> > > > >> >>
> > > > >> >> Where are the osgi.serviceloader and osgi.contract ?
> > > > >> >> This is important and used by OSGi-CDI for example (even if it
> > can
> > > be
> > > > >> >> worked around).
> > > > >> >>
> > > > >> >> So to conclude on this point not belonging to OWB, we still
> need
> > > our
> > > > >> fork
> > > > >> >> and eclipse always answered saying "yes we want OSGi [but we
> > don't
> > > > >> really
> > > > >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but
> they
> > > > don't
> > > > >> >> work on that factually so OSGi is done at minimal cost.
> > > > >> >>
> > > > >> >>
> > > > >> >> >
> > > > >> >> > Gurkan’s proposal will only add difficulty for developers and
> > > > >> probably
> > > > >> >> > > users.
> > > > >> >> > >
> > > > >> >> > What is the difficulty? The change will only affect
> maintaining
> > > the
> > > > >> >> javax.*
> > > > >> >> > branch and fully renamed jakarta.* dependencies in master.
> > > > >> >> >
> > > > >> >>
> > > > >> >> Ok Gurkan, let's be concrete, do you - you as you personally -
> > > accept
> > > > >> and
> > > > >> >> commit yourself to port any commit to one of the two branches
> to
> > > the
> > > > >> other
> > > > >> >> for all the time the project is at apache?
> > > > >> >> if so fine, if not -1 to create us unneeded (+ still
> unjustified
> > by
> > > > >> facts)
> > > > >> >> work.
> > > > >> >>
> > > > >> >>
> > > > >> >> >
> > > > >> >> > Regards.
> > > > >> >> > Gurkan
> > > > >> >> >
> > > > >> >> > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <
> > > > >> david.a.jencks@gmail.com>
> > > > >> >> > wrote:
> > > > >> >> >
> > > > >> >> > > I’m not sure exactly how it impacts this decision, but IIUC
> > the
> > > > >> >> geronimo
> > > > >> >> > > cdi spec jar is rather essential for some uses as it has
> OSGI
> > > > >> support
> > > > >> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > > > >> >> > >
> > > > >> >> > > Personally I’m afraid I’m totally on Romain’s side so far,
> > > AFAICT
> > > > >> >> > Gurkan’s
> > > > >> >> > > proposal will only add difficulty for developers and
> probably
> > > > >> users.
> > > > >> >> > > Although I haven’t been active here for years I might even
> > > vote.
> > > > >> >> > >
> > > > >> >> > > thanks
> > > > >> >> > > David Jencks
> > > > >> >> > >
> > > > >> >> > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
> > > > >> >> cgurkanerdogdu@gmail.com>
> > > > >> >> > > wrote:
> > > > >> >> > > >
> > > > >> >> > > >>
> > > > >> >> > > >> Tomcat works with branches since years without any
> issue.
> > > > >> >> > > >> All projects we tried to use branches we abandoned
> > branches
> > > > just
> > > > >> >> after
> > > > >> >> > > >> having done them.
> > > > >> >> > > >> It is fine if the old branch is no more used but here we
> > > know
> > > > we
> > > > >> >> will
> > > > >> >> > > >> maintain javax branch more than jakarta one for some
> time
> > > so I
> > > > >> >> think
> > > > >> >> > we
> > > > >> >> > > >> should avoid it while it is not justified or one of the
> 2
> > > > >> branches
> > > > >> >> > > (javax)
> > > > >> >> > > >> is "almost dead".
> > > > >> >> > > >
> > > > >> >> > > > Working with branches always happens in all open source
> > > > projects.
> > > > >> >> And
> > > > >> >> > > > there are times when it is logical to create the branch.
> > > > Jakarta
> > > > >> EE
> > > > >> >> 9
> > > > >> >> > API
> > > > >> >> > > > migration is the best time to create such a branch.
> > > Eventually,
> > > > >> we
> > > > >> >> will
> > > > >> >> > > > create such a branch in Jakarta EE 10.
> > > > >> >> > > >
> > > > >> >> > > > Fact there will be no more javax is useless IMHO, only
> > > question
> > > > >> we
> > > > >> >> > should
> > > > >> >> > > >> care about is "do we have javax users?" and should we
> > work
> > > on
> > > > >> >> javax
> > > > >> >> > > branch
> > > > >> >> > > >> enough to care about having 2 duplicate branches. Answer
> > is
> > > > >> >> obviously
> > > > >> >> > > yes
> > > > >> >> > > >> and more than jakarta users today, therefore I think for
> > > some
> > > > >> >> months
> > > > >> >> > > (maybe
> > > > >> >> > > >> a few years) we should stick to javax as our primary
> > branch
> > > > and
> > > > >> >> ensure
> > > > >> >> > > the
> > > > >> >> > > >> alignments and bugfixes can trivially - == without any
> > > action
> > > > >> from
> > > > >> >> dev
> > > > >> >> > > - be
> > > > >> >> > > >> ported. It is what we have today.
> > > > >> >> > > >>
> > > > >> >> > > > What could be more natural than maintaining branches
> (with
> > > > >> >> backporting
> > > > >> >> > > from
> > > > >> >> > > > master only if necessary). With Jakarta EE 10, we will
> > > > eventually
> > > > >> >> > create
> > > > >> >> > > > the branch for supporting the EE 8. Also, for the release
> > > > >> >> versioning,
> > > > >> >> > it
> > > > >> >> > > is
> > > > >> >> > > > nice to have a 3.x release. The community will notice
> that
> > > 3.x
> > > > is
> > > > >> >> the
> > > > >> >> > > > starting point of Jakarta EE support. Will you release
> 2.x
> > > with
> > > > >> the
> > > > >> >> > > > intention of supporting Jakarta EE 9? I am personally not
> > > > >> positive
> > > > >> >> on
> > > > >> >> > > this.
> > > > >> >> > > > I think, 3.x release will also get more interest even if
> > the
> > > > >> >> > > functionality
> > > > >> >> > > > and API stay the same. We can prepare the press release
> for
> > > it.
> > > > >> >> > > >
> > > > >> >> > > > Note we shouldn't depend on jakarta/javax api anyway
> > (neither
> > > > as
> > > > >> >> > groupId
> > > > >> >> > > >> nor as transitive dep so this change must stay a noop
> for
> > > > >> >> consumers).
> > > > >> >> > > >>
> > > > >> >> > > > What is the problem of depending on the official Jakarta
> EE
> > > CDI
> > > > >> >> API? It
> > > > >> >> > > is
> > > > >> >> > > > an Apache friendly license. Instead of maintaining the
> > > Geronimo
> > > > >> CDI
> > > > >> >> API
> > > > >> >> > > > internally, it is more logical to use Jakarta EE official
> > CDI
> > > > API
> > > > >> >> and
> > > > >> >> > > > maintain this API with EE4J community.
> > > > >> >> > > >
> > > > >> >> > > > would also appreciate if you do a vote if you can point
> out
> > > the
> > > > >> >> > breaking
> > > > >> >> > > >> changes - except the package renaming - justifying to
> fork
> > > > >> ourself
> > > > >> >> and
> > > > >> >> > > what
> > > > >> >> > > >> does not work with current solution, can ease the
> > > > decision/vote.
> > > > >> >> > > >> Today using jakarta/EE9 API is quite easy (
> > > > >> >> > > >>
> > > > >> >> > >
> > > > >> >> >
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > > >> >> > > >> ).
> > > > >> >> > > >> We should absolutely enhance the pom experience though
> but
> > > it
> > > > is
> > > > >> >> > > trivial to
> > > > >> >> > > >> do at maven level - I was envisionning to do it in shade
> > > > plugin
> > > > >> to
> > > > >> >> be
> > > > >> >> > > more
> > > > >> >> > > >> precise.
> > > > >> >> > > >>
> > > > >> >> > > > I know that there will be no functional change. But, I am
> > > also
> > > > >> >> against
> > > > >> >> > > > shading for jakarta.*. If there will be no change on
> > Jakarta
> > > EE
> > > > >> 10,
> > > > >> >> > will
> > > > >> >> > > we
> > > > >> >> > > > continue to shade? What happens when there will be a
> > change
> > > in
> > > > >> EJB,
> > > > >> >> > JMS
> > > > >> >> > > > etc specifications but no change in CDI in Jakarta EE 10?
> > > Also,
> > > > >> >> VOTING
> > > > >> >> > is
> > > > >> >> > > > the natural thing to do for the community decision. If
> the
> > > > >> community
> > > > >> >> > > would
> > > > >> >> > > > like to keep it as it is via shading, it is fine.
> > > > >> >> > > >
> > > > >> >> > > >>
> > > > >> >> > > >> To try to rephrase/clarify my questionning today: you
> ask
> > > for
> > > > >> >> jakarta
> > > > >> >> > > >> support, we already have it in a dev and project
> efficient
> > > way
> > > > >> so
> > > > >> >> why
> > > > >> >> > > >> should we change since I don't hink there is anything
> new
> > -
> > > > once
> > > > >> >> again
> > > > >> >> > > if
> > > > >> >> > > >> API starts to fully break discussion is different but
> > github
> > > > >> doesnt
> > > > >> >> > > reflect
> > > > >> >> > > >> that?
> > > > >> >> > > >>
> > > > >> >> > > > This is not just for Jakarta EE 9 support. As we know,
> > there
> > > > will
> > > > >> >> be no
> > > > >> >> > > API
> > > > >> >> > > > (functional) change, only package renaming. But, I want
> to
> > > > >> emphasize
> > > > >> >> > that
> > > > >> >> > > > with such turning points, it is so logical to integrate
> > > > official
> > > > >> >> > Jakarta
> > > > >> >> > > > CDI API into our master (removing the geronimo-cdi), and
> > > > release
> > > > >> our
> > > > >> >> > new
> > > > >> >> > > > 3.x version and let the public know that OWB supports
> > > official
> > > > >> CDI
> > > > >> >> API
> > > > >> >> > > > beginning with 3.x release. Yeah, shading is an option
> for
> > > > >> package
> > > > >> >> > > renaming
> > > > >> >> > > > but think long term. Also, I am really against the
> shading.
> > > It
> > > > >> >> really
> > > > >> >> > > > disturbs the users which depend on OWB implementation.
> For
> > > > >> example,
> > > > >> >> > > > currently Glassfish supports Weld integration but one can
> > > also
> > > > >> >> > implement
> > > > >> >> > > > OWB to replace Weld in Glassfish. Therefore, instead of
> > using
> > > > the
> > > > >> >> > shaded
> > > > >> >> > > > version, it is really important to have the full Jakarta
> EE
> > > CDI
> > > > >> API
> > > > >> >> in
> > > > >> >> > > our
> > > > >> >> > > > poms. You will still have javax.* dependency in ur POMs
> > even
> > > if
> > > > >> >> doing a
> > > > >> >> > > > shade. This is not good idea to still maintain javax.* in
> > our
> > > > POM
> > > > >> >> > files.
> > > > >> >> > > >
> > > > >> >> > > > What are other opinions before formal voting?
> > > > >> >> > > > Regards.
> > > > >> >> > > > Gurkan
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >> > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> > > > >> >> > rmannibucau@gmail.com
> > > > >> >> > > >
> > > > >> >> > > > wrote:
> > > > >> >> > > >
> > > > >> >> > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> > > > >> >> cgurkanerdogdu@gmail.com
> > > > >> >> > >
> > > > >> >> > > a
> > > > >> >> > > >> écrit :
> > > > >> >> > > >>
> > > > >> >> > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is
> > > also
> > > > on
> > > > >> >> > master.
> > > > >> >> > > >>>
> > > > >> >> > > >>
> > > > >> >> > > >> Tomcat works with branches since years without any
> issue.
> > > > >> >> > > >> All projects we tried to use branches we abandoned
> > branches
> > > > just
> > > > >> >> after
> > > > >> >> > > >> having done them.
> > > > >> >> > > >> It is fine if the old branch is no more used but here we
> > > know
> > > > we
> > > > >> >> will
> > > > >> >> > > >> maintain javax branch more than jakarta one for some
> time
> > > so I
> > > > >> >> think
> > > > >> >> > we
> > > > >> >> > > >> should avoid it while it is not justified or one of the
> 2
> > > > >> branches
> > > > >> >> > > (javax)
> > > > >> >> > > >> is "almost dead".
> > > > >> >> > > >>
> > > > >> >> > > >>
> > > > >> >> > > >>> sorry but not understand the resistance on this? will
> you
> > > > >> always
> > > > >> >> > shade
> > > > >> >> > > ?
> > > > >> >> > > >>>
> > > > >> >> > > >>
> > > > >> >> > > >> As mentionned, until API needs changes we can't easily
> > > handle
> > > > -
> > > > >> >> today
> > > > >> >> > > there
> > > > >> >> > > >> is no change.
> > > > >> >> > > >>
> > > > >> >> > > >>
> > > > >> >> > > >>> creating the new master and maintain the 2.x branch, is
> > the
> > > > >> best
> > > > >> >> > > logical
> > > > >> >> > > >>> way. there will be no javax.* any more. Tomcat
> maintains
> > 3
> > > > >> >> branches
> > > > >> >> > > and
> > > > >> >> > > >> 1
> > > > >> >> > > >>> master. only maintains 1 branch and 1 master is totally
> > > fine.
> > > > >> >> > > >>>
> > > > >> >> > > >>
> > > > >> >> > > >> Fact there will be no more javax is useless IMHO, only
> > > > question
> > > > >> we
> > > > >> >> > > should
> > > > >> >> > > >> care about is "do we have javax users?" and should we
> > work
> > > on
> > > > >> >> javax
> > > > >> >> > > branch
> > > > >> >> > > >> enough to care about having 2 duplicate branches. Answer
> > is
> > > > >> >> obviously
> > > > >> >> > > yes
> > > > >> >> > > >> and more than jakarta users today, therefore I think for
> > > some
> > > > >> >> months
> > > > >> >> > > (maybe
> > > > >> >> > > >> a few years) we should stick to javax as our primary
> > branch
> > > > and
> > > > >> >> ensure
> > > > >> >> > > the
> > > > >> >> > > >> alignments and bugfixes can trivially - == without any
> > > action
> > > > >> from
> > > > >> >> dev
> > > > >> >> > > - be
> > > > >> >> > > >> ported. It is what we have today.
> > > > >> >> > > >>
> > > > >> >> > > >>
> > > > >> >> > > >>>
> > > > >> >> > > >>> I will propose a vote shortly to decide on to create a
> > > master
> > > > >> with
> > > > >> >> > 3.x
> > > > >> >> > > >> with
> > > > >> >> > > >>> fully support of jakarta with a normal pom dependency
> > with
> > > > >> jakarta
> > > > >> >> > api.
> > > > >> >> > > >>>
> > > > >> >> > > >>
> > > > >> >> > > >> Note we shouldn't depend on jakarta/javax api anyway
> > > (neither
> > > > as
> > > > >> >> > groupId
> > > > >> >> > > >> nor as transitive dep so this change must stay a noop
> for
> > > > >> >> consumers).
> > > > >> >> > > >> I would also appreciate if you do a vote if you can
> point
> > > out
> > > > >> the
> > > > >> >> > > breaking
> > > > >> >> > > >> changes - except the package renaming - justifying to
> fork
> > > > >> ourself
> > > > >> >> and
> > > > >> >> > > what
> > > > >> >> > > >> does not work with current solution, can ease the
> > > > decision/vote.
> > > > >> >> > > >> Today using jakarta/EE9 API is quite easy (
> > > > >> >> > > >>
> > > > >> >> > >
> > > > >> >> >
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > > >> >> > > >> ).
> > > > >> >> > > >> We should absolutely enhance the pom experience though
> but
> > > it
> > > > is
> > > > >> >> > > trivial to
> > > > >> >> > > >> do at maven level - I was envisionning to do it in shade
> > > > plugin
> > > > >> to
> > > > >> >> be
> > > > >> >> > > more
> > > > >> >> > > >> precise.
> > > > >> >> > > >>
> > > > >> >> > > >> To try to rephrase/clarify my questionning today: you
> ask
> > > for
> > > > >> >> jakarta
> > > > >> >> > > >> support, we already have it in a dev and project
> efficient
> > > way
> > > > >> so
> > > > >> >> why
> > > > >> >> > > >> should we change since I don't hink there is anything
> new
> > -
> > > > once
> > > > >> >> again
> > > > >> >> > > if
> > > > >> >> > > >> API starts to fully break discussion is different but
> > github
> > > > >> doesnt
> > > > >> >> > > reflect
> > > > >> >> > > >> that?
> > > > >> >> > > >>
> > > > >> >> > > >>
> > > > >> >> > > >>>
> > > > >> >> > > >>> Regs
> > > > >> >> > > >>> Gurkan
> > > > >> >> > > >>>
> > > > >> >> > > >>>
> > > > >> >> > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
> > > > >> >> rmannibucau@gmail.com
> > > > >> >> > >
> > > > >> >> > > >>> wrote:
> > > > >> >> > > >>>
> > > > >> >> > > >>>> Today we don't need, tomorrow I don't know but while
> API
> > > > does
> > > > >> not
> > > > >> >> > > >> change
> > > > >> >> > > >>>> (except the package) we shouldn't fork ourself IMHO
> > (cause
> > > > it
> > > > >> is
> > > > >> >> > what
> > > > >> >> > > >> you
> > > > >> >> > > >>>> propose as a consequence).
> > > > >> >> > > >>>> If it becomes necessary let's do it but my vote is to
> > stay
> > > > >> lazy
> > > > >> >> on
> > > > >> >> > > >> that.
> > > > >> >> > > >>>>
> > > > >> >> > > >>>>
> > > > >> >> > > >>>> side note for G API discussion belongs to dev@G but
> it
> > is
> > > > >> less
> > > > >> >> an
> > > > >> >> > > >> issue
> > > > >> >> > > >>> to
> > > > >> >> > > >>>> fork from now since we rarely update the API, the side
> > > note
> > > > >> here
> > > > >> >> is
> > > > >> >> > > >> that
> > > > >> >> > > >>>> CDI SE is already fully runnable on ASF stack with
> > jakarta
> > > > >> >> package
> > > > >> >> > > >> since
> > > > >> >> > > >>>> some weeks or months, we did all the needed releases.
> > > > >> >> > > >>>>
> > > > >> >> > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > > > >> >> > > >>>> andraschko.thomas@gmail.com>
> > > > >> >> > > >>>> a écrit :
> > > > >> >> > > >>>>
> > > > >> >> > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via
> > our
> > > > >> build.
> > > > >> >> > > >>>>> As EE9 just changes the namespace, it's perfectly
> fine.
> > > > >> >> > > >>>>>
> > > > >> >> > > >>>>> I'm actually also a supporter of doing a hard cut but
> > > it's
> > > > >> not
> > > > >> >> > > >> required
> > > > >> >> > > >>>> and
> > > > >> >> > > >>>>> we can do it for EE 10.
> > > > >> >> > > >>>>>
> > > > >> >> > > >>>>> <
> > > > >> >> > > >>>>>
> > > > >> >> > > >>>>
> > > > >> >> > > >>>
> > > > >> >> > > >>
> > > > >> >> > >
> > > > >> >> >
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > >> >> > > >>>>>>
> > > > >> >> > > >>>>> Virenfrei.
> > > > >> >> > > >>>>> www.avast.com
> > > > >> >> > > >>>>> <
> > > > >> >> > > >>>>>
> > > > >> >> > > >>>>
> > > > >> >> > > >>>
> > > > >> >> > > >>
> > > > >> >> > >
> > > > >> >> >
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > >> >> > > >>>>>>
> > > > >> >> > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > >> >> > > >>>>>
> > > > >> >> > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan
> > Erdogdu
> > > <
> > > > >> >> > > >>>>> cgurkanerdogdu@gmail.com>:
> > > > >> >> > > >>>>>
> > > > >> >> > > >>>>>> We need to maintain two branches
> > > > >> >> > > >>>>>>
> > > > >> >> > > >>>>>> EE 8 for javax.* package 2.x branch
> > > > >> >> > > >>>>>> EE 9 for jakarta.* package 3.x master
> > > > >> >> > > >>>>>>
> > > > >> >> > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> > > > >> >> > > >> rmannibucau@gmail.com
> > > > >> >> > > >>>>
> > > > >> >> > > >>>>>> wrote:
> > > > >> >> > > >>>>>>
> > > > >> >> > > >>>>>>> Hi,
> > > > >> >> > > >>>>>>>
> > > > >> >> > > >>>>>>> I'll probably restate my position on that: if EE 9
> > > brings
> > > > >> >> > > >>>>> significatively
> > > > >> >> > > >>>>>>> new API yes - a quick review shows it is 1-1 with
> EE
> > 8
> > > > but
> > > > >> I
> > > > >> >> can
> > > > >> >> > > >>> have
> > > > >> >> > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we
> > can
> > > > >> stay
> > > > >> >> as
> > > > >> >> > > >> we
> > > > >> >> > > >>>> are
> > > > >> >> > > >>>>> I
> > > > >> >> > > >>>>>>> think avoiding to maintain two branches we can't
> > merge
> > > > >> >> regularly.
> > > > >> >> > > >>>>>>>
> > > > >> >> > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > > > >> >> > > >>>> cgurkanerdogdu@gmail.com>
> > > > >> >> > > >>>>> a
> > > > >> >> > > >>>>>>> écrit :
> > > > >> >> > > >>>>>>>
> > > > >> >> > > >>>>>>>> Hi
> > > > >> >> > > >>>>>>>> After the 2.x release, can we get the master to
> > 3.0.0
> > > to
> > > > >> >> > > >> support
> > > > >> >> > > >>>>>> upcoming
> > > > >> >> > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> > > > >> >> > > >>>>>>>>
> > > > >> >> > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead
> > of
> > > > >> using
> > > > >> >> the
> > > > >> >> > > >>>>> Apache
> > > > >> >> > > >>>>>>>> based api.
> > > > >> >> > > >>>>>>>> Regards
> > > > >> >> > > >>>>>>>> Gurkan
> > > > >> >> > > >>>>>>>>
> > > > >> >> > > >>>>>>>> --
> > > > >> >> > > >>>>>>>> Gurkan Erdogdu
> > > > >> >> > > >>>>>>>> http://gurkanerdogdu.blogspot.com
> > > > >> >> > > >>>>>>>>
> > > > >> >> > > >>>>>>>
> > > > >> >> > > >>>>>> --
> > > > >> >> > > >>>>>> Gurkan Erdogdu
> > > > >> >> > > >>>>>> http://gurkanerdogdu.blogspot.com
> > > > >> >> > > >>>>>>
> > > > >> >> > > >>>>>
> > > > >> >> > > >>>>
> > > > >> >> > > >>> --
> > > > >> >> > > >>> Gurkan Erdogdu
> > > > >> >> > > >>> http://gurkanerdogdu.blogspot.com
> > > > >> >> > > >>>
> > > > >> >> > > >>
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >> > > > --
> > > > >> >> > > > Gurkan Erdogdu
> > > > >> >> > > > http://gurkanerdogdu.blogspot.com
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> >
> > > > >> >> > --
> > > > >> >> > Gurkan Erdogdu
> > > > >> >> > http://gurkanerdogdu.blogspot.com
> > > > >> >> >
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Gurkan Erdogdu
> > > > >> > http://gurkanerdogdu.blogspot.com
> > > > >> >
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Gurkan Erdogdu
> > > > >> http://gurkanerdogdu.blogspot.com
> > > > >>
> > > > >
> > > >
> > >
> >
> >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 10 juin 2020 à 09:55, Gurkan Erdogdu <cg...@gmail.com> a
écrit :
> This javax to jakarta has already created problems in running for example
> TestNG tests in eclipse :)
> Also, keep in mind that OWB also depends on several Geronimo EE APIs and
> must be sure that there is no String usage of javax. in any of these APIs.
>
We did :)
> I am still not convinced of using shaded artifacts. For me the best thing
> is to do one big single conversion from javax. to jakarta. and create a
> branch and also using Jakarta EE APIs. I don't see any reason to use
> Geronimo APIs. (except some simple OSGI artifacts)
>
Well in front of that I can say "I don't see any reason to use jakarta
artifacts".
Both are true except we control G ones, we don't control jakarta one and it
happens they have bugs.
We - at asf - also generally run with G ones so it is better to harness G
ones than jakarta ones.
It is not a big +1 for G but a +0.1 and -0.1 for jakarta.
Finally, since we don't really provide these artifacts in owb itself it
does not change anything but we do in meecrowave (an owb project - and here
it is not a choice since we must have the right defaults) so it is
consistent to use the same accross projects of the same family IMHO.
> As I see, there are no other opinions, I will not create a VOTE for this
> and keep this way. But, it will finally need to be done.
>
When required we'll do, today there is really nothing justifying it.
> Gurkan
>
>
> On Mon, Jun 8, 2020 at 12:40 PM Thomas Andraschko <
> andraschko.thomas@gmail.com> wrote:
>
> > Nice work romain!
> >
> > Am Mo., 8. Juni 2020 um 11:29 Uhr schrieb Romain Manni-Bucau <
> > rmannibucau@gmail.com>:
> >
> > > FYI we run jakarta tck now with
> > > https://issues.apache.org/jira/browse/OWB-1327
> > > As expected it works fine
> > >
> > > 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. 8 juin 2020 à 08:33, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > a
> > > écrit :
> > >
> > > >
> > > >
> > > > Le dim. 7 juin 2020 à 20:48, Gurkan Erdogdu <
> cgurkanerdogdu@gmail.com>
> > a
> > > > écrit :
> > > >
> > > >> > Not, it is not correct Gurkan ;).
> > > >> > jakarta does NOT support OSGi properly, it does it the old way and
> > > break
> > > >> > several rules. For instance last CDI spec jar contains:
> > > >>
> > > >> As I said in my previous email, I am not an OSGI expert. But, what I
> > can
> > > >> do
> > > >> is that I can ping the CDI team in EE4J to add features to support
> > > >> OWB-OSGI
> > > >> or other ASF projects? Could you explain in detail?
> > > >>
> > > >
> > > > OSGi-CDI not OWB-CDI, it is an OSGi spec ;)
> > > > It is mainly the metadata.
> > > > Point is we already contacted the spec leaders, even for Microprofile
> > if
> > > > you want to get the full story (same people more or less) and it
> didn't
> > > go
> > > > well enough even if people were willing to do it.
> > > > So factually today it is saner to keep it here and it is not an issue
> > for
> > > > G project anyway since we do it for years and we will keep doing it
> for
> > > > defaults at least.
> > > > Once again not an OWB discussion and decision had been taken already
> on
> > > > this one so don't want to loop on the same topic again and again, in
> > > > particular from the wrong list ;).
> > > >
> > > >
> > > >>
> > > >> Regards.
> > > >> Gurkan
> > > >>
> > > >> On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu <
> > cgurkanerdogdu@gmail.com
> > > >
> > > >> wrote:
> > > >>
> > > >> > So to conclude on this point not belonging to OWB, we still need
> our
> > > >> fork
> > > >> >> and eclipse always answered saying "yes we want OSGi [but we
> don't
> > > >> really
> > > >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they
> > > don't
> > > >> >> work on that factually so OSGi is done at minimal cost.
> > > >> >
> > > >> > OK thanks for the clarification. I am not an OSGI expert.
> > > >> >
> > > >> > Ok Gurkan, let's be concrete, do you - you as you personally -
> > accept
> > > >> and
> > > >> >> commit yourself to port any commit to one of the two branches to
> > the
> > > >> other
> > > >> >> for all the time the project is at apache?
> > > >> >> if so fine, if not -1 to create us unneeded (+ still unjustified
> by
> > > >> facts)
> > > >> >> work.
> > > >> >
> > > >> > :=)
> > > >> > Hey, I'm just proposing what I think about. If nobody cares about
> > it
> > > or
> > > >> > is not beneficial, it is ok, and also there is no need to VOTE
> (This
> > > is
> > > >> why
> > > >> > I'd like to get more opinions on it). But look at Weld, they did
> the
> > > >> > update, https://github.com/weld and full of updating their pom to
> > use
> > > >> > jakarta.*
> > > >> >
> > > >> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc),
> > use
> > > >> > geronimo-...specs which depend on javax.*. Today or tomorrow, we
> > will
> > > >> > eventually move to jakarta.* namespace. Instead of working with
> > such
> > > >> > shading plugin stuff as a workaround, I just offer to take the
> > master
> > > to
> > > >> > jakarta.* and update all OWB modules' dependency from javax.* to
> > > >> jakarta.*
> > > >> > official APIS. This is not related to who will maintain the
> > branches.
> > > >> You
> > > >> > know that ASF works as a voluntary based approach. You can not
> push
> > > >> anybody
> > > >> > to work on anything as in commercial companies.
> > > >> >
> > > >> > Also, regarding the cost and energy you mention to maintain the
> > > branch,
> > > >> > via Geronimo specs, you will need to update all of the Geronimo
> > Specs
> > > >> and
> > > >> > maintain them. I think this is not rational because now, jakarta.*
> > > >> official
> > > >> > API license is EPL and Apache friendly. Why do I need to maintain
> > for
> > > >> > example Geronimo EL?
> > > >> >
> > > >> > Regards.
> > > >> > Gurkan
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <
> > > >> rmannibucau@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> >> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <
> > > cgurkanerdogdu@gmail.com>
> > > >> a
> > > >> >> écrit :
> > > >> >>
> > > >> >> > Hi David
> > > >> >> >
> > > >> >> > I’m not sure exactly how it impacts this decision, but IIUC the
> > > >> geronimo
> > > >> >> > > cdi spec jar is rather essential for some uses as it has OSGI
> > > >> support
> > > >> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > > >> >> > >
> > > >> >> > No, it is not correct. It has OSGI support. GlassFish is an
> OSGI
> > > >> based
> > > >> >> > server.You can grap the code from
> > > >> https://github.com/eclipse-ee4j/cdi
> > > >> >> and
> > > >> >> > build. It has OSGI enabled MANIFEST.MF file.
> > > >> >> >
> > > >> >>
> > > >> >> Not, it is not correct Gurkan ;).
> > > >> >> jakarta does NOT support OSGi properly, it does it the old way
> and
> > > >> break
> > > >> >> several rules. For instance last CDI spec jar contains:
> > > >> >>
> > > >> >> Manifest-Version: 1.0
> > > >> >> Bundle-Description: APIs for CDI (Contexts and Dependency
> Injection
> > > fo
> > > >> >> r Java)
> > > >> >> Bundle-License:
> > https://repository.jboss.org/licenses/apache-2.0.txt
> > > >> >> Bundle-SymbolicName: jakarta.enterprise.cdi-api
> > > >> >> Built-By: default
> > > >> >> Bnd-LastModified: 1590678420932
> > > >> >> Bundle-ManifestVersion: 2
> > > >> >> Bundle-DocURL: https://jboss.org
> > > >> >> Bundle-Vendor: JBoss by Red Hat, Inc.
> > > >> >> Import-Package:
> > > jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> > > >> >> 3)",jakarta.interceptor;version="[2.0,3)"
> > > >> >> Require-Capability: osgi.ee;filter:="(&(osgi.ee
> > > =JavaSE)(version=1.8))"
> > > >> >> Tool: Bnd-2.4.1.201501161923
> > > >> >> Originally-Created-By: Apache Maven Bundle Plugin
> > > >> >> Export-Package:
> > > jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> > > >> >>
> > > ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> > > >> >>
> > > nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> > > >> >>
> > > sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> > > >> >>
> > > arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> > > >> >>
> > > rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> > > >> >>
> > > ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> > > >> >>
> > > til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> > > >> >>
> > > ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> > > >> >> ct.se
> > > ;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> > > >> >>
> > > se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> > > >> >>
> > > arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> > > >> >>
> > > ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> > > >> >>
> > > ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> > > >> >>
> > > .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> > > >> >>
> > > karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> > > >> >> ise.util",jakarta.enterprise.util;version="3.0"
> > > >> >> Bundle-Name: CDI APIs
> > > >> >> Bundle-Version: 3.0.0.M4
> > > >> >> Build-Jdk-Spec: 1.8
> > > >> >> Created-By: Apache Maven Bundle Plugin
> > > >> >> Build-Jdk: 1.8.0_202
> > > >> >>
> > > >> >> Where are the osgi.serviceloader and osgi.contract ?
> > > >> >> This is important and used by OSGi-CDI for example (even if it
> can
> > be
> > > >> >> worked around).
> > > >> >>
> > > >> >> So to conclude on this point not belonging to OWB, we still need
> > our
> > > >> fork
> > > >> >> and eclipse always answered saying "yes we want OSGi [but we
> don't
> > > >> really
> > > >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they
> > > don't
> > > >> >> work on that factually so OSGi is done at minimal cost.
> > > >> >>
> > > >> >>
> > > >> >> >
> > > >> >> > Gurkan’s proposal will only add difficulty for developers and
> > > >> probably
> > > >> >> > > users.
> > > >> >> > >
> > > >> >> > What is the difficulty? The change will only affect maintaining
> > the
> > > >> >> javax.*
> > > >> >> > branch and fully renamed jakarta.* dependencies in master.
> > > >> >> >
> > > >> >>
> > > >> >> Ok Gurkan, let's be concrete, do you - you as you personally -
> > accept
> > > >> and
> > > >> >> commit yourself to port any commit to one of the two branches to
> > the
> > > >> other
> > > >> >> for all the time the project is at apache?
> > > >> >> if so fine, if not -1 to create us unneeded (+ still unjustified
> by
> > > >> facts)
> > > >> >> work.
> > > >> >>
> > > >> >>
> > > >> >> >
> > > >> >> > Regards.
> > > >> >> > Gurkan
> > > >> >> >
> > > >> >> > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <
> > > >> david.a.jencks@gmail.com>
> > > >> >> > wrote:
> > > >> >> >
> > > >> >> > > I’m not sure exactly how it impacts this decision, but IIUC
> the
> > > >> >> geronimo
> > > >> >> > > cdi spec jar is rather essential for some uses as it has OSGI
> > > >> support
> > > >> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > > >> >> > >
> > > >> >> > > Personally I’m afraid I’m totally on Romain’s side so far,
> > AFAICT
> > > >> >> > Gurkan’s
> > > >> >> > > proposal will only add difficulty for developers and probably
> > > >> users.
> > > >> >> > > Although I haven’t been active here for years I might even
> > vote.
> > > >> >> > >
> > > >> >> > > thanks
> > > >> >> > > David Jencks
> > > >> >> > >
> > > >> >> > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
> > > >> >> cgurkanerdogdu@gmail.com>
> > > >> >> > > wrote:
> > > >> >> > > >
> > > >> >> > > >>
> > > >> >> > > >> Tomcat works with branches since years without any issue.
> > > >> >> > > >> All projects we tried to use branches we abandoned
> branches
> > > just
> > > >> >> after
> > > >> >> > > >> having done them.
> > > >> >> > > >> It is fine if the old branch is no more used but here we
> > know
> > > we
> > > >> >> will
> > > >> >> > > >> maintain javax branch more than jakarta one for some time
> > so I
> > > >> >> think
> > > >> >> > we
> > > >> >> > > >> should avoid it while it is not justified or one of the 2
> > > >> branches
> > > >> >> > > (javax)
> > > >> >> > > >> is "almost dead".
> > > >> >> > > >
> > > >> >> > > > Working with branches always happens in all open source
> > > projects.
> > > >> >> And
> > > >> >> > > > there are times when it is logical to create the branch.
> > > Jakarta
> > > >> EE
> > > >> >> 9
> > > >> >> > API
> > > >> >> > > > migration is the best time to create such a branch.
> > Eventually,
> > > >> we
> > > >> >> will
> > > >> >> > > > create such a branch in Jakarta EE 10.
> > > >> >> > > >
> > > >> >> > > > Fact there will be no more javax is useless IMHO, only
> > question
> > > >> we
> > > >> >> > should
> > > >> >> > > >> care about is "do we have javax users?" and should we
> work
> > on
> > > >> >> javax
> > > >> >> > > branch
> > > >> >> > > >> enough to care about having 2 duplicate branches. Answer
> is
> > > >> >> obviously
> > > >> >> > > yes
> > > >> >> > > >> and more than jakarta users today, therefore I think for
> > some
> > > >> >> months
> > > >> >> > > (maybe
> > > >> >> > > >> a few years) we should stick to javax as our primary
> branch
> > > and
> > > >> >> ensure
> > > >> >> > > the
> > > >> >> > > >> alignments and bugfixes can trivially - == without any
> > action
> > > >> from
> > > >> >> dev
> > > >> >> > > - be
> > > >> >> > > >> ported. It is what we have today.
> > > >> >> > > >>
> > > >> >> > > > What could be more natural than maintaining branches (with
> > > >> >> backporting
> > > >> >> > > from
> > > >> >> > > > master only if necessary). With Jakarta EE 10, we will
> > > eventually
> > > >> >> > create
> > > >> >> > > > the branch for supporting the EE 8. Also, for the release
> > > >> >> versioning,
> > > >> >> > it
> > > >> >> > > is
> > > >> >> > > > nice to have a 3.x release. The community will notice that
> > 3.x
> > > is
> > > >> >> the
> > > >> >> > > > starting point of Jakarta EE support. Will you release 2.x
> > with
> > > >> the
> > > >> >> > > > intention of supporting Jakarta EE 9? I am personally not
> > > >> positive
> > > >> >> on
> > > >> >> > > this.
> > > >> >> > > > I think, 3.x release will also get more interest even if
> the
> > > >> >> > > functionality
> > > >> >> > > > and API stay the same. We can prepare the press release for
> > it.
> > > >> >> > > >
> > > >> >> > > > Note we shouldn't depend on jakarta/javax api anyway
> (neither
> > > as
> > > >> >> > groupId
> > > >> >> > > >> nor as transitive dep so this change must stay a noop for
> > > >> >> consumers).
> > > >> >> > > >>
> > > >> >> > > > What is the problem of depending on the official Jakarta EE
> > CDI
> > > >> >> API? It
> > > >> >> > > is
> > > >> >> > > > an Apache friendly license. Instead of maintaining the
> > Geronimo
> > > >> CDI
> > > >> >> API
> > > >> >> > > > internally, it is more logical to use Jakarta EE official
> CDI
> > > API
> > > >> >> and
> > > >> >> > > > maintain this API with EE4J community.
> > > >> >> > > >
> > > >> >> > > > would also appreciate if you do a vote if you can point out
> > the
> > > >> >> > breaking
> > > >> >> > > >> changes - except the package renaming - justifying to fork
> > > >> ourself
> > > >> >> and
> > > >> >> > > what
> > > >> >> > > >> does not work with current solution, can ease the
> > > decision/vote.
> > > >> >> > > >> Today using jakarta/EE9 API is quite easy (
> > > >> >> > > >>
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > >> >> > > >> ).
> > > >> >> > > >> We should absolutely enhance the pom experience though but
> > it
> > > is
> > > >> >> > > trivial to
> > > >> >> > > >> do at maven level - I was envisionning to do it in shade
> > > plugin
> > > >> to
> > > >> >> be
> > > >> >> > > more
> > > >> >> > > >> precise.
> > > >> >> > > >>
> > > >> >> > > > I know that there will be no functional change. But, I am
> > also
> > > >> >> against
> > > >> >> > > > shading for jakarta.*. If there will be no change on
> Jakarta
> > EE
> > > >> 10,
> > > >> >> > will
> > > >> >> > > we
> > > >> >> > > > continue to shade? What happens when there will be a
> change
> > in
> > > >> EJB,
> > > >> >> > JMS
> > > >> >> > > > etc specifications but no change in CDI in Jakarta EE 10?
> > Also,
> > > >> >> VOTING
> > > >> >> > is
> > > >> >> > > > the natural thing to do for the community decision. If the
> > > >> community
> > > >> >> > > would
> > > >> >> > > > like to keep it as it is via shading, it is fine.
> > > >> >> > > >
> > > >> >> > > >>
> > > >> >> > > >> To try to rephrase/clarify my questionning today: you ask
> > for
> > > >> >> jakarta
> > > >> >> > > >> support, we already have it in a dev and project efficient
> > way
> > > >> so
> > > >> >> why
> > > >> >> > > >> should we change since I don't hink there is anything new
> -
> > > once
> > > >> >> again
> > > >> >> > > if
> > > >> >> > > >> API starts to fully break discussion is different but
> github
> > > >> doesnt
> > > >> >> > > reflect
> > > >> >> > > >> that?
> > > >> >> > > >>
> > > >> >> > > > This is not just for Jakarta EE 9 support. As we know,
> there
> > > will
> > > >> >> be no
> > > >> >> > > API
> > > >> >> > > > (functional) change, only package renaming. But, I want to
> > > >> emphasize
> > > >> >> > that
> > > >> >> > > > with such turning points, it is so logical to integrate
> > > official
> > > >> >> > Jakarta
> > > >> >> > > > CDI API into our master (removing the geronimo-cdi), and
> > > release
> > > >> our
> > > >> >> > new
> > > >> >> > > > 3.x version and let the public know that OWB supports
> > official
> > > >> CDI
> > > >> >> API
> > > >> >> > > > beginning with 3.x release. Yeah, shading is an option for
> > > >> package
> > > >> >> > > renaming
> > > >> >> > > > but think long term. Also, I am really against the shading.
> > It
> > > >> >> really
> > > >> >> > > > disturbs the users which depend on OWB implementation. For
> > > >> example,
> > > >> >> > > > currently Glassfish supports Weld integration but one can
> > also
> > > >> >> > implement
> > > >> >> > > > OWB to replace Weld in Glassfish. Therefore, instead of
> using
> > > the
> > > >> >> > shaded
> > > >> >> > > > version, it is really important to have the full Jakarta EE
> > CDI
> > > >> API
> > > >> >> in
> > > >> >> > > our
> > > >> >> > > > poms. You will still have javax.* dependency in ur POMs
> even
> > if
> > > >> >> doing a
> > > >> >> > > > shade. This is not good idea to still maintain javax.* in
> our
> > > POM
> > > >> >> > files.
> > > >> >> > > >
> > > >> >> > > > What are other opinions before formal voting?
> > > >> >> > > > Regards.
> > > >> >> > > > Gurkan
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> > > >> >> > rmannibucau@gmail.com
> > > >> >> > > >
> > > >> >> > > > wrote:
> > > >> >> > > >
> > > >> >> > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> > > >> >> cgurkanerdogdu@gmail.com
> > > >> >> > >
> > > >> >> > > a
> > > >> >> > > >> écrit :
> > > >> >> > > >>
> > > >> >> > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is
> > also
> > > on
> > > >> >> > master.
> > > >> >> > > >>>
> > > >> >> > > >>
> > > >> >> > > >> Tomcat works with branches since years without any issue.
> > > >> >> > > >> All projects we tried to use branches we abandoned
> branches
> > > just
> > > >> >> after
> > > >> >> > > >> having done them.
> > > >> >> > > >> It is fine if the old branch is no more used but here we
> > know
> > > we
> > > >> >> will
> > > >> >> > > >> maintain javax branch more than jakarta one for some time
> > so I
> > > >> >> think
> > > >> >> > we
> > > >> >> > > >> should avoid it while it is not justified or one of the 2
> > > >> branches
> > > >> >> > > (javax)
> > > >> >> > > >> is "almost dead".
> > > >> >> > > >>
> > > >> >> > > >>
> > > >> >> > > >>> sorry but not understand the resistance on this? will you
> > > >> always
> > > >> >> > shade
> > > >> >> > > ?
> > > >> >> > > >>>
> > > >> >> > > >>
> > > >> >> > > >> As mentionned, until API needs changes we can't easily
> > handle
> > > -
> > > >> >> today
> > > >> >> > > there
> > > >> >> > > >> is no change.
> > > >> >> > > >>
> > > >> >> > > >>
> > > >> >> > > >>> creating the new master and maintain the 2.x branch, is
> the
> > > >> best
> > > >> >> > > logical
> > > >> >> > > >>> way. there will be no javax.* any more. Tomcat maintains
> 3
> > > >> >> branches
> > > >> >> > > and
> > > >> >> > > >> 1
> > > >> >> > > >>> master. only maintains 1 branch and 1 master is totally
> > fine.
> > > >> >> > > >>>
> > > >> >> > > >>
> > > >> >> > > >> Fact there will be no more javax is useless IMHO, only
> > > question
> > > >> we
> > > >> >> > > should
> > > >> >> > > >> care about is "do we have javax users?" and should we
> work
> > on
> > > >> >> javax
> > > >> >> > > branch
> > > >> >> > > >> enough to care about having 2 duplicate branches. Answer
> is
> > > >> >> obviously
> > > >> >> > > yes
> > > >> >> > > >> and more than jakarta users today, therefore I think for
> > some
> > > >> >> months
> > > >> >> > > (maybe
> > > >> >> > > >> a few years) we should stick to javax as our primary
> branch
> > > and
> > > >> >> ensure
> > > >> >> > > the
> > > >> >> > > >> alignments and bugfixes can trivially - == without any
> > action
> > > >> from
> > > >> >> dev
> > > >> >> > > - be
> > > >> >> > > >> ported. It is what we have today.
> > > >> >> > > >>
> > > >> >> > > >>
> > > >> >> > > >>>
> > > >> >> > > >>> I will propose a vote shortly to decide on to create a
> > master
> > > >> with
> > > >> >> > 3.x
> > > >> >> > > >> with
> > > >> >> > > >>> fully support of jakarta with a normal pom dependency
> with
> > > >> jakarta
> > > >> >> > api.
> > > >> >> > > >>>
> > > >> >> > > >>
> > > >> >> > > >> Note we shouldn't depend on jakarta/javax api anyway
> > (neither
> > > as
> > > >> >> > groupId
> > > >> >> > > >> nor as transitive dep so this change must stay a noop for
> > > >> >> consumers).
> > > >> >> > > >> I would also appreciate if you do a vote if you can point
> > out
> > > >> the
> > > >> >> > > breaking
> > > >> >> > > >> changes - except the package renaming - justifying to fork
> > > >> ourself
> > > >> >> and
> > > >> >> > > what
> > > >> >> > > >> does not work with current solution, can ease the
> > > decision/vote.
> > > >> >> > > >> Today using jakarta/EE9 API is quite easy (
> > > >> >> > > >>
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > >> >> > > >> ).
> > > >> >> > > >> We should absolutely enhance the pom experience though but
> > it
> > > is
> > > >> >> > > trivial to
> > > >> >> > > >> do at maven level - I was envisionning to do it in shade
> > > plugin
> > > >> to
> > > >> >> be
> > > >> >> > > more
> > > >> >> > > >> precise.
> > > >> >> > > >>
> > > >> >> > > >> To try to rephrase/clarify my questionning today: you ask
> > for
> > > >> >> jakarta
> > > >> >> > > >> support, we already have it in a dev and project efficient
> > way
> > > >> so
> > > >> >> why
> > > >> >> > > >> should we change since I don't hink there is anything new
> -
> > > once
> > > >> >> again
> > > >> >> > > if
> > > >> >> > > >> API starts to fully break discussion is different but
> github
> > > >> doesnt
> > > >> >> > > reflect
> > > >> >> > > >> that?
> > > >> >> > > >>
> > > >> >> > > >>
> > > >> >> > > >>>
> > > >> >> > > >>> Regs
> > > >> >> > > >>> Gurkan
> > > >> >> > > >>>
> > > >> >> > > >>>
> > > >> >> > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
> > > >> >> rmannibucau@gmail.com
> > > >> >> > >
> > > >> >> > > >>> wrote:
> > > >> >> > > >>>
> > > >> >> > > >>>> Today we don't need, tomorrow I don't know but while API
> > > does
> > > >> not
> > > >> >> > > >> change
> > > >> >> > > >>>> (except the package) we shouldn't fork ourself IMHO
> (cause
> > > it
> > > >> is
> > > >> >> > what
> > > >> >> > > >> you
> > > >> >> > > >>>> propose as a consequence).
> > > >> >> > > >>>> If it becomes necessary let's do it but my vote is to
> stay
> > > >> lazy
> > > >> >> on
> > > >> >> > > >> that.
> > > >> >> > > >>>>
> > > >> >> > > >>>>
> > > >> >> > > >>>> side note for G API discussion belongs to dev@G but it
> is
> > > >> less
> > > >> >> an
> > > >> >> > > >> issue
> > > >> >> > > >>> to
> > > >> >> > > >>>> fork from now since we rarely update the API, the side
> > note
> > > >> here
> > > >> >> is
> > > >> >> > > >> that
> > > >> >> > > >>>> CDI SE is already fully runnable on ASF stack with
> jakarta
> > > >> >> package
> > > >> >> > > >> since
> > > >> >> > > >>>> some weeks or months, we did all the needed releases.
> > > >> >> > > >>>>
> > > >> >> > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > > >> >> > > >>>> andraschko.thomas@gmail.com>
> > > >> >> > > >>>> a écrit :
> > > >> >> > > >>>>
> > > >> >> > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via
> our
> > > >> build.
> > > >> >> > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
> > > >> >> > > >>>>>
> > > >> >> > > >>>>> I'm actually also a supporter of doing a hard cut but
> > it's
> > > >> not
> > > >> >> > > >> required
> > > >> >> > > >>>> and
> > > >> >> > > >>>>> we can do it for EE 10.
> > > >> >> > > >>>>>
> > > >> >> > > >>>>> <
> > > >> >> > > >>>>>
> > > >> >> > > >>>>
> > > >> >> > > >>>
> > > >> >> > > >>
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > >> >> > > >>>>>>
> > > >> >> > > >>>>> Virenfrei.
> > > >> >> > > >>>>> www.avast.com
> > > >> >> > > >>>>> <
> > > >> >> > > >>>>>
> > > >> >> > > >>>>
> > > >> >> > > >>>
> > > >> >> > > >>
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > >> >> > > >>>>>>
> > > >> >> > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > >> >> > > >>>>>
> > > >> >> > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan
> Erdogdu
> > <
> > > >> >> > > >>>>> cgurkanerdogdu@gmail.com>:
> > > >> >> > > >>>>>
> > > >> >> > > >>>>>> We need to maintain two branches
> > > >> >> > > >>>>>>
> > > >> >> > > >>>>>> EE 8 for javax.* package 2.x branch
> > > >> >> > > >>>>>> EE 9 for jakarta.* package 3.x master
> > > >> >> > > >>>>>>
> > > >> >> > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> > > >> >> > > >> rmannibucau@gmail.com
> > > >> >> > > >>>>
> > > >> >> > > >>>>>> wrote:
> > > >> >> > > >>>>>>
> > > >> >> > > >>>>>>> Hi,
> > > >> >> > > >>>>>>>
> > > >> >> > > >>>>>>> I'll probably restate my position on that: if EE 9
> > brings
> > > >> >> > > >>>>> significatively
> > > >> >> > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE
> 8
> > > but
> > > >> I
> > > >> >> can
> > > >> >> > > >>> have
> > > >> >> > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we
> can
> > > >> stay
> > > >> >> as
> > > >> >> > > >> we
> > > >> >> > > >>>> are
> > > >> >> > > >>>>> I
> > > >> >> > > >>>>>>> think avoiding to maintain two branches we can't
> merge
> > > >> >> regularly.
> > > >> >> > > >>>>>>>
> > > >> >> > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > > >> >> > > >>>> cgurkanerdogdu@gmail.com>
> > > >> >> > > >>>>> a
> > > >> >> > > >>>>>>> écrit :
> > > >> >> > > >>>>>>>
> > > >> >> > > >>>>>>>> Hi
> > > >> >> > > >>>>>>>> After the 2.x release, can we get the master to
> 3.0.0
> > to
> > > >> >> > > >> support
> > > >> >> > > >>>>>> upcoming
> > > >> >> > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> > > >> >> > > >>>>>>>>
> > > >> >> > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead
> of
> > > >> using
> > > >> >> the
> > > >> >> > > >>>>> Apache
> > > >> >> > > >>>>>>>> based api.
> > > >> >> > > >>>>>>>> Regards
> > > >> >> > > >>>>>>>> Gurkan
> > > >> >> > > >>>>>>>>
> > > >> >> > > >>>>>>>> --
> > > >> >> > > >>>>>>>> Gurkan Erdogdu
> > > >> >> > > >>>>>>>> http://gurkanerdogdu.blogspot.com
> > > >> >> > > >>>>>>>>
> > > >> >> > > >>>>>>>
> > > >> >> > > >>>>>> --
> > > >> >> > > >>>>>> Gurkan Erdogdu
> > > >> >> > > >>>>>> http://gurkanerdogdu.blogspot.com
> > > >> >> > > >>>>>>
> > > >> >> > > >>>>>
> > > >> >> > > >>>>
> > > >> >> > > >>> --
> > > >> >> > > >>> Gurkan Erdogdu
> > > >> >> > > >>> http://gurkanerdogdu.blogspot.com
> > > >> >> > > >>>
> > > >> >> > > >>
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > > --
> > > >> >> > > > Gurkan Erdogdu
> > > >> >> > > > http://gurkanerdogdu.blogspot.com
> > > >> >> > >
> > > >> >> > >
> > > >> >> >
> > > >> >> > --
> > > >> >> > Gurkan Erdogdu
> > > >> >> > http://gurkanerdogdu.blogspot.com
> > > >> >> >
> > > >> >>
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Gurkan Erdogdu
> > > >> > http://gurkanerdogdu.blogspot.com
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> Gurkan Erdogdu
> > > >> http://gurkanerdogdu.blogspot.com
> > > >>
> > > >
> > >
> >
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
Re: Jakarta EE 9 Support
Posted by Gurkan Erdogdu <cg...@gmail.com>.
This javax to jakarta has already created problems in running for example
TestNG tests in eclipse :)
Also, keep in mind that OWB also depends on several Geronimo EE APIs and
must be sure that there is no String usage of javax. in any of these APIs.
I am still not convinced of using shaded artifacts. For me the best thing
is to do one big single conversion from javax. to jakarta. and create a
branch and also using Jakarta EE APIs. I don't see any reason to use
Geronimo APIs. (except some simple OSGI artifacts)
As I see, there are no other opinions, I will not create a VOTE for this
and keep this way. But, it will finally need to be done.
Gurkan
On Mon, Jun 8, 2020 at 12:40 PM Thomas Andraschko <
andraschko.thomas@gmail.com> wrote:
> Nice work romain!
>
> Am Mo., 8. Juni 2020 um 11:29 Uhr schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com>:
>
> > FYI we run jakarta tck now with
> > https://issues.apache.org/jira/browse/OWB-1327
> > As expected it works fine
> >
> > 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. 8 juin 2020 à 08:33, Romain Manni-Bucau <rm...@gmail.com>
> a
> > écrit :
> >
> > >
> > >
> > > Le dim. 7 juin 2020 à 20:48, Gurkan Erdogdu <cg...@gmail.com>
> a
> > > écrit :
> > >
> > >> > Not, it is not correct Gurkan ;).
> > >> > jakarta does NOT support OSGi properly, it does it the old way and
> > break
> > >> > several rules. For instance last CDI spec jar contains:
> > >>
> > >> As I said in my previous email, I am not an OSGI expert. But, what I
> can
> > >> do
> > >> is that I can ping the CDI team in EE4J to add features to support
> > >> OWB-OSGI
> > >> or other ASF projects? Could you explain in detail?
> > >>
> > >
> > > OSGi-CDI not OWB-CDI, it is an OSGi spec ;)
> > > It is mainly the metadata.
> > > Point is we already contacted the spec leaders, even for Microprofile
> if
> > > you want to get the full story (same people more or less) and it didn't
> > go
> > > well enough even if people were willing to do it.
> > > So factually today it is saner to keep it here and it is not an issue
> for
> > > G project anyway since we do it for years and we will keep doing it for
> > > defaults at least.
> > > Once again not an OWB discussion and decision had been taken already on
> > > this one so don't want to loop on the same topic again and again, in
> > > particular from the wrong list ;).
> > >
> > >
> > >>
> > >> Regards.
> > >> Gurkan
> > >>
> > >> On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu <
> cgurkanerdogdu@gmail.com
> > >
> > >> wrote:
> > >>
> > >> > So to conclude on this point not belonging to OWB, we still need our
> > >> fork
> > >> >> and eclipse always answered saying "yes we want OSGi [but we don't
> > >> really
> > >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they
> > don't
> > >> >> work on that factually so OSGi is done at minimal cost.
> > >> >
> > >> > OK thanks for the clarification. I am not an OSGI expert.
> > >> >
> > >> > Ok Gurkan, let's be concrete, do you - you as you personally -
> accept
> > >> and
> > >> >> commit yourself to port any commit to one of the two branches to
> the
> > >> other
> > >> >> for all the time the project is at apache?
> > >> >> if so fine, if not -1 to create us unneeded (+ still unjustified by
> > >> facts)
> > >> >> work.
> > >> >
> > >> > :=)
> > >> > Hey, I'm just proposing what I think about. If nobody cares about
> it
> > or
> > >> > is not beneficial, it is ok, and also there is no need to VOTE (This
> > is
> > >> why
> > >> > I'd like to get more opinions on it). But look at Weld, they did the
> > >> > update, https://github.com/weld and full of updating their pom to
> use
> > >> > jakarta.*
> > >> >
> > >> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc),
> use
> > >> > geronimo-...specs which depend on javax.*. Today or tomorrow, we
> will
> > >> > eventually move to jakarta.* namespace. Instead of working with
> such
> > >> > shading plugin stuff as a workaround, I just offer to take the
> master
> > to
> > >> > jakarta.* and update all OWB modules' dependency from javax.* to
> > >> jakarta.*
> > >> > official APIS. This is not related to who will maintain the
> branches.
> > >> You
> > >> > know that ASF works as a voluntary based approach. You can not push
> > >> anybody
> > >> > to work on anything as in commercial companies.
> > >> >
> > >> > Also, regarding the cost and energy you mention to maintain the
> > branch,
> > >> > via Geronimo specs, you will need to update all of the Geronimo
> Specs
> > >> and
> > >> > maintain them. I think this is not rational because now, jakarta.*
> > >> official
> > >> > API license is EPL and Apache friendly. Why do I need to maintain
> for
> > >> > example Geronimo EL?
> > >> >
> > >> > Regards.
> > >> > Gurkan
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <
> > >> rmannibucau@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <
> > cgurkanerdogdu@gmail.com>
> > >> a
> > >> >> écrit :
> > >> >>
> > >> >> > Hi David
> > >> >> >
> > >> >> > I’m not sure exactly how it impacts this decision, but IIUC the
> > >> geronimo
> > >> >> > > cdi spec jar is rather essential for some uses as it has OSGI
> > >> support
> > >> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > >> >> > >
> > >> >> > No, it is not correct. It has OSGI support. GlassFish is an OSGI
> > >> based
> > >> >> > server.You can grap the code from
> > >> https://github.com/eclipse-ee4j/cdi
> > >> >> and
> > >> >> > build. It has OSGI enabled MANIFEST.MF file.
> > >> >> >
> > >> >>
> > >> >> Not, it is not correct Gurkan ;).
> > >> >> jakarta does NOT support OSGi properly, it does it the old way and
> > >> break
> > >> >> several rules. For instance last CDI spec jar contains:
> > >> >>
> > >> >> Manifest-Version: 1.0
> > >> >> Bundle-Description: APIs for CDI (Contexts and Dependency Injection
> > fo
> > >> >> r Java)
> > >> >> Bundle-License:
> https://repository.jboss.org/licenses/apache-2.0.txt
> > >> >> Bundle-SymbolicName: jakarta.enterprise.cdi-api
> > >> >> Built-By: default
> > >> >> Bnd-LastModified: 1590678420932
> > >> >> Bundle-ManifestVersion: 2
> > >> >> Bundle-DocURL: https://jboss.org
> > >> >> Bundle-Vendor: JBoss by Red Hat, Inc.
> > >> >> Import-Package:
> > jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> > >> >> 3)",jakarta.interceptor;version="[2.0,3)"
> > >> >> Require-Capability: osgi.ee;filter:="(&(osgi.ee
> > =JavaSE)(version=1.8))"
> > >> >> Tool: Bnd-2.4.1.201501161923
> > >> >> Originally-Created-By: Apache Maven Bundle Plugin
> > >> >> Export-Package:
> > jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> > >> >>
> > ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> > >> >>
> > nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> > >> >>
> > sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> > >> >>
> > arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> > >> >>
> > rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> > >> >>
> > ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> > >> >>
> > til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> > >> >>
> > ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> > >> >> ct.se
> > ;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> > >> >>
> > se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> > >> >>
> > arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> > >> >>
> > ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> > >> >>
> > ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> > >> >>
> > .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> > >> >>
> > karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> > >> >> ise.util",jakarta.enterprise.util;version="3.0"
> > >> >> Bundle-Name: CDI APIs
> > >> >> Bundle-Version: 3.0.0.M4
> > >> >> Build-Jdk-Spec: 1.8
> > >> >> Created-By: Apache Maven Bundle Plugin
> > >> >> Build-Jdk: 1.8.0_202
> > >> >>
> > >> >> Where are the osgi.serviceloader and osgi.contract ?
> > >> >> This is important and used by OSGi-CDI for example (even if it can
> be
> > >> >> worked around).
> > >> >>
> > >> >> So to conclude on this point not belonging to OWB, we still need
> our
> > >> fork
> > >> >> and eclipse always answered saying "yes we want OSGi [but we don't
> > >> really
> > >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they
> > don't
> > >> >> work on that factually so OSGi is done at minimal cost.
> > >> >>
> > >> >>
> > >> >> >
> > >> >> > Gurkan’s proposal will only add difficulty for developers and
> > >> probably
> > >> >> > > users.
> > >> >> > >
> > >> >> > What is the difficulty? The change will only affect maintaining
> the
> > >> >> javax.*
> > >> >> > branch and fully renamed jakarta.* dependencies in master.
> > >> >> >
> > >> >>
> > >> >> Ok Gurkan, let's be concrete, do you - you as you personally -
> accept
> > >> and
> > >> >> commit yourself to port any commit to one of the two branches to
> the
> > >> other
> > >> >> for all the time the project is at apache?
> > >> >> if so fine, if not -1 to create us unneeded (+ still unjustified by
> > >> facts)
> > >> >> work.
> > >> >>
> > >> >>
> > >> >> >
> > >> >> > Regards.
> > >> >> > Gurkan
> > >> >> >
> > >> >> > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <
> > >> david.a.jencks@gmail.com>
> > >> >> > wrote:
> > >> >> >
> > >> >> > > I’m not sure exactly how it impacts this decision, but IIUC the
> > >> >> geronimo
> > >> >> > > cdi spec jar is rather essential for some uses as it has OSGI
> > >> support
> > >> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > >> >> > >
> > >> >> > > Personally I’m afraid I’m totally on Romain’s side so far,
> AFAICT
> > >> >> > Gurkan’s
> > >> >> > > proposal will only add difficulty for developers and probably
> > >> users.
> > >> >> > > Although I haven’t been active here for years I might even
> vote.
> > >> >> > >
> > >> >> > > thanks
> > >> >> > > David Jencks
> > >> >> > >
> > >> >> > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
> > >> >> cgurkanerdogdu@gmail.com>
> > >> >> > > wrote:
> > >> >> > > >
> > >> >> > > >>
> > >> >> > > >> Tomcat works with branches since years without any issue.
> > >> >> > > >> All projects we tried to use branches we abandoned branches
> > just
> > >> >> after
> > >> >> > > >> having done them.
> > >> >> > > >> It is fine if the old branch is no more used but here we
> know
> > we
> > >> >> will
> > >> >> > > >> maintain javax branch more than jakarta one for some time
> so I
> > >> >> think
> > >> >> > we
> > >> >> > > >> should avoid it while it is not justified or one of the 2
> > >> branches
> > >> >> > > (javax)
> > >> >> > > >> is "almost dead".
> > >> >> > > >
> > >> >> > > > Working with branches always happens in all open source
> > projects.
> > >> >> And
> > >> >> > > > there are times when it is logical to create the branch.
> > Jakarta
> > >> EE
> > >> >> 9
> > >> >> > API
> > >> >> > > > migration is the best time to create such a branch.
> Eventually,
> > >> we
> > >> >> will
> > >> >> > > > create such a branch in Jakarta EE 10.
> > >> >> > > >
> > >> >> > > > Fact there will be no more javax is useless IMHO, only
> question
> > >> we
> > >> >> > should
> > >> >> > > >> care about is "do we have javax users?" and should we work
> on
> > >> >> javax
> > >> >> > > branch
> > >> >> > > >> enough to care about having 2 duplicate branches. Answer is
> > >> >> obviously
> > >> >> > > yes
> > >> >> > > >> and more than jakarta users today, therefore I think for
> some
> > >> >> months
> > >> >> > > (maybe
> > >> >> > > >> a few years) we should stick to javax as our primary branch
> > and
> > >> >> ensure
> > >> >> > > the
> > >> >> > > >> alignments and bugfixes can trivially - == without any
> action
> > >> from
> > >> >> dev
> > >> >> > > - be
> > >> >> > > >> ported. It is what we have today.
> > >> >> > > >>
> > >> >> > > > What could be more natural than maintaining branches (with
> > >> >> backporting
> > >> >> > > from
> > >> >> > > > master only if necessary). With Jakarta EE 10, we will
> > eventually
> > >> >> > create
> > >> >> > > > the branch for supporting the EE 8. Also, for the release
> > >> >> versioning,
> > >> >> > it
> > >> >> > > is
> > >> >> > > > nice to have a 3.x release. The community will notice that
> 3.x
> > is
> > >> >> the
> > >> >> > > > starting point of Jakarta EE support. Will you release 2.x
> with
> > >> the
> > >> >> > > > intention of supporting Jakarta EE 9? I am personally not
> > >> positive
> > >> >> on
> > >> >> > > this.
> > >> >> > > > I think, 3.x release will also get more interest even if the
> > >> >> > > functionality
> > >> >> > > > and API stay the same. We can prepare the press release for
> it.
> > >> >> > > >
> > >> >> > > > Note we shouldn't depend on jakarta/javax api anyway (neither
> > as
> > >> >> > groupId
> > >> >> > > >> nor as transitive dep so this change must stay a noop for
> > >> >> consumers).
> > >> >> > > >>
> > >> >> > > > What is the problem of depending on the official Jakarta EE
> CDI
> > >> >> API? It
> > >> >> > > is
> > >> >> > > > an Apache friendly license. Instead of maintaining the
> Geronimo
> > >> CDI
> > >> >> API
> > >> >> > > > internally, it is more logical to use Jakarta EE official CDI
> > API
> > >> >> and
> > >> >> > > > maintain this API with EE4J community.
> > >> >> > > >
> > >> >> > > > would also appreciate if you do a vote if you can point out
> the
> > >> >> > breaking
> > >> >> > > >> changes - except the package renaming - justifying to fork
> > >> ourself
> > >> >> and
> > >> >> > > what
> > >> >> > > >> does not work with current solution, can ease the
> > decision/vote.
> > >> >> > > >> Today using jakarta/EE9 API is quite easy (
> > >> >> > > >>
> > >> >> > >
> > >> >> >
> > >> >>
> > >>
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > >> >> > > >> ).
> > >> >> > > >> We should absolutely enhance the pom experience though but
> it
> > is
> > >> >> > > trivial to
> > >> >> > > >> do at maven level - I was envisionning to do it in shade
> > plugin
> > >> to
> > >> >> be
> > >> >> > > more
> > >> >> > > >> precise.
> > >> >> > > >>
> > >> >> > > > I know that there will be no functional change. But, I am
> also
> > >> >> against
> > >> >> > > > shading for jakarta.*. If there will be no change on Jakarta
> EE
> > >> 10,
> > >> >> > will
> > >> >> > > we
> > >> >> > > > continue to shade? What happens when there will be a change
> in
> > >> EJB,
> > >> >> > JMS
> > >> >> > > > etc specifications but no change in CDI in Jakarta EE 10?
> Also,
> > >> >> VOTING
> > >> >> > is
> > >> >> > > > the natural thing to do for the community decision. If the
> > >> community
> > >> >> > > would
> > >> >> > > > like to keep it as it is via shading, it is fine.
> > >> >> > > >
> > >> >> > > >>
> > >> >> > > >> To try to rephrase/clarify my questionning today: you ask
> for
> > >> >> jakarta
> > >> >> > > >> support, we already have it in a dev and project efficient
> way
> > >> so
> > >> >> why
> > >> >> > > >> should we change since I don't hink there is anything new -
> > once
> > >> >> again
> > >> >> > > if
> > >> >> > > >> API starts to fully break discussion is different but github
> > >> doesnt
> > >> >> > > reflect
> > >> >> > > >> that?
> > >> >> > > >>
> > >> >> > > > This is not just for Jakarta EE 9 support. As we know, there
> > will
> > >> >> be no
> > >> >> > > API
> > >> >> > > > (functional) change, only package renaming. But, I want to
> > >> emphasize
> > >> >> > that
> > >> >> > > > with such turning points, it is so logical to integrate
> > official
> > >> >> > Jakarta
> > >> >> > > > CDI API into our master (removing the geronimo-cdi), and
> > release
> > >> our
> > >> >> > new
> > >> >> > > > 3.x version and let the public know that OWB supports
> official
> > >> CDI
> > >> >> API
> > >> >> > > > beginning with 3.x release. Yeah, shading is an option for
> > >> package
> > >> >> > > renaming
> > >> >> > > > but think long term. Also, I am really against the shading.
> It
> > >> >> really
> > >> >> > > > disturbs the users which depend on OWB implementation. For
> > >> example,
> > >> >> > > > currently Glassfish supports Weld integration but one can
> also
> > >> >> > implement
> > >> >> > > > OWB to replace Weld in Glassfish. Therefore, instead of using
> > the
> > >> >> > shaded
> > >> >> > > > version, it is really important to have the full Jakarta EE
> CDI
> > >> API
> > >> >> in
> > >> >> > > our
> > >> >> > > > poms. You will still have javax.* dependency in ur POMs even
> if
> > >> >> doing a
> > >> >> > > > shade. This is not good idea to still maintain javax.* in our
> > POM
> > >> >> > files.
> > >> >> > > >
> > >> >> > > > What are other opinions before formal voting?
> > >> >> > > > Regards.
> > >> >> > > > Gurkan
> > >> >> > > >
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> > >> >> > rmannibucau@gmail.com
> > >> >> > > >
> > >> >> > > > wrote:
> > >> >> > > >
> > >> >> > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> > >> >> cgurkanerdogdu@gmail.com
> > >> >> > >
> > >> >> > > a
> > >> >> > > >> écrit :
> > >> >> > > >>
> > >> >> > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is
> also
> > on
> > >> >> > master.
> > >> >> > > >>>
> > >> >> > > >>
> > >> >> > > >> Tomcat works with branches since years without any issue.
> > >> >> > > >> All projects we tried to use branches we abandoned branches
> > just
> > >> >> after
> > >> >> > > >> having done them.
> > >> >> > > >> It is fine if the old branch is no more used but here we
> know
> > we
> > >> >> will
> > >> >> > > >> maintain javax branch more than jakarta one for some time
> so I
> > >> >> think
> > >> >> > we
> > >> >> > > >> should avoid it while it is not justified or one of the 2
> > >> branches
> > >> >> > > (javax)
> > >> >> > > >> is "almost dead".
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >>> sorry but not understand the resistance on this? will you
> > >> always
> > >> >> > shade
> > >> >> > > ?
> > >> >> > > >>>
> > >> >> > > >>
> > >> >> > > >> As mentionned, until API needs changes we can't easily
> handle
> > -
> > >> >> today
> > >> >> > > there
> > >> >> > > >> is no change.
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >>> creating the new master and maintain the 2.x branch, is the
> > >> best
> > >> >> > > logical
> > >> >> > > >>> way. there will be no javax.* any more. Tomcat maintains 3
> > >> >> branches
> > >> >> > > and
> > >> >> > > >> 1
> > >> >> > > >>> master. only maintains 1 branch and 1 master is totally
> fine.
> > >> >> > > >>>
> > >> >> > > >>
> > >> >> > > >> Fact there will be no more javax is useless IMHO, only
> > question
> > >> we
> > >> >> > > should
> > >> >> > > >> care about is "do we have javax users?" and should we work
> on
> > >> >> javax
> > >> >> > > branch
> > >> >> > > >> enough to care about having 2 duplicate branches. Answer is
> > >> >> obviously
> > >> >> > > yes
> > >> >> > > >> and more than jakarta users today, therefore I think for
> some
> > >> >> months
> > >> >> > > (maybe
> > >> >> > > >> a few years) we should stick to javax as our primary branch
> > and
> > >> >> ensure
> > >> >> > > the
> > >> >> > > >> alignments and bugfixes can trivially - == without any
> action
> > >> from
> > >> >> dev
> > >> >> > > - be
> > >> >> > > >> ported. It is what we have today.
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >>>
> > >> >> > > >>> I will propose a vote shortly to decide on to create a
> master
> > >> with
> > >> >> > 3.x
> > >> >> > > >> with
> > >> >> > > >>> fully support of jakarta with a normal pom dependency with
> > >> jakarta
> > >> >> > api.
> > >> >> > > >>>
> > >> >> > > >>
> > >> >> > > >> Note we shouldn't depend on jakarta/javax api anyway
> (neither
> > as
> > >> >> > groupId
> > >> >> > > >> nor as transitive dep so this change must stay a noop for
> > >> >> consumers).
> > >> >> > > >> I would also appreciate if you do a vote if you can point
> out
> > >> the
> > >> >> > > breaking
> > >> >> > > >> changes - except the package renaming - justifying to fork
> > >> ourself
> > >> >> and
> > >> >> > > what
> > >> >> > > >> does not work with current solution, can ease the
> > decision/vote.
> > >> >> > > >> Today using jakarta/EE9 API is quite easy (
> > >> >> > > >>
> > >> >> > >
> > >> >> >
> > >> >>
> > >>
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > >> >> > > >> ).
> > >> >> > > >> We should absolutely enhance the pom experience though but
> it
> > is
> > >> >> > > trivial to
> > >> >> > > >> do at maven level - I was envisionning to do it in shade
> > plugin
> > >> to
> > >> >> be
> > >> >> > > more
> > >> >> > > >> precise.
> > >> >> > > >>
> > >> >> > > >> To try to rephrase/clarify my questionning today: you ask
> for
> > >> >> jakarta
> > >> >> > > >> support, we already have it in a dev and project efficient
> way
> > >> so
> > >> >> why
> > >> >> > > >> should we change since I don't hink there is anything new -
> > once
> > >> >> again
> > >> >> > > if
> > >> >> > > >> API starts to fully break discussion is different but github
> > >> doesnt
> > >> >> > > reflect
> > >> >> > > >> that?
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >>>
> > >> >> > > >>> Regs
> > >> >> > > >>> Gurkan
> > >> >> > > >>>
> > >> >> > > >>>
> > >> >> > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
> > >> >> rmannibucau@gmail.com
> > >> >> > >
> > >> >> > > >>> wrote:
> > >> >> > > >>>
> > >> >> > > >>>> Today we don't need, tomorrow I don't know but while API
> > does
> > >> not
> > >> >> > > >> change
> > >> >> > > >>>> (except the package) we shouldn't fork ourself IMHO (cause
> > it
> > >> is
> > >> >> > what
> > >> >> > > >> you
> > >> >> > > >>>> propose as a consequence).
> > >> >> > > >>>> If it becomes necessary let's do it but my vote is to stay
> > >> lazy
> > >> >> on
> > >> >> > > >> that.
> > >> >> > > >>>>
> > >> >> > > >>>>
> > >> >> > > >>>> side note for G API discussion belongs to dev@G but it is
> > >> less
> > >> >> an
> > >> >> > > >> issue
> > >> >> > > >>> to
> > >> >> > > >>>> fork from now since we rarely update the API, the side
> note
> > >> here
> > >> >> is
> > >> >> > > >> that
> > >> >> > > >>>> CDI SE is already fully runnable on ASF stack with jakarta
> > >> >> package
> > >> >> > > >> since
> > >> >> > > >>>> some weeks or months, we did all the needed releases.
> > >> >> > > >>>>
> > >> >> > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > >> >> > > >>>> andraschko.thomas@gmail.com>
> > >> >> > > >>>> a écrit :
> > >> >> > > >>>>
> > >> >> > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our
> > >> build.
> > >> >> > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
> > >> >> > > >>>>>
> > >> >> > > >>>>> I'm actually also a supporter of doing a hard cut but
> it's
> > >> not
> > >> >> > > >> required
> > >> >> > > >>>> and
> > >> >> > > >>>>> we can do it for EE 10.
> > >> >> > > >>>>>
> > >> >> > > >>>>> <
> > >> >> > > >>>>>
> > >> >> > > >>>>
> > >> >> > > >>>
> > >> >> > > >>
> > >> >> > >
> > >> >> >
> > >> >>
> > >>
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > >> >> > > >>>>>>
> > >> >> > > >>>>> Virenfrei.
> > >> >> > > >>>>> www.avast.com
> > >> >> > > >>>>> <
> > >> >> > > >>>>>
> > >> >> > > >>>>
> > >> >> > > >>>
> > >> >> > > >>
> > >> >> > >
> > >> >> >
> > >> >>
> > >>
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > >> >> > > >>>>>>
> > >> >> > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >> >> > > >>>>>
> > >> >> > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu
> <
> > >> >> > > >>>>> cgurkanerdogdu@gmail.com>:
> > >> >> > > >>>>>
> > >> >> > > >>>>>> We need to maintain two branches
> > >> >> > > >>>>>>
> > >> >> > > >>>>>> EE 8 for javax.* package 2.x branch
> > >> >> > > >>>>>> EE 9 for jakarta.* package 3.x master
> > >> >> > > >>>>>>
> > >> >> > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> > >> >> > > >> rmannibucau@gmail.com
> > >> >> > > >>>>
> > >> >> > > >>>>>> wrote:
> > >> >> > > >>>>>>
> > >> >> > > >>>>>>> Hi,
> > >> >> > > >>>>>>>
> > >> >> > > >>>>>>> I'll probably restate my position on that: if EE 9
> brings
> > >> >> > > >>>>> significatively
> > >> >> > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8
> > but
> > >> I
> > >> >> can
> > >> >> > > >>> have
> > >> >> > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can
> > >> stay
> > >> >> as
> > >> >> > > >> we
> > >> >> > > >>>> are
> > >> >> > > >>>>> I
> > >> >> > > >>>>>>> think avoiding to maintain two branches we can't merge
> > >> >> regularly.
> > >> >> > > >>>>>>>
> > >> >> > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > >> >> > > >>>> cgurkanerdogdu@gmail.com>
> > >> >> > > >>>>> a
> > >> >> > > >>>>>>> écrit :
> > >> >> > > >>>>>>>
> > >> >> > > >>>>>>>> Hi
> > >> >> > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0
> to
> > >> >> > > >> support
> > >> >> > > >>>>>> upcoming
> > >> >> > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of
> > >> using
> > >> >> the
> > >> >> > > >>>>> Apache
> > >> >> > > >>>>>>>> based api.
> > >> >> > > >>>>>>>> Regards
> > >> >> > > >>>>>>>> Gurkan
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>> --
> > >> >> > > >>>>>>>> Gurkan Erdogdu
> > >> >> > > >>>>>>>> http://gurkanerdogdu.blogspot.com
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>
> > >> >> > > >>>>>> --
> > >> >> > > >>>>>> Gurkan Erdogdu
> > >> >> > > >>>>>> http://gurkanerdogdu.blogspot.com
> > >> >> > > >>>>>>
> > >> >> > > >>>>>
> > >> >> > > >>>>
> > >> >> > > >>> --
> > >> >> > > >>> Gurkan Erdogdu
> > >> >> > > >>> http://gurkanerdogdu.blogspot.com
> > >> >> > > >>>
> > >> >> > > >>
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > --
> > >> >> > > > Gurkan Erdogdu
> > >> >> > > > http://gurkanerdogdu.blogspot.com
> > >> >> > >
> > >> >> > >
> > >> >> >
> > >> >> > --
> > >> >> > Gurkan Erdogdu
> > >> >> > http://gurkanerdogdu.blogspot.com
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >> > Gurkan Erdogdu
> > >> > http://gurkanerdogdu.blogspot.com
> > >> >
> > >>
> > >>
> > >> --
> > >> Gurkan Erdogdu
> > >> http://gurkanerdogdu.blogspot.com
> > >>
> > >
> >
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Thomas Andraschko <an...@gmail.com>.
Nice work romain!
Am Mo., 8. Juni 2020 um 11:29 Uhr schrieb Romain Manni-Bucau <
rmannibucau@gmail.com>:
> FYI we run jakarta tck now with
> https://issues.apache.org/jira/browse/OWB-1327
> As expected it works fine
>
> 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. 8 juin 2020 à 08:33, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
>
> >
> >
> > Le dim. 7 juin 2020 à 20:48, Gurkan Erdogdu <cg...@gmail.com> a
> > écrit :
> >
> >> > Not, it is not correct Gurkan ;).
> >> > jakarta does NOT support OSGi properly, it does it the old way and
> break
> >> > several rules. For instance last CDI spec jar contains:
> >>
> >> As I said in my previous email, I am not an OSGI expert. But, what I can
> >> do
> >> is that I can ping the CDI team in EE4J to add features to support
> >> OWB-OSGI
> >> or other ASF projects? Could you explain in detail?
> >>
> >
> > OSGi-CDI not OWB-CDI, it is an OSGi spec ;)
> > It is mainly the metadata.
> > Point is we already contacted the spec leaders, even for Microprofile if
> > you want to get the full story (same people more or less) and it didn't
> go
> > well enough even if people were willing to do it.
> > So factually today it is saner to keep it here and it is not an issue for
> > G project anyway since we do it for years and we will keep doing it for
> > defaults at least.
> > Once again not an OWB discussion and decision had been taken already on
> > this one so don't want to loop on the same topic again and again, in
> > particular from the wrong list ;).
> >
> >
> >>
> >> Regards.
> >> Gurkan
> >>
> >> On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu <cgurkanerdogdu@gmail.com
> >
> >> wrote:
> >>
> >> > So to conclude on this point not belonging to OWB, we still need our
> >> fork
> >> >> and eclipse always answered saying "yes we want OSGi [but we don't
> >> really
> >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they
> don't
> >> >> work on that factually so OSGi is done at minimal cost.
> >> >
> >> > OK thanks for the clarification. I am not an OSGI expert.
> >> >
> >> > Ok Gurkan, let's be concrete, do you - you as you personally - accept
> >> and
> >> >> commit yourself to port any commit to one of the two branches to the
> >> other
> >> >> for all the time the project is at apache?
> >> >> if so fine, if not -1 to create us unneeded (+ still unjustified by
> >> facts)
> >> >> work.
> >> >
> >> > :=)
> >> > Hey, I'm just proposing what I think about. If nobody cares about it
> or
> >> > is not beneficial, it is ok, and also there is no need to VOTE (This
> is
> >> why
> >> > I'd like to get more opinions on it). But look at Weld, they did the
> >> > update, https://github.com/weld and full of updating their pom to use
> >> > jakarta.*
> >> >
> >> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
> >> > geronimo-...specs which depend on javax.*. Today or tomorrow, we will
> >> > eventually move to jakarta.* namespace. Instead of working with such
> >> > shading plugin stuff as a workaround, I just offer to take the master
> to
> >> > jakarta.* and update all OWB modules' dependency from javax.* to
> >> jakarta.*
> >> > official APIS. This is not related to who will maintain the branches.
> >> You
> >> > know that ASF works as a voluntary based approach. You can not push
> >> anybody
> >> > to work on anything as in commercial companies.
> >> >
> >> > Also, regarding the cost and energy you mention to maintain the
> branch,
> >> > via Geronimo specs, you will need to update all of the Geronimo Specs
> >> and
> >> > maintain them. I think this is not rational because now, jakarta.*
> >> official
> >> > API license is EPL and Apache friendly. Why do I need to maintain for
> >> > example Geronimo EL?
> >> >
> >> > Regards.
> >> > Gurkan
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <
> >> rmannibucau@gmail.com>
> >> > wrote:
> >> >
> >> >> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <
> cgurkanerdogdu@gmail.com>
> >> a
> >> >> écrit :
> >> >>
> >> >> > Hi David
> >> >> >
> >> >> > I’m not sure exactly how it impacts this decision, but IIUC the
> >> geronimo
> >> >> > > cdi spec jar is rather essential for some uses as it has OSGI
> >> support
> >> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> >> >> > >
> >> >> > No, it is not correct. It has OSGI support. GlassFish is an OSGI
> >> based
> >> >> > server.You can grap the code from
> >> https://github.com/eclipse-ee4j/cdi
> >> >> and
> >> >> > build. It has OSGI enabled MANIFEST.MF file.
> >> >> >
> >> >>
> >> >> Not, it is not correct Gurkan ;).
> >> >> jakarta does NOT support OSGi properly, it does it the old way and
> >> break
> >> >> several rules. For instance last CDI spec jar contains:
> >> >>
> >> >> Manifest-Version: 1.0
> >> >> Bundle-Description: APIs for CDI (Contexts and Dependency Injection
> fo
> >> >> r Java)
> >> >> Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
> >> >> Bundle-SymbolicName: jakarta.enterprise.cdi-api
> >> >> Built-By: default
> >> >> Bnd-LastModified: 1590678420932
> >> >> Bundle-ManifestVersion: 2
> >> >> Bundle-DocURL: https://jboss.org
> >> >> Bundle-Vendor: JBoss by Red Hat, Inc.
> >> >> Import-Package:
> jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> >> >> 3)",jakarta.interceptor;version="[2.0,3)"
> >> >> Require-Capability: osgi.ee;filter:="(&(osgi.ee
> =JavaSE)(version=1.8))"
> >> >> Tool: Bnd-2.4.1.201501161923
> >> >> Originally-Created-By: Apache Maven Bundle Plugin
> >> >> Export-Package:
> jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> >> >>
> ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> >> >>
> nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> >> >>
> sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> >> >>
> arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> >> >>
> rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> >> >>
> ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> >> >>
> til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> >> >>
> ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> >> >> ct.se
> ;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> >> >>
> se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> >> >>
> arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> >> >>
> ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> >> >>
> ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> >> >>
> .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> >> >>
> karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> >> >> ise.util",jakarta.enterprise.util;version="3.0"
> >> >> Bundle-Name: CDI APIs
> >> >> Bundle-Version: 3.0.0.M4
> >> >> Build-Jdk-Spec: 1.8
> >> >> Created-By: Apache Maven Bundle Plugin
> >> >> Build-Jdk: 1.8.0_202
> >> >>
> >> >> Where are the osgi.serviceloader and osgi.contract ?
> >> >> This is important and used by OSGi-CDI for example (even if it can be
> >> >> worked around).
> >> >>
> >> >> So to conclude on this point not belonging to OWB, we still need our
> >> fork
> >> >> and eclipse always answered saying "yes we want OSGi [but we don't
> >> really
> >> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they
> don't
> >> >> work on that factually so OSGi is done at minimal cost.
> >> >>
> >> >>
> >> >> >
> >> >> > Gurkan’s proposal will only add difficulty for developers and
> >> probably
> >> >> > > users.
> >> >> > >
> >> >> > What is the difficulty? The change will only affect maintaining the
> >> >> javax.*
> >> >> > branch and fully renamed jakarta.* dependencies in master.
> >> >> >
> >> >>
> >> >> Ok Gurkan, let's be concrete, do you - you as you personally - accept
> >> and
> >> >> commit yourself to port any commit to one of the two branches to the
> >> other
> >> >> for all the time the project is at apache?
> >> >> if so fine, if not -1 to create us unneeded (+ still unjustified by
> >> facts)
> >> >> work.
> >> >>
> >> >>
> >> >> >
> >> >> > Regards.
> >> >> > Gurkan
> >> >> >
> >> >> > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <
> >> david.a.jencks@gmail.com>
> >> >> > wrote:
> >> >> >
> >> >> > > I’m not sure exactly how it impacts this decision, but IIUC the
> >> >> geronimo
> >> >> > > cdi spec jar is rather essential for some uses as it has OSGI
> >> support
> >> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> >> >> > >
> >> >> > > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT
> >> >> > Gurkan’s
> >> >> > > proposal will only add difficulty for developers and probably
> >> users.
> >> >> > > Although I haven’t been active here for years I might even vote.
> >> >> > >
> >> >> > > thanks
> >> >> > > David Jencks
> >> >> > >
> >> >> > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
> >> >> cgurkanerdogdu@gmail.com>
> >> >> > > wrote:
> >> >> > > >
> >> >> > > >>
> >> >> > > >> Tomcat works with branches since years without any issue.
> >> >> > > >> All projects we tried to use branches we abandoned branches
> just
> >> >> after
> >> >> > > >> having done them.
> >> >> > > >> It is fine if the old branch is no more used but here we know
> we
> >> >> will
> >> >> > > >> maintain javax branch more than jakarta one for some time so I
> >> >> think
> >> >> > we
> >> >> > > >> should avoid it while it is not justified or one of the 2
> >> branches
> >> >> > > (javax)
> >> >> > > >> is "almost dead".
> >> >> > > >
> >> >> > > > Working with branches always happens in all open source
> projects.
> >> >> And
> >> >> > > > there are times when it is logical to create the branch.
> Jakarta
> >> EE
> >> >> 9
> >> >> > API
> >> >> > > > migration is the best time to create such a branch. Eventually,
> >> we
> >> >> will
> >> >> > > > create such a branch in Jakarta EE 10.
> >> >> > > >
> >> >> > > > Fact there will be no more javax is useless IMHO, only question
> >> we
> >> >> > should
> >> >> > > >> care about is "do we have javax users?" and should we work on
> >> >> javax
> >> >> > > branch
> >> >> > > >> enough to care about having 2 duplicate branches. Answer is
> >> >> obviously
> >> >> > > yes
> >> >> > > >> and more than jakarta users today, therefore I think for some
> >> >> months
> >> >> > > (maybe
> >> >> > > >> a few years) we should stick to javax as our primary branch
> and
> >> >> ensure
> >> >> > > the
> >> >> > > >> alignments and bugfixes can trivially - == without any action
> >> from
> >> >> dev
> >> >> > > - be
> >> >> > > >> ported. It is what we have today.
> >> >> > > >>
> >> >> > > > What could be more natural than maintaining branches (with
> >> >> backporting
> >> >> > > from
> >> >> > > > master only if necessary). With Jakarta EE 10, we will
> eventually
> >> >> > create
> >> >> > > > the branch for supporting the EE 8. Also, for the release
> >> >> versioning,
> >> >> > it
> >> >> > > is
> >> >> > > > nice to have a 3.x release. The community will notice that 3.x
> is
> >> >> the
> >> >> > > > starting point of Jakarta EE support. Will you release 2.x with
> >> the
> >> >> > > > intention of supporting Jakarta EE 9? I am personally not
> >> positive
> >> >> on
> >> >> > > this.
> >> >> > > > I think, 3.x release will also get more interest even if the
> >> >> > > functionality
> >> >> > > > and API stay the same. We can prepare the press release for it.
> >> >> > > >
> >> >> > > > Note we shouldn't depend on jakarta/javax api anyway (neither
> as
> >> >> > groupId
> >> >> > > >> nor as transitive dep so this change must stay a noop for
> >> >> consumers).
> >> >> > > >>
> >> >> > > > What is the problem of depending on the official Jakarta EE CDI
> >> >> API? It
> >> >> > > is
> >> >> > > > an Apache friendly license. Instead of maintaining the Geronimo
> >> CDI
> >> >> API
> >> >> > > > internally, it is more logical to use Jakarta EE official CDI
> API
> >> >> and
> >> >> > > > maintain this API with EE4J community.
> >> >> > > >
> >> >> > > > would also appreciate if you do a vote if you can point out the
> >> >> > breaking
> >> >> > > >> changes - except the package renaming - justifying to fork
> >> ourself
> >> >> and
> >> >> > > what
> >> >> > > >> does not work with current solution, can ease the
> decision/vote.
> >> >> > > >> Today using jakarta/EE9 API is quite easy (
> >> >> > > >>
> >> >> > >
> >> >> >
> >> >>
> >>
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> >> >> > > >> ).
> >> >> > > >> We should absolutely enhance the pom experience though but it
> is
> >> >> > > trivial to
> >> >> > > >> do at maven level - I was envisionning to do it in shade
> plugin
> >> to
> >> >> be
> >> >> > > more
> >> >> > > >> precise.
> >> >> > > >>
> >> >> > > > I know that there will be no functional change. But, I am also
> >> >> against
> >> >> > > > shading for jakarta.*. If there will be no change on Jakarta EE
> >> 10,
> >> >> > will
> >> >> > > we
> >> >> > > > continue to shade? What happens when there will be a change in
> >> EJB,
> >> >> > JMS
> >> >> > > > etc specifications but no change in CDI in Jakarta EE 10? Also,
> >> >> VOTING
> >> >> > is
> >> >> > > > the natural thing to do for the community decision. If the
> >> community
> >> >> > > would
> >> >> > > > like to keep it as it is via shading, it is fine.
> >> >> > > >
> >> >> > > >>
> >> >> > > >> To try to rephrase/clarify my questionning today: you ask for
> >> >> jakarta
> >> >> > > >> support, we already have it in a dev and project efficient way
> >> so
> >> >> why
> >> >> > > >> should we change since I don't hink there is anything new -
> once
> >> >> again
> >> >> > > if
> >> >> > > >> API starts to fully break discussion is different but github
> >> doesnt
> >> >> > > reflect
> >> >> > > >> that?
> >> >> > > >>
> >> >> > > > This is not just for Jakarta EE 9 support. As we know, there
> will
> >> >> be no
> >> >> > > API
> >> >> > > > (functional) change, only package renaming. But, I want to
> >> emphasize
> >> >> > that
> >> >> > > > with such turning points, it is so logical to integrate
> official
> >> >> > Jakarta
> >> >> > > > CDI API into our master (removing the geronimo-cdi), and
> release
> >> our
> >> >> > new
> >> >> > > > 3.x version and let the public know that OWB supports official
> >> CDI
> >> >> API
> >> >> > > > beginning with 3.x release. Yeah, shading is an option for
> >> package
> >> >> > > renaming
> >> >> > > > but think long term. Also, I am really against the shading. It
> >> >> really
> >> >> > > > disturbs the users which depend on OWB implementation. For
> >> example,
> >> >> > > > currently Glassfish supports Weld integration but one can also
> >> >> > implement
> >> >> > > > OWB to replace Weld in Glassfish. Therefore, instead of using
> the
> >> >> > shaded
> >> >> > > > version, it is really important to have the full Jakarta EE CDI
> >> API
> >> >> in
> >> >> > > our
> >> >> > > > poms. You will still have javax.* dependency in ur POMs even if
> >> >> doing a
> >> >> > > > shade. This is not good idea to still maintain javax.* in our
> POM
> >> >> > files.
> >> >> > > >
> >> >> > > > What are other opinions before formal voting?
> >> >> > > > Regards.
> >> >> > > > Gurkan
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> >> >> > rmannibucau@gmail.com
> >> >> > > >
> >> >> > > > wrote:
> >> >> > > >
> >> >> > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> >> >> cgurkanerdogdu@gmail.com
> >> >> > >
> >> >> > > a
> >> >> > > >> écrit :
> >> >> > > >>
> >> >> > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also
> on
> >> >> > master.
> >> >> > > >>>
> >> >> > > >>
> >> >> > > >> Tomcat works with branches since years without any issue.
> >> >> > > >> All projects we tried to use branches we abandoned branches
> just
> >> >> after
> >> >> > > >> having done them.
> >> >> > > >> It is fine if the old branch is no more used but here we know
> we
> >> >> will
> >> >> > > >> maintain javax branch more than jakarta one for some time so I
> >> >> think
> >> >> > we
> >> >> > > >> should avoid it while it is not justified or one of the 2
> >> branches
> >> >> > > (javax)
> >> >> > > >> is "almost dead".
> >> >> > > >>
> >> >> > > >>
> >> >> > > >>> sorry but not understand the resistance on this? will you
> >> always
> >> >> > shade
> >> >> > > ?
> >> >> > > >>>
> >> >> > > >>
> >> >> > > >> As mentionned, until API needs changes we can't easily handle
> -
> >> >> today
> >> >> > > there
> >> >> > > >> is no change.
> >> >> > > >>
> >> >> > > >>
> >> >> > > >>> creating the new master and maintain the 2.x branch, is the
> >> best
> >> >> > > logical
> >> >> > > >>> way. there will be no javax.* any more. Tomcat maintains 3
> >> >> branches
> >> >> > > and
> >> >> > > >> 1
> >> >> > > >>> master. only maintains 1 branch and 1 master is totally fine.
> >> >> > > >>>
> >> >> > > >>
> >> >> > > >> Fact there will be no more javax is useless IMHO, only
> question
> >> we
> >> >> > > should
> >> >> > > >> care about is "do we have javax users?" and should we work on
> >> >> javax
> >> >> > > branch
> >> >> > > >> enough to care about having 2 duplicate branches. Answer is
> >> >> obviously
> >> >> > > yes
> >> >> > > >> and more than jakarta users today, therefore I think for some
> >> >> months
> >> >> > > (maybe
> >> >> > > >> a few years) we should stick to javax as our primary branch
> and
> >> >> ensure
> >> >> > > the
> >> >> > > >> alignments and bugfixes can trivially - == without any action
> >> from
> >> >> dev
> >> >> > > - be
> >> >> > > >> ported. It is what we have today.
> >> >> > > >>
> >> >> > > >>
> >> >> > > >>>
> >> >> > > >>> I will propose a vote shortly to decide on to create a master
> >> with
> >> >> > 3.x
> >> >> > > >> with
> >> >> > > >>> fully support of jakarta with a normal pom dependency with
> >> jakarta
> >> >> > api.
> >> >> > > >>>
> >> >> > > >>
> >> >> > > >> Note we shouldn't depend on jakarta/javax api anyway (neither
> as
> >> >> > groupId
> >> >> > > >> nor as transitive dep so this change must stay a noop for
> >> >> consumers).
> >> >> > > >> I would also appreciate if you do a vote if you can point out
> >> the
> >> >> > > breaking
> >> >> > > >> changes - except the package renaming - justifying to fork
> >> ourself
> >> >> and
> >> >> > > what
> >> >> > > >> does not work with current solution, can ease the
> decision/vote.
> >> >> > > >> Today using jakarta/EE9 API is quite easy (
> >> >> > > >>
> >> >> > >
> >> >> >
> >> >>
> >>
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> >> >> > > >> ).
> >> >> > > >> We should absolutely enhance the pom experience though but it
> is
> >> >> > > trivial to
> >> >> > > >> do at maven level - I was envisionning to do it in shade
> plugin
> >> to
> >> >> be
> >> >> > > more
> >> >> > > >> precise.
> >> >> > > >>
> >> >> > > >> To try to rephrase/clarify my questionning today: you ask for
> >> >> jakarta
> >> >> > > >> support, we already have it in a dev and project efficient way
> >> so
> >> >> why
> >> >> > > >> should we change since I don't hink there is anything new -
> once
> >> >> again
> >> >> > > if
> >> >> > > >> API starts to fully break discussion is different but github
> >> doesnt
> >> >> > > reflect
> >> >> > > >> that?
> >> >> > > >>
> >> >> > > >>
> >> >> > > >>>
> >> >> > > >>> Regs
> >> >> > > >>> Gurkan
> >> >> > > >>>
> >> >> > > >>>
> >> >> > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
> >> >> rmannibucau@gmail.com
> >> >> > >
> >> >> > > >>> wrote:
> >> >> > > >>>
> >> >> > > >>>> Today we don't need, tomorrow I don't know but while API
> does
> >> not
> >> >> > > >> change
> >> >> > > >>>> (except the package) we shouldn't fork ourself IMHO (cause
> it
> >> is
> >> >> > what
> >> >> > > >> you
> >> >> > > >>>> propose as a consequence).
> >> >> > > >>>> If it becomes necessary let's do it but my vote is to stay
> >> lazy
> >> >> on
> >> >> > > >> that.
> >> >> > > >>>>
> >> >> > > >>>>
> >> >> > > >>>> side note for G API discussion belongs to dev@G but it is
> >> less
> >> >> an
> >> >> > > >> issue
> >> >> > > >>> to
> >> >> > > >>>> fork from now since we rarely update the API, the side note
> >> here
> >> >> is
> >> >> > > >> that
> >> >> > > >>>> CDI SE is already fully runnable on ASF stack with jakarta
> >> >> package
> >> >> > > >> since
> >> >> > > >>>> some weeks or months, we did all the needed releases.
> >> >> > > >>>>
> >> >> > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> >> >> > > >>>> andraschko.thomas@gmail.com>
> >> >> > > >>>> a écrit :
> >> >> > > >>>>
> >> >> > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our
> >> build.
> >> >> > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
> >> >> > > >>>>>
> >> >> > > >>>>> I'm actually also a supporter of doing a hard cut but it's
> >> not
> >> >> > > >> required
> >> >> > > >>>> and
> >> >> > > >>>>> we can do it for EE 10.
> >> >> > > >>>>>
> >> >> > > >>>>> <
> >> >> > > >>>>>
> >> >> > > >>>>
> >> >> > > >>>
> >> >> > > >>
> >> >> > >
> >> >> >
> >> >>
> >>
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >> >> > > >>>>>>
> >> >> > > >>>>> Virenfrei.
> >> >> > > >>>>> www.avast.com
> >> >> > > >>>>> <
> >> >> > > >>>>>
> >> >> > > >>>>
> >> >> > > >>>
> >> >> > > >>
> >> >> > >
> >> >> >
> >> >>
> >>
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >> >> > > >>>>>>
> >> >> > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >> >> > > >>>>>
> >> >> > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> >> >> > > >>>>> cgurkanerdogdu@gmail.com>:
> >> >> > > >>>>>
> >> >> > > >>>>>> We need to maintain two branches
> >> >> > > >>>>>>
> >> >> > > >>>>>> EE 8 for javax.* package 2.x branch
> >> >> > > >>>>>> EE 9 for jakarta.* package 3.x master
> >> >> > > >>>>>>
> >> >> > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> >> >> > > >> rmannibucau@gmail.com
> >> >> > > >>>>
> >> >> > > >>>>>> wrote:
> >> >> > > >>>>>>
> >> >> > > >>>>>>> Hi,
> >> >> > > >>>>>>>
> >> >> > > >>>>>>> I'll probably restate my position on that: if EE 9 brings
> >> >> > > >>>>> significatively
> >> >> > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8
> but
> >> I
> >> >> can
> >> >> > > >>> have
> >> >> > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can
> >> stay
> >> >> as
> >> >> > > >> we
> >> >> > > >>>> are
> >> >> > > >>>>> I
> >> >> > > >>>>>>> think avoiding to maintain two branches we can't merge
> >> >> regularly.
> >> >> > > >>>>>>>
> >> >> > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> >> >> > > >>>> cgurkanerdogdu@gmail.com>
> >> >> > > >>>>> a
> >> >> > > >>>>>>> écrit :
> >> >> > > >>>>>>>
> >> >> > > >>>>>>>> Hi
> >> >> > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
> >> >> > > >> support
> >> >> > > >>>>>> upcoming
> >> >> > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of
> >> using
> >> >> the
> >> >> > > >>>>> Apache
> >> >> > > >>>>>>>> based api.
> >> >> > > >>>>>>>> Regards
> >> >> > > >>>>>>>> Gurkan
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>>> --
> >> >> > > >>>>>>>> Gurkan Erdogdu
> >> >> > > >>>>>>>> http://gurkanerdogdu.blogspot.com
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>>
> >> >> > > >>>>>> --
> >> >> > > >>>>>> Gurkan Erdogdu
> >> >> > > >>>>>> http://gurkanerdogdu.blogspot.com
> >> >> > > >>>>>>
> >> >> > > >>>>>
> >> >> > > >>>>
> >> >> > > >>> --
> >> >> > > >>> Gurkan Erdogdu
> >> >> > > >>> http://gurkanerdogdu.blogspot.com
> >> >> > > >>>
> >> >> > > >>
> >> >> > > >
> >> >> > > >
> >> >> > > > --
> >> >> > > > Gurkan Erdogdu
> >> >> > > > http://gurkanerdogdu.blogspot.com
> >> >> > >
> >> >> > >
> >> >> >
> >> >> > --
> >> >> > Gurkan Erdogdu
> >> >> > http://gurkanerdogdu.blogspot.com
> >> >> >
> >> >>
> >> >
> >> >
> >> > --
> >> > Gurkan Erdogdu
> >> > http://gurkanerdogdu.blogspot.com
> >> >
> >>
> >>
> >> --
> >> Gurkan Erdogdu
> >> http://gurkanerdogdu.blogspot.com
> >>
> >
>
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
FYI we run jakarta tck now with
https://issues.apache.org/jira/browse/OWB-1327
As expected it works fine
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. 8 juin 2020 à 08:33, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
>
>
> Le dim. 7 juin 2020 à 20:48, Gurkan Erdogdu <cg...@gmail.com> a
> écrit :
>
>> > Not, it is not correct Gurkan ;).
>> > jakarta does NOT support OSGi properly, it does it the old way and break
>> > several rules. For instance last CDI spec jar contains:
>>
>> As I said in my previous email, I am not an OSGI expert. But, what I can
>> do
>> is that I can ping the CDI team in EE4J to add features to support
>> OWB-OSGI
>> or other ASF projects? Could you explain in detail?
>>
>
> OSGi-CDI not OWB-CDI, it is an OSGi spec ;)
> It is mainly the metadata.
> Point is we already contacted the spec leaders, even for Microprofile if
> you want to get the full story (same people more or less) and it didn't go
> well enough even if people were willing to do it.
> So factually today it is saner to keep it here and it is not an issue for
> G project anyway since we do it for years and we will keep doing it for
> defaults at least.
> Once again not an OWB discussion and decision had been taken already on
> this one so don't want to loop on the same topic again and again, in
> particular from the wrong list ;).
>
>
>>
>> Regards.
>> Gurkan
>>
>> On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu <cg...@gmail.com>
>> wrote:
>>
>> > So to conclude on this point not belonging to OWB, we still need our
>> fork
>> >> and eclipse always answered saying "yes we want OSGi [but we don't
>> really
>> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
>> >> work on that factually so OSGi is done at minimal cost.
>> >
>> > OK thanks for the clarification. I am not an OSGI expert.
>> >
>> > Ok Gurkan, let's be concrete, do you - you as you personally - accept
>> and
>> >> commit yourself to port any commit to one of the two branches to the
>> other
>> >> for all the time the project is at apache?
>> >> if so fine, if not -1 to create us unneeded (+ still unjustified by
>> facts)
>> >> work.
>> >
>> > :=)
>> > Hey, I'm just proposing what I think about. If nobody cares about it or
>> > is not beneficial, it is ok, and also there is no need to VOTE (This is
>> why
>> > I'd like to get more opinions on it). But look at Weld, they did the
>> > update, https://github.com/weld and full of updating their pom to use
>> > jakarta.*
>> >
>> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
>> > geronimo-...specs which depend on javax.*. Today or tomorrow, we will
>> > eventually move to jakarta.* namespace. Instead of working with such
>> > shading plugin stuff as a workaround, I just offer to take the master to
>> > jakarta.* and update all OWB modules' dependency from javax.* to
>> jakarta.*
>> > official APIS. This is not related to who will maintain the branches.
>> You
>> > know that ASF works as a voluntary based approach. You can not push
>> anybody
>> > to work on anything as in commercial companies.
>> >
>> > Also, regarding the cost and energy you mention to maintain the branch,
>> > via Geronimo specs, you will need to update all of the Geronimo Specs
>> and
>> > maintain them. I think this is not rational because now, jakarta.*
>> official
>> > API license is EPL and Apache friendly. Why do I need to maintain for
>> > example Geronimo EL?
>> >
>> > Regards.
>> > Gurkan
>> >
>> >
>> >
>> >
>> >
>> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > wrote:
>> >
>> >> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cg...@gmail.com>
>> a
>> >> écrit :
>> >>
>> >> > Hi David
>> >> >
>> >> > I’m not sure exactly how it impacts this decision, but IIUC the
>> geronimo
>> >> > > cdi spec jar is rather essential for some uses as it has OSGI
>> support
>> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
>> >> > >
>> >> > No, it is not correct. It has OSGI support. GlassFish is an OSGI
>> based
>> >> > server.You can grap the code from
>> https://github.com/eclipse-ee4j/cdi
>> >> and
>> >> > build. It has OSGI enabled MANIFEST.MF file.
>> >> >
>> >>
>> >> Not, it is not correct Gurkan ;).
>> >> jakarta does NOT support OSGi properly, it does it the old way and
>> break
>> >> several rules. For instance last CDI spec jar contains:
>> >>
>> >> Manifest-Version: 1.0
>> >> Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
>> >> r Java)
>> >> Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
>> >> Bundle-SymbolicName: jakarta.enterprise.cdi-api
>> >> Built-By: default
>> >> Bnd-LastModified: 1590678420932
>> >> Bundle-ManifestVersion: 2
>> >> Bundle-DocURL: https://jboss.org
>> >> Bundle-Vendor: JBoss by Red Hat, Inc.
>> >> Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
>> >> 3)",jakarta.interceptor;version="[2.0,3)"
>> >> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
>> >> Tool: Bnd-2.4.1.201501161923
>> >> Originally-Created-By: Apache Maven Bundle Plugin
>> >> Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
>> >> ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
>> >> nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
>> >> sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
>> >> arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
>> >> rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
>> >> ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
>> >> til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
>> >> ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
>> >> ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
>> >> se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
>> >> arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
>> >> ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
>> >> ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
>> >> .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
>> >> karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
>> >> ise.util",jakarta.enterprise.util;version="3.0"
>> >> Bundle-Name: CDI APIs
>> >> Bundle-Version: 3.0.0.M4
>> >> Build-Jdk-Spec: 1.8
>> >> Created-By: Apache Maven Bundle Plugin
>> >> Build-Jdk: 1.8.0_202
>> >>
>> >> Where are the osgi.serviceloader and osgi.contract ?
>> >> This is important and used by OSGi-CDI for example (even if it can be
>> >> worked around).
>> >>
>> >> So to conclude on this point not belonging to OWB, we still need our
>> fork
>> >> and eclipse always answered saying "yes we want OSGi [but we don't
>> really
>> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
>> >> work on that factually so OSGi is done at minimal cost.
>> >>
>> >>
>> >> >
>> >> > Gurkan’s proposal will only add difficulty for developers and
>> probably
>> >> > > users.
>> >> > >
>> >> > What is the difficulty? The change will only affect maintaining the
>> >> javax.*
>> >> > branch and fully renamed jakarta.* dependencies in master.
>> >> >
>> >>
>> >> Ok Gurkan, let's be concrete, do you - you as you personally - accept
>> and
>> >> commit yourself to port any commit to one of the two branches to the
>> other
>> >> for all the time the project is at apache?
>> >> if so fine, if not -1 to create us unneeded (+ still unjustified by
>> facts)
>> >> work.
>> >>
>> >>
>> >> >
>> >> > Regards.
>> >> > Gurkan
>> >> >
>> >> > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <
>> david.a.jencks@gmail.com>
>> >> > wrote:
>> >> >
>> >> > > I’m not sure exactly how it impacts this decision, but IIUC the
>> >> geronimo
>> >> > > cdi spec jar is rather essential for some uses as it has OSGI
>> support
>> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
>> >> > >
>> >> > > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT
>> >> > Gurkan’s
>> >> > > proposal will only add difficulty for developers and probably
>> users.
>> >> > > Although I haven’t been active here for years I might even vote.
>> >> > >
>> >> > > thanks
>> >> > > David Jencks
>> >> > >
>> >> > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
>> >> cgurkanerdogdu@gmail.com>
>> >> > > wrote:
>> >> > > >
>> >> > > >>
>> >> > > >> Tomcat works with branches since years without any issue.
>> >> > > >> All projects we tried to use branches we abandoned branches just
>> >> after
>> >> > > >> having done them.
>> >> > > >> It is fine if the old branch is no more used but here we know we
>> >> will
>> >> > > >> maintain javax branch more than jakarta one for some time so I
>> >> think
>> >> > we
>> >> > > >> should avoid it while it is not justified or one of the 2
>> branches
>> >> > > (javax)
>> >> > > >> is "almost dead".
>> >> > > >
>> >> > > > Working with branches always happens in all open source projects.
>> >> And
>> >> > > > there are times when it is logical to create the branch. Jakarta
>> EE
>> >> 9
>> >> > API
>> >> > > > migration is the best time to create such a branch. Eventually,
>> we
>> >> will
>> >> > > > create such a branch in Jakarta EE 10.
>> >> > > >
>> >> > > > Fact there will be no more javax is useless IMHO, only question
>> we
>> >> > should
>> >> > > >> care about is "do we have javax users?" and should we work on
>> >> javax
>> >> > > branch
>> >> > > >> enough to care about having 2 duplicate branches. Answer is
>> >> obviously
>> >> > > yes
>> >> > > >> and more than jakarta users today, therefore I think for some
>> >> months
>> >> > > (maybe
>> >> > > >> a few years) we should stick to javax as our primary branch and
>> >> ensure
>> >> > > the
>> >> > > >> alignments and bugfixes can trivially - == without any action
>> from
>> >> dev
>> >> > > - be
>> >> > > >> ported. It is what we have today.
>> >> > > >>
>> >> > > > What could be more natural than maintaining branches (with
>> >> backporting
>> >> > > from
>> >> > > > master only if necessary). With Jakarta EE 10, we will eventually
>> >> > create
>> >> > > > the branch for supporting the EE 8. Also, for the release
>> >> versioning,
>> >> > it
>> >> > > is
>> >> > > > nice to have a 3.x release. The community will notice that 3.x is
>> >> the
>> >> > > > starting point of Jakarta EE support. Will you release 2.x with
>> the
>> >> > > > intention of supporting Jakarta EE 9? I am personally not
>> positive
>> >> on
>> >> > > this.
>> >> > > > I think, 3.x release will also get more interest even if the
>> >> > > functionality
>> >> > > > and API stay the same. We can prepare the press release for it.
>> >> > > >
>> >> > > > Note we shouldn't depend on jakarta/javax api anyway (neither as
>> >> > groupId
>> >> > > >> nor as transitive dep so this change must stay a noop for
>> >> consumers).
>> >> > > >>
>> >> > > > What is the problem of depending on the official Jakarta EE CDI
>> >> API? It
>> >> > > is
>> >> > > > an Apache friendly license. Instead of maintaining the Geronimo
>> CDI
>> >> API
>> >> > > > internally, it is more logical to use Jakarta EE official CDI API
>> >> and
>> >> > > > maintain this API with EE4J community.
>> >> > > >
>> >> > > > would also appreciate if you do a vote if you can point out the
>> >> > breaking
>> >> > > >> changes - except the package renaming - justifying to fork
>> ourself
>> >> and
>> >> > > what
>> >> > > >> does not work with current solution, can ease the decision/vote.
>> >> > > >> Today using jakarta/EE9 API is quite easy (
>> >> > > >>
>> >> > >
>> >> >
>> >>
>> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
>> >> > > >> ).
>> >> > > >> We should absolutely enhance the pom experience though but it is
>> >> > > trivial to
>> >> > > >> do at maven level - I was envisionning to do it in shade plugin
>> to
>> >> be
>> >> > > more
>> >> > > >> precise.
>> >> > > >>
>> >> > > > I know that there will be no functional change. But, I am also
>> >> against
>> >> > > > shading for jakarta.*. If there will be no change on Jakarta EE
>> 10,
>> >> > will
>> >> > > we
>> >> > > > continue to shade? What happens when there will be a change in
>> EJB,
>> >> > JMS
>> >> > > > etc specifications but no change in CDI in Jakarta EE 10? Also,
>> >> VOTING
>> >> > is
>> >> > > > the natural thing to do for the community decision. If the
>> community
>> >> > > would
>> >> > > > like to keep it as it is via shading, it is fine.
>> >> > > >
>> >> > > >>
>> >> > > >> To try to rephrase/clarify my questionning today: you ask for
>> >> jakarta
>> >> > > >> support, we already have it in a dev and project efficient way
>> so
>> >> why
>> >> > > >> should we change since I don't hink there is anything new - once
>> >> again
>> >> > > if
>> >> > > >> API starts to fully break discussion is different but github
>> doesnt
>> >> > > reflect
>> >> > > >> that?
>> >> > > >>
>> >> > > > This is not just for Jakarta EE 9 support. As we know, there will
>> >> be no
>> >> > > API
>> >> > > > (functional) change, only package renaming. But, I want to
>> emphasize
>> >> > that
>> >> > > > with such turning points, it is so logical to integrate official
>> >> > Jakarta
>> >> > > > CDI API into our master (removing the geronimo-cdi), and release
>> our
>> >> > new
>> >> > > > 3.x version and let the public know that OWB supports official
>> CDI
>> >> API
>> >> > > > beginning with 3.x release. Yeah, shading is an option for
>> package
>> >> > > renaming
>> >> > > > but think long term. Also, I am really against the shading. It
>> >> really
>> >> > > > disturbs the users which depend on OWB implementation. For
>> example,
>> >> > > > currently Glassfish supports Weld integration but one can also
>> >> > implement
>> >> > > > OWB to replace Weld in Glassfish. Therefore, instead of using the
>> >> > shaded
>> >> > > > version, it is really important to have the full Jakarta EE CDI
>> API
>> >> in
>> >> > > our
>> >> > > > poms. You will still have javax.* dependency in ur POMs even if
>> >> doing a
>> >> > > > shade. This is not good idea to still maintain javax.* in our POM
>> >> > files.
>> >> > > >
>> >> > > > What are other opinions before formal voting?
>> >> > > > Regards.
>> >> > > > Gurkan
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
>> >> > rmannibucau@gmail.com
>> >> > > >
>> >> > > > wrote:
>> >> > > >
>> >> > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
>> >> cgurkanerdogdu@gmail.com
>> >> > >
>> >> > > a
>> >> > > >> écrit :
>> >> > > >>
>> >> > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on
>> >> > master.
>> >> > > >>>
>> >> > > >>
>> >> > > >> Tomcat works with branches since years without any issue.
>> >> > > >> All projects we tried to use branches we abandoned branches just
>> >> after
>> >> > > >> having done them.
>> >> > > >> It is fine if the old branch is no more used but here we know we
>> >> will
>> >> > > >> maintain javax branch more than jakarta one for some time so I
>> >> think
>> >> > we
>> >> > > >> should avoid it while it is not justified or one of the 2
>> branches
>> >> > > (javax)
>> >> > > >> is "almost dead".
>> >> > > >>
>> >> > > >>
>> >> > > >>> sorry but not understand the resistance on this? will you
>> always
>> >> > shade
>> >> > > ?
>> >> > > >>>
>> >> > > >>
>> >> > > >> As mentionned, until API needs changes we can't easily handle -
>> >> today
>> >> > > there
>> >> > > >> is no change.
>> >> > > >>
>> >> > > >>
>> >> > > >>> creating the new master and maintain the 2.x branch, is the
>> best
>> >> > > logical
>> >> > > >>> way. there will be no javax.* any more. Tomcat maintains 3
>> >> branches
>> >> > > and
>> >> > > >> 1
>> >> > > >>> master. only maintains 1 branch and 1 master is totally fine.
>> >> > > >>>
>> >> > > >>
>> >> > > >> Fact there will be no more javax is useless IMHO, only question
>> we
>> >> > > should
>> >> > > >> care about is "do we have javax users?" and should we work on
>> >> javax
>> >> > > branch
>> >> > > >> enough to care about having 2 duplicate branches. Answer is
>> >> obviously
>> >> > > yes
>> >> > > >> and more than jakarta users today, therefore I think for some
>> >> months
>> >> > > (maybe
>> >> > > >> a few years) we should stick to javax as our primary branch and
>> >> ensure
>> >> > > the
>> >> > > >> alignments and bugfixes can trivially - == without any action
>> from
>> >> dev
>> >> > > - be
>> >> > > >> ported. It is what we have today.
>> >> > > >>
>> >> > > >>
>> >> > > >>>
>> >> > > >>> I will propose a vote shortly to decide on to create a master
>> with
>> >> > 3.x
>> >> > > >> with
>> >> > > >>> fully support of jakarta with a normal pom dependency with
>> jakarta
>> >> > api.
>> >> > > >>>
>> >> > > >>
>> >> > > >> Note we shouldn't depend on jakarta/javax api anyway (neither as
>> >> > groupId
>> >> > > >> nor as transitive dep so this change must stay a noop for
>> >> consumers).
>> >> > > >> I would also appreciate if you do a vote if you can point out
>> the
>> >> > > breaking
>> >> > > >> changes - except the package renaming - justifying to fork
>> ourself
>> >> and
>> >> > > what
>> >> > > >> does not work with current solution, can ease the decision/vote.
>> >> > > >> Today using jakarta/EE9 API is quite easy (
>> >> > > >>
>> >> > >
>> >> >
>> >>
>> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
>> >> > > >> ).
>> >> > > >> We should absolutely enhance the pom experience though but it is
>> >> > > trivial to
>> >> > > >> do at maven level - I was envisionning to do it in shade plugin
>> to
>> >> be
>> >> > > more
>> >> > > >> precise.
>> >> > > >>
>> >> > > >> To try to rephrase/clarify my questionning today: you ask for
>> >> jakarta
>> >> > > >> support, we already have it in a dev and project efficient way
>> so
>> >> why
>> >> > > >> should we change since I don't hink there is anything new - once
>> >> again
>> >> > > if
>> >> > > >> API starts to fully break discussion is different but github
>> doesnt
>> >> > > reflect
>> >> > > >> that?
>> >> > > >>
>> >> > > >>
>> >> > > >>>
>> >> > > >>> Regs
>> >> > > >>> Gurkan
>> >> > > >>>
>> >> > > >>>
>> >> > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
>> >> rmannibucau@gmail.com
>> >> > >
>> >> > > >>> wrote:
>> >> > > >>>
>> >> > > >>>> Today we don't need, tomorrow I don't know but while API does
>> not
>> >> > > >> change
>> >> > > >>>> (except the package) we shouldn't fork ourself IMHO (cause it
>> is
>> >> > what
>> >> > > >> you
>> >> > > >>>> propose as a consequence).
>> >> > > >>>> If it becomes necessary let's do it but my vote is to stay
>> lazy
>> >> on
>> >> > > >> that.
>> >> > > >>>>
>> >> > > >>>>
>> >> > > >>>> side note for G API discussion belongs to dev@G but it is
>> less
>> >> an
>> >> > > >> issue
>> >> > > >>> to
>> >> > > >>>> fork from now since we rarely update the API, the side note
>> here
>> >> is
>> >> > > >> that
>> >> > > >>>> CDI SE is already fully runnable on ASF stack with jakarta
>> >> package
>> >> > > >> since
>> >> > > >>>> some weeks or months, we did all the needed releases.
>> >> > > >>>>
>> >> > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
>> >> > > >>>> andraschko.thomas@gmail.com>
>> >> > > >>>> a écrit :
>> >> > > >>>>
>> >> > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our
>> build.
>> >> > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
>> >> > > >>>>>
>> >> > > >>>>> I'm actually also a supporter of doing a hard cut but it's
>> not
>> >> > > >> required
>> >> > > >>>> and
>> >> > > >>>>> we can do it for EE 10.
>> >> > > >>>>>
>> >> > > >>>>> <
>> >> > > >>>>>
>> >> > > >>>>
>> >> > > >>>
>> >> > > >>
>> >> > >
>> >> >
>> >>
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>> >> > > >>>>>>
>> >> > > >>>>> Virenfrei.
>> >> > > >>>>> www.avast.com
>> >> > > >>>>> <
>> >> > > >>>>>
>> >> > > >>>>
>> >> > > >>>
>> >> > > >>
>> >> > >
>> >> >
>> >>
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>> >> > > >>>>>>
>> >> > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> >> > > >>>>>
>> >> > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
>> >> > > >>>>> cgurkanerdogdu@gmail.com>:
>> >> > > >>>>>
>> >> > > >>>>>> We need to maintain two branches
>> >> > > >>>>>>
>> >> > > >>>>>> EE 8 for javax.* package 2.x branch
>> >> > > >>>>>> EE 9 for jakarta.* package 3.x master
>> >> > > >>>>>>
>> >> > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
>> >> > > >> rmannibucau@gmail.com
>> >> > > >>>>
>> >> > > >>>>>> wrote:
>> >> > > >>>>>>
>> >> > > >>>>>>> Hi,
>> >> > > >>>>>>>
>> >> > > >>>>>>> I'll probably restate my position on that: if EE 9 brings
>> >> > > >>>>> significatively
>> >> > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but
>> I
>> >> can
>> >> > > >>> have
>> >> > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can
>> stay
>> >> as
>> >> > > >> we
>> >> > > >>>> are
>> >> > > >>>>> I
>> >> > > >>>>>>> think avoiding to maintain two branches we can't merge
>> >> regularly.
>> >> > > >>>>>>>
>> >> > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
>> >> > > >>>> cgurkanerdogdu@gmail.com>
>> >> > > >>>>> a
>> >> > > >>>>>>> écrit :
>> >> > > >>>>>>>
>> >> > > >>>>>>>> Hi
>> >> > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
>> >> > > >> support
>> >> > > >>>>>> upcoming
>> >> > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of
>> using
>> >> the
>> >> > > >>>>> Apache
>> >> > > >>>>>>>> based api.
>> >> > > >>>>>>>> Regards
>> >> > > >>>>>>>> Gurkan
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> --
>> >> > > >>>>>>>> Gurkan Erdogdu
>> >> > > >>>>>>>> http://gurkanerdogdu.blogspot.com
>> >> > > >>>>>>>>
>> >> > > >>>>>>>
>> >> > > >>>>>> --
>> >> > > >>>>>> Gurkan Erdogdu
>> >> > > >>>>>> http://gurkanerdogdu.blogspot.com
>> >> > > >>>>>>
>> >> > > >>>>>
>> >> > > >>>>
>> >> > > >>> --
>> >> > > >>> Gurkan Erdogdu
>> >> > > >>> http://gurkanerdogdu.blogspot.com
>> >> > > >>>
>> >> > > >>
>> >> > > >
>> >> > > >
>> >> > > > --
>> >> > > > Gurkan Erdogdu
>> >> > > > http://gurkanerdogdu.blogspot.com
>> >> > >
>> >> > >
>> >> >
>> >> > --
>> >> > Gurkan Erdogdu
>> >> > http://gurkanerdogdu.blogspot.com
>> >> >
>> >>
>> >
>> >
>> > --
>> > Gurkan Erdogdu
>> > http://gurkanerdogdu.blogspot.com
>> >
>>
>>
>> --
>> Gurkan Erdogdu
>> http://gurkanerdogdu.blogspot.com
>>
>
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 7 juin 2020 à 20:48, Gurkan Erdogdu <cg...@gmail.com> a
écrit :
> > Not, it is not correct Gurkan ;).
> > jakarta does NOT support OSGi properly, it does it the old way and break
> > several rules. For instance last CDI spec jar contains:
>
> As I said in my previous email, I am not an OSGI expert. But, what I can do
> is that I can ping the CDI team in EE4J to add features to support OWB-OSGI
> or other ASF projects? Could you explain in detail?
>
OSGi-CDI not OWB-CDI, it is an OSGi spec ;)
It is mainly the metadata.
Point is we already contacted the spec leaders, even for Microprofile if
you want to get the full story (same people more or less) and it didn't go
well enough even if people were willing to do it.
So factually today it is saner to keep it here and it is not an issue for G
project anyway since we do it for years and we will keep doing it for
defaults at least.
Once again not an OWB discussion and decision had been taken already on
this one so don't want to loop on the same topic again and again, in
particular from the wrong list ;).
>
> Regards.
> Gurkan
>
> On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu <cg...@gmail.com>
> wrote:
>
> > So to conclude on this point not belonging to OWB, we still need our fork
> >> and eclipse always answered saying "yes we want OSGi [but we don't
> really
> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> >> work on that factually so OSGi is done at minimal cost.
> >
> > OK thanks for the clarification. I am not an OSGI expert.
> >
> > Ok Gurkan, let's be concrete, do you - you as you personally - accept and
> >> commit yourself to port any commit to one of the two branches to the
> other
> >> for all the time the project is at apache?
> >> if so fine, if not -1 to create us unneeded (+ still unjustified by
> facts)
> >> work.
> >
> > :=)
> > Hey, I'm just proposing what I think about. If nobody cares about it or
> > is not beneficial, it is ok, and also there is no need to VOTE (This is
> why
> > I'd like to get more opinions on it). But look at Weld, they did the
> > update, https://github.com/weld and full of updating their pom to use
> > jakarta.*
> >
> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
> > geronimo-...specs which depend on javax.*. Today or tomorrow, we will
> > eventually move to jakarta.* namespace. Instead of working with such
> > shading plugin stuff as a workaround, I just offer to take the master to
> > jakarta.* and update all OWB modules' dependency from javax.* to
> jakarta.*
> > official APIS. This is not related to who will maintain the branches. You
> > know that ASF works as a voluntary based approach. You can not push
> anybody
> > to work on anything as in commercial companies.
> >
> > Also, regarding the cost and energy you mention to maintain the branch,
> > via Geronimo specs, you will need to update all of the Geronimo Specs and
> > maintain them. I think this is not rational because now, jakarta.*
> official
> > API license is EPL and Apache friendly. Why do I need to maintain for
> > example Geronimo EL?
> >
> > Regards.
> > Gurkan
> >
> >
> >
> >
> >
> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> >> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cg...@gmail.com>
> a
> >> écrit :
> >>
> >> > Hi David
> >> >
> >> > I’m not sure exactly how it impacts this decision, but IIUC the
> geronimo
> >> > > cdi spec jar is rather essential for some uses as it has OSGI
> support
> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> >> > >
> >> > No, it is not correct. It has OSGI support. GlassFish is an OSGI based
> >> > server.You can grap the code from https://github.com/eclipse-ee4j/cdi
> >> and
> >> > build. It has OSGI enabled MANIFEST.MF file.
> >> >
> >>
> >> Not, it is not correct Gurkan ;).
> >> jakarta does NOT support OSGi properly, it does it the old way and break
> >> several rules. For instance last CDI spec jar contains:
> >>
> >> Manifest-Version: 1.0
> >> Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
> >> r Java)
> >> Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
> >> Bundle-SymbolicName: jakarta.enterprise.cdi-api
> >> Built-By: default
> >> Bnd-LastModified: 1590678420932
> >> Bundle-ManifestVersion: 2
> >> Bundle-DocURL: https://jboss.org
> >> Bundle-Vendor: JBoss by Red Hat, Inc.
> >> Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> >> 3)",jakarta.interceptor;version="[2.0,3)"
> >> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> >> Tool: Bnd-2.4.1.201501161923
> >> Originally-Created-By: Apache Maven Bundle Plugin
> >> Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> >> ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> >> nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> >> sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> >> arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> >> rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> >> ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> >> til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> >> ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> >> ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> >> se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> >> arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> >> ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> >> ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> >> .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> >> karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> >> ise.util",jakarta.enterprise.util;version="3.0"
> >> Bundle-Name: CDI APIs
> >> Bundle-Version: 3.0.0.M4
> >> Build-Jdk-Spec: 1.8
> >> Created-By: Apache Maven Bundle Plugin
> >> Build-Jdk: 1.8.0_202
> >>
> >> Where are the osgi.serviceloader and osgi.contract ?
> >> This is important and used by OSGi-CDI for example (even if it can be
> >> worked around).
> >>
> >> So to conclude on this point not belonging to OWB, we still need our
> fork
> >> and eclipse always answered saying "yes we want OSGi [but we don't
> really
> >> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> >> work on that factually so OSGi is done at minimal cost.
> >>
> >>
> >> >
> >> > Gurkan’s proposal will only add difficulty for developers and probably
> >> > > users.
> >> > >
> >> > What is the difficulty? The change will only affect maintaining the
> >> javax.*
> >> > branch and fully renamed jakarta.* dependencies in master.
> >> >
> >>
> >> Ok Gurkan, let's be concrete, do you - you as you personally - accept
> and
> >> commit yourself to port any commit to one of the two branches to the
> other
> >> for all the time the project is at apache?
> >> if so fine, if not -1 to create us unneeded (+ still unjustified by
> facts)
> >> work.
> >>
> >>
> >> >
> >> > Regards.
> >> > Gurkan
> >> >
> >> > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <david.a.jencks@gmail.com
> >
> >> > wrote:
> >> >
> >> > > I’m not sure exactly how it impacts this decision, but IIUC the
> >> geronimo
> >> > > cdi spec jar is rather essential for some uses as it has OSGI
> support
> >> > > whereas IIUC the eclipse/jakarta one doesn’t.
> >> > >
> >> > > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT
> >> > Gurkan’s
> >> > > proposal will only add difficulty for developers and probably users.
> >> > > Although I haven’t been active here for years I might even vote.
> >> > >
> >> > > thanks
> >> > > David Jencks
> >> > >
> >> > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
> >> cgurkanerdogdu@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > >>
> >> > > >> Tomcat works with branches since years without any issue.
> >> > > >> All projects we tried to use branches we abandoned branches just
> >> after
> >> > > >> having done them.
> >> > > >> It is fine if the old branch is no more used but here we know we
> >> will
> >> > > >> maintain javax branch more than jakarta one for some time so I
> >> think
> >> > we
> >> > > >> should avoid it while it is not justified or one of the 2
> branches
> >> > > (javax)
> >> > > >> is "almost dead".
> >> > > >
> >> > > > Working with branches always happens in all open source projects.
> >> And
> >> > > > there are times when it is logical to create the branch. Jakarta
> EE
> >> 9
> >> > API
> >> > > > migration is the best time to create such a branch. Eventually, we
> >> will
> >> > > > create such a branch in Jakarta EE 10.
> >> > > >
> >> > > > Fact there will be no more javax is useless IMHO, only question we
> >> > should
> >> > > >> care about is "do we have javax users?" and should we work on
> >> javax
> >> > > branch
> >> > > >> enough to care about having 2 duplicate branches. Answer is
> >> obviously
> >> > > yes
> >> > > >> and more than jakarta users today, therefore I think for some
> >> months
> >> > > (maybe
> >> > > >> a few years) we should stick to javax as our primary branch and
> >> ensure
> >> > > the
> >> > > >> alignments and bugfixes can trivially - == without any action
> from
> >> dev
> >> > > - be
> >> > > >> ported. It is what we have today.
> >> > > >>
> >> > > > What could be more natural than maintaining branches (with
> >> backporting
> >> > > from
> >> > > > master only if necessary). With Jakarta EE 10, we will eventually
> >> > create
> >> > > > the branch for supporting the EE 8. Also, for the release
> >> versioning,
> >> > it
> >> > > is
> >> > > > nice to have a 3.x release. The community will notice that 3.x is
> >> the
> >> > > > starting point of Jakarta EE support. Will you release 2.x with
> the
> >> > > > intention of supporting Jakarta EE 9? I am personally not positive
> >> on
> >> > > this.
> >> > > > I think, 3.x release will also get more interest even if the
> >> > > functionality
> >> > > > and API stay the same. We can prepare the press release for it.
> >> > > >
> >> > > > Note we shouldn't depend on jakarta/javax api anyway (neither as
> >> > groupId
> >> > > >> nor as transitive dep so this change must stay a noop for
> >> consumers).
> >> > > >>
> >> > > > What is the problem of depending on the official Jakarta EE CDI
> >> API? It
> >> > > is
> >> > > > an Apache friendly license. Instead of maintaining the Geronimo
> CDI
> >> API
> >> > > > internally, it is more logical to use Jakarta EE official CDI API
> >> and
> >> > > > maintain this API with EE4J community.
> >> > > >
> >> > > > would also appreciate if you do a vote if you can point out the
> >> > breaking
> >> > > >> changes - except the package renaming - justifying to fork
> ourself
> >> and
> >> > > what
> >> > > >> does not work with current solution, can ease the decision/vote.
> >> > > >> Today using jakarta/EE9 API is quite easy (
> >> > > >>
> >> > >
> >> >
> >>
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> >> > > >> ).
> >> > > >> We should absolutely enhance the pom experience though but it is
> >> > > trivial to
> >> > > >> do at maven level - I was envisionning to do it in shade plugin
> to
> >> be
> >> > > more
> >> > > >> precise.
> >> > > >>
> >> > > > I know that there will be no functional change. But, I am also
> >> against
> >> > > > shading for jakarta.*. If there will be no change on Jakarta EE
> 10,
> >> > will
> >> > > we
> >> > > > continue to shade? What happens when there will be a change in
> EJB,
> >> > JMS
> >> > > > etc specifications but no change in CDI in Jakarta EE 10? Also,
> >> VOTING
> >> > is
> >> > > > the natural thing to do for the community decision. If the
> community
> >> > > would
> >> > > > like to keep it as it is via shading, it is fine.
> >> > > >
> >> > > >>
> >> > > >> To try to rephrase/clarify my questionning today: you ask for
> >> jakarta
> >> > > >> support, we already have it in a dev and project efficient way so
> >> why
> >> > > >> should we change since I don't hink there is anything new - once
> >> again
> >> > > if
> >> > > >> API starts to fully break discussion is different but github
> doesnt
> >> > > reflect
> >> > > >> that?
> >> > > >>
> >> > > > This is not just for Jakarta EE 9 support. As we know, there will
> >> be no
> >> > > API
> >> > > > (functional) change, only package renaming. But, I want to
> emphasize
> >> > that
> >> > > > with such turning points, it is so logical to integrate official
> >> > Jakarta
> >> > > > CDI API into our master (removing the geronimo-cdi), and release
> our
> >> > new
> >> > > > 3.x version and let the public know that OWB supports official CDI
> >> API
> >> > > > beginning with 3.x release. Yeah, shading is an option for package
> >> > > renaming
> >> > > > but think long term. Also, I am really against the shading. It
> >> really
> >> > > > disturbs the users which depend on OWB implementation. For
> example,
> >> > > > currently Glassfish supports Weld integration but one can also
> >> > implement
> >> > > > OWB to replace Weld in Glassfish. Therefore, instead of using the
> >> > shaded
> >> > > > version, it is really important to have the full Jakarta EE CDI
> API
> >> in
> >> > > our
> >> > > > poms. You will still have javax.* dependency in ur POMs even if
> >> doing a
> >> > > > shade. This is not good idea to still maintain javax.* in our POM
> >> > files.
> >> > > >
> >> > > > What are other opinions before formal voting?
> >> > > > Regards.
> >> > > > Gurkan
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> >> > rmannibucau@gmail.com
> >> > > >
> >> > > > wrote:
> >> > > >
> >> > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> >> cgurkanerdogdu@gmail.com
> >> > >
> >> > > a
> >> > > >> écrit :
> >> > > >>
> >> > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on
> >> > master.
> >> > > >>>
> >> > > >>
> >> > > >> Tomcat works with branches since years without any issue.
> >> > > >> All projects we tried to use branches we abandoned branches just
> >> after
> >> > > >> having done them.
> >> > > >> It is fine if the old branch is no more used but here we know we
> >> will
> >> > > >> maintain javax branch more than jakarta one for some time so I
> >> think
> >> > we
> >> > > >> should avoid it while it is not justified or one of the 2
> branches
> >> > > (javax)
> >> > > >> is "almost dead".
> >> > > >>
> >> > > >>
> >> > > >>> sorry but not understand the resistance on this? will you always
> >> > shade
> >> > > ?
> >> > > >>>
> >> > > >>
> >> > > >> As mentionned, until API needs changes we can't easily handle -
> >> today
> >> > > there
> >> > > >> is no change.
> >> > > >>
> >> > > >>
> >> > > >>> creating the new master and maintain the 2.x branch, is the best
> >> > > logical
> >> > > >>> way. there will be no javax.* any more. Tomcat maintains 3
> >> branches
> >> > > and
> >> > > >> 1
> >> > > >>> master. only maintains 1 branch and 1 master is totally fine.
> >> > > >>>
> >> > > >>
> >> > > >> Fact there will be no more javax is useless IMHO, only question
> we
> >> > > should
> >> > > >> care about is "do we have javax users?" and should we work on
> >> javax
> >> > > branch
> >> > > >> enough to care about having 2 duplicate branches. Answer is
> >> obviously
> >> > > yes
> >> > > >> and more than jakarta users today, therefore I think for some
> >> months
> >> > > (maybe
> >> > > >> a few years) we should stick to javax as our primary branch and
> >> ensure
> >> > > the
> >> > > >> alignments and bugfixes can trivially - == without any action
> from
> >> dev
> >> > > - be
> >> > > >> ported. It is what we have today.
> >> > > >>
> >> > > >>
> >> > > >>>
> >> > > >>> I will propose a vote shortly to decide on to create a master
> with
> >> > 3.x
> >> > > >> with
> >> > > >>> fully support of jakarta with a normal pom dependency with
> jakarta
> >> > api.
> >> > > >>>
> >> > > >>
> >> > > >> Note we shouldn't depend on jakarta/javax api anyway (neither as
> >> > groupId
> >> > > >> nor as transitive dep so this change must stay a noop for
> >> consumers).
> >> > > >> I would also appreciate if you do a vote if you can point out the
> >> > > breaking
> >> > > >> changes - except the package renaming - justifying to fork
> ourself
> >> and
> >> > > what
> >> > > >> does not work with current solution, can ease the decision/vote.
> >> > > >> Today using jakarta/EE9 API is quite easy (
> >> > > >>
> >> > >
> >> >
> >>
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> >> > > >> ).
> >> > > >> We should absolutely enhance the pom experience though but it is
> >> > > trivial to
> >> > > >> do at maven level - I was envisionning to do it in shade plugin
> to
> >> be
> >> > > more
> >> > > >> precise.
> >> > > >>
> >> > > >> To try to rephrase/clarify my questionning today: you ask for
> >> jakarta
> >> > > >> support, we already have it in a dev and project efficient way so
> >> why
> >> > > >> should we change since I don't hink there is anything new - once
> >> again
> >> > > if
> >> > > >> API starts to fully break discussion is different but github
> doesnt
> >> > > reflect
> >> > > >> that?
> >> > > >>
> >> > > >>
> >> > > >>>
> >> > > >>> Regs
> >> > > >>> Gurkan
> >> > > >>>
> >> > > >>>
> >> > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
> >> rmannibucau@gmail.com
> >> > >
> >> > > >>> wrote:
> >> > > >>>
> >> > > >>>> Today we don't need, tomorrow I don't know but while API does
> not
> >> > > >> change
> >> > > >>>> (except the package) we shouldn't fork ourself IMHO (cause it
> is
> >> > what
> >> > > >> you
> >> > > >>>> propose as a consequence).
> >> > > >>>> If it becomes necessary let's do it but my vote is to stay lazy
> >> on
> >> > > >> that.
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> side note for G API discussion belongs to dev@G but it is less
> >> an
> >> > > >> issue
> >> > > >>> to
> >> > > >>>> fork from now since we rarely update the API, the side note
> here
> >> is
> >> > > >> that
> >> > > >>>> CDI SE is already fully runnable on ASF stack with jakarta
> >> package
> >> > > >> since
> >> > > >>>> some weeks or months, we did all the needed releases.
> >> > > >>>>
> >> > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> >> > > >>>> andraschko.thomas@gmail.com>
> >> > > >>>> a écrit :
> >> > > >>>>
> >> > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our
> build.
> >> > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
> >> > > >>>>>
> >> > > >>>>> I'm actually also a supporter of doing a hard cut but it's not
> >> > > >> required
> >> > > >>>> and
> >> > > >>>>> we can do it for EE 10.
> >> > > >>>>>
> >> > > >>>>> <
> >> > > >>>>>
> >> > > >>>>
> >> > > >>>
> >> > > >>
> >> > >
> >> >
> >>
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >> > > >>>>>>
> >> > > >>>>> Virenfrei.
> >> > > >>>>> www.avast.com
> >> > > >>>>> <
> >> > > >>>>>
> >> > > >>>>
> >> > > >>>
> >> > > >>
> >> > >
> >> >
> >>
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >> > > >>>>>>
> >> > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >> > > >>>>>
> >> > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> >> > > >>>>> cgurkanerdogdu@gmail.com>:
> >> > > >>>>>
> >> > > >>>>>> We need to maintain two branches
> >> > > >>>>>>
> >> > > >>>>>> EE 8 for javax.* package 2.x branch
> >> > > >>>>>> EE 9 for jakarta.* package 3.x master
> >> > > >>>>>>
> >> > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> >> > > >> rmannibucau@gmail.com
> >> > > >>>>
> >> > > >>>>>> wrote:
> >> > > >>>>>>
> >> > > >>>>>>> Hi,
> >> > > >>>>>>>
> >> > > >>>>>>> I'll probably restate my position on that: if EE 9 brings
> >> > > >>>>> significatively
> >> > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but I
> >> can
> >> > > >>> have
> >> > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can stay
> >> as
> >> > > >> we
> >> > > >>>> are
> >> > > >>>>> I
> >> > > >>>>>>> think avoiding to maintain two branches we can't merge
> >> regularly.
> >> > > >>>>>>>
> >> > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> >> > > >>>> cgurkanerdogdu@gmail.com>
> >> > > >>>>> a
> >> > > >>>>>>> écrit :
> >> > > >>>>>>>
> >> > > >>>>>>>> Hi
> >> > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
> >> > > >> support
> >> > > >>>>>> upcoming
> >> > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> >> > > >>>>>>>>
> >> > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of using
> >> the
> >> > > >>>>> Apache
> >> > > >>>>>>>> based api.
> >> > > >>>>>>>> Regards
> >> > > >>>>>>>> Gurkan
> >> > > >>>>>>>>
> >> > > >>>>>>>> --
> >> > > >>>>>>>> Gurkan Erdogdu
> >> > > >>>>>>>> http://gurkanerdogdu.blogspot.com
> >> > > >>>>>>>>
> >> > > >>>>>>>
> >> > > >>>>>> --
> >> > > >>>>>> Gurkan Erdogdu
> >> > > >>>>>> http://gurkanerdogdu.blogspot.com
> >> > > >>>>>>
> >> > > >>>>>
> >> > > >>>>
> >> > > >>> --
> >> > > >>> Gurkan Erdogdu
> >> > > >>> http://gurkanerdogdu.blogspot.com
> >> > > >>>
> >> > > >>
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Gurkan Erdogdu
> >> > > > http://gurkanerdogdu.blogspot.com
> >> > >
> >> > >
> >> >
> >> > --
> >> > Gurkan Erdogdu
> >> > http://gurkanerdogdu.blogspot.com
> >> >
> >>
> >
> >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
Re: Jakarta EE 9 Support
Posted by Gurkan Erdogdu <cg...@gmail.com>.
> Not, it is not correct Gurkan ;).
> jakarta does NOT support OSGi properly, it does it the old way and break
> several rules. For instance last CDI spec jar contains:
As I said in my previous email, I am not an OSGI expert. But, what I can do
is that I can ping the CDI team in EE4J to add features to support OWB-OSGI
or other ASF projects? Could you explain in detail?
Regards.
Gurkan
On Sun, Jun 7, 2020 at 9:39 PM Gurkan Erdogdu <cg...@gmail.com>
wrote:
> So to conclude on this point not belonging to OWB, we still need our fork
>> and eclipse always answered saying "yes we want OSGi [but we don't really
>> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
>> work on that factually so OSGi is done at minimal cost.
>
> OK thanks for the clarification. I am not an OSGI expert.
>
> Ok Gurkan, let's be concrete, do you - you as you personally - accept and
>> commit yourself to port any commit to one of the two branches to the other
>> for all the time the project is at apache?
>> if so fine, if not -1 to create us unneeded (+ still unjustified by facts)
>> work.
>
> :=)
> Hey, I'm just proposing what I think about. If nobody cares about it or
> is not beneficial, it is ok, and also there is no need to VOTE (This is why
> I'd like to get more opinions on it). But look at Weld, they did the
> update, https://github.com/weld and full of updating their pom to use
> jakarta.*
>
> Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
> geronimo-...specs which depend on javax.*. Today or tomorrow, we will
> eventually move to jakarta.* namespace. Instead of working with such
> shading plugin stuff as a workaround, I just offer to take the master to
> jakarta.* and update all OWB modules' dependency from javax.* to jakarta.*
> official APIS. This is not related to who will maintain the branches. You
> know that ASF works as a voluntary based approach. You can not push anybody
> to work on anything as in commercial companies.
>
> Also, regarding the cost and energy you mention to maintain the branch,
> via Geronimo specs, you will need to update all of the Geronimo Specs and
> maintain them. I think this is not rational because now, jakarta.* official
> API license is EPL and Apache friendly. Why do I need to maintain for
> example Geronimo EL?
>
> Regards.
> Gurkan
>
>
>
>
>
> On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cg...@gmail.com> a
>> écrit :
>>
>> > Hi David
>> >
>> > I’m not sure exactly how it impacts this decision, but IIUC the geronimo
>> > > cdi spec jar is rather essential for some uses as it has OSGI support
>> > > whereas IIUC the eclipse/jakarta one doesn’t.
>> > >
>> > No, it is not correct. It has OSGI support. GlassFish is an OSGI based
>> > server.You can grap the code from https://github.com/eclipse-ee4j/cdi
>> and
>> > build. It has OSGI enabled MANIFEST.MF file.
>> >
>>
>> Not, it is not correct Gurkan ;).
>> jakarta does NOT support OSGi properly, it does it the old way and break
>> several rules. For instance last CDI spec jar contains:
>>
>> Manifest-Version: 1.0
>> Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
>> r Java)
>> Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
>> Bundle-SymbolicName: jakarta.enterprise.cdi-api
>> Built-By: default
>> Bnd-LastModified: 1590678420932
>> Bundle-ManifestVersion: 2
>> Bundle-DocURL: https://jboss.org
>> Bundle-Vendor: JBoss by Red Hat, Inc.
>> Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
>> 3)",jakarta.interceptor;version="[2.0,3)"
>> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
>> Tool: Bnd-2.4.1.201501161923
>> Originally-Created-By: Apache Maven Bundle Plugin
>> Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
>> ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
>> nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
>> sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
>> arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
>> rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
>> ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
>> til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
>> ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
>> ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
>> se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
>> arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
>> ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
>> ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
>> .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
>> karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
>> ise.util",jakarta.enterprise.util;version="3.0"
>> Bundle-Name: CDI APIs
>> Bundle-Version: 3.0.0.M4
>> Build-Jdk-Spec: 1.8
>> Created-By: Apache Maven Bundle Plugin
>> Build-Jdk: 1.8.0_202
>>
>> Where are the osgi.serviceloader and osgi.contract ?
>> This is important and used by OSGi-CDI for example (even if it can be
>> worked around).
>>
>> So to conclude on this point not belonging to OWB, we still need our fork
>> and eclipse always answered saying "yes we want OSGi [but we don't really
>> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
>> work on that factually so OSGi is done at minimal cost.
>>
>>
>> >
>> > Gurkan’s proposal will only add difficulty for developers and probably
>> > > users.
>> > >
>> > What is the difficulty? The change will only affect maintaining the
>> javax.*
>> > branch and fully renamed jakarta.* dependencies in master.
>> >
>>
>> Ok Gurkan, let's be concrete, do you - you as you personally - accept and
>> commit yourself to port any commit to one of the two branches to the other
>> for all the time the project is at apache?
>> if so fine, if not -1 to create us unneeded (+ still unjustified by facts)
>> work.
>>
>>
>> >
>> > Regards.
>> > Gurkan
>> >
>> > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <da...@gmail.com>
>> > wrote:
>> >
>> > > I’m not sure exactly how it impacts this decision, but IIUC the
>> geronimo
>> > > cdi spec jar is rather essential for some uses as it has OSGI support
>> > > whereas IIUC the eclipse/jakarta one doesn’t.
>> > >
>> > > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT
>> > Gurkan’s
>> > > proposal will only add difficulty for developers and probably users.
>> > > Although I haven’t been active here for years I might even vote.
>> > >
>> > > thanks
>> > > David Jencks
>> > >
>> > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
>> cgurkanerdogdu@gmail.com>
>> > > wrote:
>> > > >
>> > > >>
>> > > >> Tomcat works with branches since years without any issue.
>> > > >> All projects we tried to use branches we abandoned branches just
>> after
>> > > >> having done them.
>> > > >> It is fine if the old branch is no more used but here we know we
>> will
>> > > >> maintain javax branch more than jakarta one for some time so I
>> think
>> > we
>> > > >> should avoid it while it is not justified or one of the 2 branches
>> > > (javax)
>> > > >> is "almost dead".
>> > > >
>> > > > Working with branches always happens in all open source projects.
>> And
>> > > > there are times when it is logical to create the branch. Jakarta EE
>> 9
>> > API
>> > > > migration is the best time to create such a branch. Eventually, we
>> will
>> > > > create such a branch in Jakarta EE 10.
>> > > >
>> > > > Fact there will be no more javax is useless IMHO, only question we
>> > should
>> > > >> care about is "do we have javax users?" and should we work on
>> javax
>> > > branch
>> > > >> enough to care about having 2 duplicate branches. Answer is
>> obviously
>> > > yes
>> > > >> and more than jakarta users today, therefore I think for some
>> months
>> > > (maybe
>> > > >> a few years) we should stick to javax as our primary branch and
>> ensure
>> > > the
>> > > >> alignments and bugfixes can trivially - == without any action from
>> dev
>> > > - be
>> > > >> ported. It is what we have today.
>> > > >>
>> > > > What could be more natural than maintaining branches (with
>> backporting
>> > > from
>> > > > master only if necessary). With Jakarta EE 10, we will eventually
>> > create
>> > > > the branch for supporting the EE 8. Also, for the release
>> versioning,
>> > it
>> > > is
>> > > > nice to have a 3.x release. The community will notice that 3.x is
>> the
>> > > > starting point of Jakarta EE support. Will you release 2.x with the
>> > > > intention of supporting Jakarta EE 9? I am personally not positive
>> on
>> > > this.
>> > > > I think, 3.x release will also get more interest even if the
>> > > functionality
>> > > > and API stay the same. We can prepare the press release for it.
>> > > >
>> > > > Note we shouldn't depend on jakarta/javax api anyway (neither as
>> > groupId
>> > > >> nor as transitive dep so this change must stay a noop for
>> consumers).
>> > > >>
>> > > > What is the problem of depending on the official Jakarta EE CDI
>> API? It
>> > > is
>> > > > an Apache friendly license. Instead of maintaining the Geronimo CDI
>> API
>> > > > internally, it is more logical to use Jakarta EE official CDI API
>> and
>> > > > maintain this API with EE4J community.
>> > > >
>> > > > would also appreciate if you do a vote if you can point out the
>> > breaking
>> > > >> changes - except the package renaming - justifying to fork ourself
>> and
>> > > what
>> > > >> does not work with current solution, can ease the decision/vote.
>> > > >> Today using jakarta/EE9 API is quite easy (
>> > > >>
>> > >
>> >
>> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
>> > > >> ).
>> > > >> We should absolutely enhance the pom experience though but it is
>> > > trivial to
>> > > >> do at maven level - I was envisionning to do it in shade plugin to
>> be
>> > > more
>> > > >> precise.
>> > > >>
>> > > > I know that there will be no functional change. But, I am also
>> against
>> > > > shading for jakarta.*. If there will be no change on Jakarta EE 10,
>> > will
>> > > we
>> > > > continue to shade? What happens when there will be a change in EJB,
>> > JMS
>> > > > etc specifications but no change in CDI in Jakarta EE 10? Also,
>> VOTING
>> > is
>> > > > the natural thing to do for the community decision. If the community
>> > > would
>> > > > like to keep it as it is via shading, it is fine.
>> > > >
>> > > >>
>> > > >> To try to rephrase/clarify my questionning today: you ask for
>> jakarta
>> > > >> support, we already have it in a dev and project efficient way so
>> why
>> > > >> should we change since I don't hink there is anything new - once
>> again
>> > > if
>> > > >> API starts to fully break discussion is different but github doesnt
>> > > reflect
>> > > >> that?
>> > > >>
>> > > > This is not just for Jakarta EE 9 support. As we know, there will
>> be no
>> > > API
>> > > > (functional) change, only package renaming. But, I want to emphasize
>> > that
>> > > > with such turning points, it is so logical to integrate official
>> > Jakarta
>> > > > CDI API into our master (removing the geronimo-cdi), and release our
>> > new
>> > > > 3.x version and let the public know that OWB supports official CDI
>> API
>> > > > beginning with 3.x release. Yeah, shading is an option for package
>> > > renaming
>> > > > but think long term. Also, I am really against the shading. It
>> really
>> > > > disturbs the users which depend on OWB implementation. For example,
>> > > > currently Glassfish supports Weld integration but one can also
>> > implement
>> > > > OWB to replace Weld in Glassfish. Therefore, instead of using the
>> > shaded
>> > > > version, it is really important to have the full Jakarta EE CDI API
>> in
>> > > our
>> > > > poms. You will still have javax.* dependency in ur POMs even if
>> doing a
>> > > > shade. This is not good idea to still maintain javax.* in our POM
>> > files.
>> > > >
>> > > > What are other opinions before formal voting?
>> > > > Regards.
>> > > > Gurkan
>> > > >
>> > > >
>> > > >
>> > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
>> > rmannibucau@gmail.com
>> > > >
>> > > > wrote:
>> > > >
>> > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
>> cgurkanerdogdu@gmail.com
>> > >
>> > > a
>> > > >> écrit :
>> > > >>
>> > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on
>> > master.
>> > > >>>
>> > > >>
>> > > >> Tomcat works with branches since years without any issue.
>> > > >> All projects we tried to use branches we abandoned branches just
>> after
>> > > >> having done them.
>> > > >> It is fine if the old branch is no more used but here we know we
>> will
>> > > >> maintain javax branch more than jakarta one for some time so I
>> think
>> > we
>> > > >> should avoid it while it is not justified or one of the 2 branches
>> > > (javax)
>> > > >> is "almost dead".
>> > > >>
>> > > >>
>> > > >>> sorry but not understand the resistance on this? will you always
>> > shade
>> > > ?
>> > > >>>
>> > > >>
>> > > >> As mentionned, until API needs changes we can't easily handle -
>> today
>> > > there
>> > > >> is no change.
>> > > >>
>> > > >>
>> > > >>> creating the new master and maintain the 2.x branch, is the best
>> > > logical
>> > > >>> way. there will be no javax.* any more. Tomcat maintains 3
>> branches
>> > > and
>> > > >> 1
>> > > >>> master. only maintains 1 branch and 1 master is totally fine.
>> > > >>>
>> > > >>
>> > > >> Fact there will be no more javax is useless IMHO, only question we
>> > > should
>> > > >> care about is "do we have javax users?" and should we work on
>> javax
>> > > branch
>> > > >> enough to care about having 2 duplicate branches. Answer is
>> obviously
>> > > yes
>> > > >> and more than jakarta users today, therefore I think for some
>> months
>> > > (maybe
>> > > >> a few years) we should stick to javax as our primary branch and
>> ensure
>> > > the
>> > > >> alignments and bugfixes can trivially - == without any action from
>> dev
>> > > - be
>> > > >> ported. It is what we have today.
>> > > >>
>> > > >>
>> > > >>>
>> > > >>> I will propose a vote shortly to decide on to create a master with
>> > 3.x
>> > > >> with
>> > > >>> fully support of jakarta with a normal pom dependency with jakarta
>> > api.
>> > > >>>
>> > > >>
>> > > >> Note we shouldn't depend on jakarta/javax api anyway (neither as
>> > groupId
>> > > >> nor as transitive dep so this change must stay a noop for
>> consumers).
>> > > >> I would also appreciate if you do a vote if you can point out the
>> > > breaking
>> > > >> changes - except the package renaming - justifying to fork ourself
>> and
>> > > what
>> > > >> does not work with current solution, can ease the decision/vote.
>> > > >> Today using jakarta/EE9 API is quite easy (
>> > > >>
>> > >
>> >
>> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
>> > > >> ).
>> > > >> We should absolutely enhance the pom experience though but it is
>> > > trivial to
>> > > >> do at maven level - I was envisionning to do it in shade plugin to
>> be
>> > > more
>> > > >> precise.
>> > > >>
>> > > >> To try to rephrase/clarify my questionning today: you ask for
>> jakarta
>> > > >> support, we already have it in a dev and project efficient way so
>> why
>> > > >> should we change since I don't hink there is anything new - once
>> again
>> > > if
>> > > >> API starts to fully break discussion is different but github doesnt
>> > > reflect
>> > > >> that?
>> > > >>
>> > > >>
>> > > >>>
>> > > >>> Regs
>> > > >>> Gurkan
>> > > >>>
>> > > >>>
>> > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
>> rmannibucau@gmail.com
>> > >
>> > > >>> wrote:
>> > > >>>
>> > > >>>> Today we don't need, tomorrow I don't know but while API does not
>> > > >> change
>> > > >>>> (except the package) we shouldn't fork ourself IMHO (cause it is
>> > what
>> > > >> you
>> > > >>>> propose as a consequence).
>> > > >>>> If it becomes necessary let's do it but my vote is to stay lazy
>> on
>> > > >> that.
>> > > >>>>
>> > > >>>>
>> > > >>>> side note for G API discussion belongs to dev@G but it is less
>> an
>> > > >> issue
>> > > >>> to
>> > > >>>> fork from now since we rarely update the API, the side note here
>> is
>> > > >> that
>> > > >>>> CDI SE is already fully runnable on ASF stack with jakarta
>> package
>> > > >> since
>> > > >>>> some weeks or months, we did all the needed releases.
>> > > >>>>
>> > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
>> > > >>>> andraschko.thomas@gmail.com>
>> > > >>>> a écrit :
>> > > >>>>
>> > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our build.
>> > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
>> > > >>>>>
>> > > >>>>> I'm actually also a supporter of doing a hard cut but it's not
>> > > >> required
>> > > >>>> and
>> > > >>>>> we can do it for EE 10.
>> > > >>>>>
>> > > >>>>> <
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > >>
>> > >
>> >
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>> > > >>>>>>
>> > > >>>>> Virenfrei.
>> > > >>>>> www.avast.com
>> > > >>>>> <
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > >>
>> > >
>> >
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>> > > >>>>>>
>> > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> > > >>>>>
>> > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
>> > > >>>>> cgurkanerdogdu@gmail.com>:
>> > > >>>>>
>> > > >>>>>> We need to maintain two branches
>> > > >>>>>>
>> > > >>>>>> EE 8 for javax.* package 2.x branch
>> > > >>>>>> EE 9 for jakarta.* package 3.x master
>> > > >>>>>>
>> > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
>> > > >> rmannibucau@gmail.com
>> > > >>>>
>> > > >>>>>> wrote:
>> > > >>>>>>
>> > > >>>>>>> Hi,
>> > > >>>>>>>
>> > > >>>>>>> I'll probably restate my position on that: if EE 9 brings
>> > > >>>>> significatively
>> > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but I
>> can
>> > > >>> have
>> > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can stay
>> as
>> > > >> we
>> > > >>>> are
>> > > >>>>> I
>> > > >>>>>>> think avoiding to maintain two branches we can't merge
>> regularly.
>> > > >>>>>>>
>> > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
>> > > >>>> cgurkanerdogdu@gmail.com>
>> > > >>>>> a
>> > > >>>>>>> écrit :
>> > > >>>>>>>
>> > > >>>>>>>> Hi
>> > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
>> > > >> support
>> > > >>>>>> upcoming
>> > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
>> > > >>>>>>>>
>> > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of using
>> the
>> > > >>>>> Apache
>> > > >>>>>>>> based api.
>> > > >>>>>>>> Regards
>> > > >>>>>>>> Gurkan
>> > > >>>>>>>>
>> > > >>>>>>>> --
>> > > >>>>>>>> Gurkan Erdogdu
>> > > >>>>>>>> http://gurkanerdogdu.blogspot.com
>> > > >>>>>>>>
>> > > >>>>>>>
>> > > >>>>>> --
>> > > >>>>>> Gurkan Erdogdu
>> > > >>>>>> http://gurkanerdogdu.blogspot.com
>> > > >>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>> --
>> > > >>> Gurkan Erdogdu
>> > > >>> http://gurkanerdogdu.blogspot.com
>> > > >>>
>> > > >>
>> > > >
>> > > >
>> > > > --
>> > > > Gurkan Erdogdu
>> > > > http://gurkanerdogdu.blogspot.com
>> > >
>> > >
>> >
>> > --
>> > Gurkan Erdogdu
>> > http://gurkanerdogdu.blogspot.com
>> >
>>
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
As expected:
public static final java.lang.String JAVAX_ENTERPRISE_PACKAGE;
descriptor: Ljava/lang/String;
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
ConstantValue: String jakarta.enterprise.
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 dim. 7 juin 2020 à 23:24, Gurkan Erdogdu <cg...@gmail.com> a
écrit :
> There are some string literals in source code using javax.*. for example,
> in BeansDeployer, public static final String JAVAX_ENTERPRISE_PACKAGE =
> "javax.enterprise.";.
> How is the shading plugin fixes these?
> Regards.
> Gurkan
>
> On Sun, Jun 7, 2020 at 10:55 PM Gurkan Erdogdu <cg...@gmail.com>
> wrote:
>
> > They also impled the bda differently than us making it only usable for
> >> single bda apps and created arc@quarkus which violates that, so not
> sure
> >> we
> >> should copy what others do. I tend to prefer to add thinking on top of
> >> that
> >> in the context of our project which is diff than the RI (by design and
> by
> >> workforce).
> >>
> > This is not copying but not going into discussion more.
> >
> >
> >> I can agree that in one year we reverse the pattern, shade becoming
> javax.
> >> But since we cant enforce anyone to do the sync between branches and due
> >> to
> >> past years contributions stats, we must not go that way IMHO, it would
> >> either make us expose 2 bad branches or kill our resources for no user
> >> gains. Indeed that is my opinion but from the stats i have today it is
> my
> >> conclusion.
> >
> > You have concerns about the community, understanding.
> >
> > Please discuss it on G, it does not impact OWB - and btw this is not what
> >> had been said ;).
> >>
> > Thanks for the pointer
> >
> > Regards.
> > Gurkan
> >
> > On Sun, Jun 7, 2020 at 9:50 PM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> >> Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu <cg...@gmail.com>
> a
> >> écrit :
> >>
> >> > >
> >> > > So to conclude on this point not belonging to OWB, we still need our
> >> fork
> >> > > and eclipse always answered saying "yes we want OSGi [but we don't
> >> really
> >> > > know]" - and I know eclipse+EE has a lot of OSGi experts but they
> >> don't
> >> > > work on that factually so OSGi is done at minimal cost.
> >> >
> >> > OK thanks for the clarification. I am not an OSGI expert.
> >> >
> >> > Ok Gurkan, let's be concrete, do you - you as you personally - accept
> >> and
> >> > > commit yourself to port any commit to one of the two branches to the
> >> > other
> >> > > for all the time the project is at apache?
> >> > > if so fine, if not -1 to create us unneeded (+ still unjustified by
> >> > facts)
> >> > > work.
> >> >
> >> > :=)
> >> > Hey, I'm just proposing what I think about. If nobody cares about it
> >> or is
> >> > not beneficial, it is ok, and also there is no need to VOTE (This is
> why
> >> > I'd like to get more opinions on it).
> >>
> >>
> >> It is fine, just wanted to emphasis the consequence and what it means
> for
> >> the project.
> >>
> >> But look at Weld, they did the
> >> > update, https://github.com/weld and full of updating their pom to use
> >> > jakarta.*
> >> >
> >>
> >> They also impled the bda differently than us making it only usable for
> >> single bda apps and created arc@quarkus which violates that, so not
> sure
> >> we
> >> should copy what others do. I tend to prefer to add thinking on top of
> >> that
> >> in the context of our project which is diff than the RI (by design and
> by
> >> workforce).
> >>
> >>
> >>
> >> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
> >> > geronimo-...specs which depend on javax.*. Today or tomorrow, we will
> >> > eventually move to jakarta.* namespace. Instead of working with such
> >> > shading plugin stuff as a workaround, I just offer to take the master
> to
> >> > jakarta.* and update all OWB modules' dependency from javax.* to
> >> jakarta.*
> >> > official APIS. This is not related to who will maintain the branches.
> >> You
> >> > know that ASF works as a voluntary based approach. You can not push
> >> anybody
> >> > to work on anything as in commercial companies.
> >> >
> >>
> >> I can agree that in one year we reverse the pattern, shade becoming
> javax.
> >> But since we cant enforce anyone to do the sync between branches and due
> >> to
> >> past years contributions stats, we must not go that way IMHO, it would
> >> either make us expose 2 bad branches or kill our resources for no user
> >> gains. Indeed that is my opinion but from the stats i have today it is
> my
> >> conclusion.
> >>
> >>
> >> > Also, regarding the cost and energy you mention to maintain the
> branch,
> >> via
> >> > Geronimo specs, you will need to update all of the Geronimo Specs and
> >> > maintain them. I think this is not rational because now, jakarta.*
> >> official
> >> > API license is EPL and Apache friendly. Why do I need to maintain for
> >> > example Geronimo EL?
> >> >
> >>
> >> Please discuss it on G, it does not impact OWB - and btw this is not
> what
> >> had been said ;).
> >>
> >>
> >>
> >> > Regards.
> >> > Gurkan
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <
> >> rmannibucau@gmail.com>
> >> > wrote:
> >> >
> >> > > Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <
> cgurkanerdogdu@gmail.com>
> >> a
> >> > > écrit :
> >> > >
> >> > > > Hi David
> >> > > >
> >> > > > I’m not sure exactly how it impacts this decision, but IIUC the
> >> > geronimo
> >> > > > > cdi spec jar is rather essential for some uses as it has OSGI
> >> support
> >> > > > > whereas IIUC the eclipse/jakarta one doesn’t.
> >> > > > >
> >> > > > No, it is not correct. It has OSGI support. GlassFish is an OSGI
> >> based
> >> > > > server.You can grap the code from
> >> https://github.com/eclipse-ee4j/cdi
> >> > > and
> >> > > > build. It has OSGI enabled MANIFEST.MF file.
> >> > > >
> >> > >
> >> > > Not, it is not correct Gurkan ;).
> >> > > jakarta does NOT support OSGi properly, it does it the old way and
> >> break
> >> > > several rules. For instance last CDI spec jar contains:
> >> > >
> >> > > Manifest-Version: 1.0
> >> > > Bundle-Description: APIs for CDI (Contexts and Dependency Injection
> fo
> >> > > r Java)
> >> > > Bundle-License:
> https://repository.jboss.org/licenses/apache-2.0.txt
> >> > > Bundle-SymbolicName: jakarta.enterprise.cdi-api
> >> > > Built-By: default
> >> > > Bnd-LastModified: 1590678420932
> >> > > Bundle-ManifestVersion: 2
> >> > > Bundle-DocURL: https://jboss.org
> >> > > Bundle-Vendor: JBoss by Red Hat, Inc.
> >> > > Import-Package:
> jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> >> > > 3)",jakarta.interceptor;version="[2.0,3)"
> >> > > Require-Capability: osgi.ee;filter:="(&(osgi.ee
> >> =JavaSE)(version=1.8))"
> >> > > Tool: Bnd-2.4.1.201501161923
> >> > > Originally-Created-By: Apache Maven Bundle Plugin
> >> > > Export-Package:
> jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> >> > >
> ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> >> > >
> nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> >> > >
> sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> >> > >
> arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> >> > >
> rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> >> > >
> ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> >> > >
> til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> >> > >
> ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> >> > > ct.se
> >> ;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> >> > >
> se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> >> > >
> arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> >> > >
> ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> >> > >
> ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> >> > >
> .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> >> > >
> karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> >> > > ise.util",jakarta.enterprise.util;version="3.0"
> >> > > Bundle-Name: CDI APIs
> >> > > Bundle-Version: 3.0.0.M4
> >> > > Build-Jdk-Spec: 1.8
> >> > > Created-By: Apache Maven Bundle Plugin
> >> > > Build-Jdk: 1.8.0_202
> >> > >
> >> > > Where are the osgi.serviceloader and osgi.contract ?
> >> > > This is important and used by OSGi-CDI for example (even if it can
> be
> >> > > worked around).
> >> > >
> >> > > So to conclude on this point not belonging to OWB, we still need our
> >> fork
> >> > > and eclipse always answered saying "yes we want OSGi [but we don't
> >> really
> >> > > know]" - and I know eclipse+EE has a lot of OSGi experts but they
> >> don't
> >> > > work on that factually so OSGi is done at minimal cost.
> >> > >
> >> > >
> >> > > >
> >> > > > Gurkan’s proposal will only add difficulty for developers and
> >> probably
> >> > > > > users.
> >> > > > >
> >> > > > What is the difficulty? The change will only affect maintaining
> the
> >> > > javax.*
> >> > > > branch and fully renamed jakarta.* dependencies in master.
> >> > > >
> >> > >
> >> > > Ok Gurkan, let's be concrete, do you - you as you personally -
> accept
> >> and
> >> > > commit yourself to port any commit to one of the two branches to the
> >> > other
> >> > > for all the time the project is at apache?
> >> > > if so fine, if not -1 to create us unneeded (+ still unjustified by
> >> > facts)
> >> > > work.
> >> > >
> >> > >
> >> > > >
> >> > > > Regards.
> >> > > > Gurkan
> >> > > >
> >> > > > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <
> >> david.a.jencks@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > I’m not sure exactly how it impacts this decision, but IIUC the
> >> > > geronimo
> >> > > > > cdi spec jar is rather essential for some uses as it has OSGI
> >> support
> >> > > > > whereas IIUC the eclipse/jakarta one doesn’t.
> >> > > > >
> >> > > > > Personally I’m afraid I’m totally on Romain’s side so far,
> AFAICT
> >> > > > Gurkan’s
> >> > > > > proposal will only add difficulty for developers and probably
> >> users.
> >> > > > > Although I haven’t been active here for years I might even vote.
> >> > > > >
> >> > > > > thanks
> >> > > > > David Jencks
> >> > > > >
> >> > > > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
> >> > > cgurkanerdogdu@gmail.com>
> >> > > > > wrote:
> >> > > > > >
> >> > > > > >>
> >> > > > > >> Tomcat works with branches since years without any issue.
> >> > > > > >> All projects we tried to use branches we abandoned branches
> >> just
> >> > > after
> >> > > > > >> having done them.
> >> > > > > >> It is fine if the old branch is no more used but here we know
> >> we
> >> > > will
> >> > > > > >> maintain javax branch more than jakarta one for some time so
> I
> >> > think
> >> > > > we
> >> > > > > >> should avoid it while it is not justified or one of the 2
> >> branches
> >> > > > > (javax)
> >> > > > > >> is "almost dead".
> >> > > > > >
> >> > > > > > Working with branches always happens in all open source
> >> projects.
> >> > > And
> >> > > > > > there are times when it is logical to create the branch.
> Jakarta
> >> > EE 9
> >> > > > API
> >> > > > > > migration is the best time to create such a branch.
> Eventually,
> >> we
> >> > > will
> >> > > > > > create such a branch in Jakarta EE 10.
> >> > > > > >
> >> > > > > > Fact there will be no more javax is useless IMHO, only
> question
> >> we
> >> > > > should
> >> > > > > >> care about is "do we have javax users?" and should we work
> on
> >> > javax
> >> > > > > branch
> >> > > > > >> enough to care about having 2 duplicate branches. Answer is
> >> > > obviously
> >> > > > > yes
> >> > > > > >> and more than jakarta users today, therefore I think for some
> >> > months
> >> > > > > (maybe
> >> > > > > >> a few years) we should stick to javax as our primary branch
> and
> >> > > ensure
> >> > > > > the
> >> > > > > >> alignments and bugfixes can trivially - == without any action
> >> from
> >> > > dev
> >> > > > > - be
> >> > > > > >> ported. It is what we have today.
> >> > > > > >>
> >> > > > > > What could be more natural than maintaining branches (with
> >> > > backporting
> >> > > > > from
> >> > > > > > master only if necessary). With Jakarta EE 10, we will
> >> eventually
> >> > > > create
> >> > > > > > the branch for supporting the EE 8. Also, for the release
> >> > versioning,
> >> > > > it
> >> > > > > is
> >> > > > > > nice to have a 3.x release. The community will notice that 3.x
> >> is
> >> > the
> >> > > > > > starting point of Jakarta EE support. Will you release 2.x
> with
> >> the
> >> > > > > > intention of supporting Jakarta EE 9? I am personally not
> >> positive
> >> > on
> >> > > > > this.
> >> > > > > > I think, 3.x release will also get more interest even if the
> >> > > > > functionality
> >> > > > > > and API stay the same. We can prepare the press release for
> it.
> >> > > > > >
> >> > > > > > Note we shouldn't depend on jakarta/javax api anyway (neither
> as
> >> > > > groupId
> >> > > > > >> nor as transitive dep so this change must stay a noop for
> >> > > consumers).
> >> > > > > >>
> >> > > > > > What is the problem of depending on the official Jakarta EE
> CDI
> >> > API?
> >> > > It
> >> > > > > is
> >> > > > > > an Apache friendly license. Instead of maintaining the
> Geronimo
> >> CDI
> >> > > API
> >> > > > > > internally, it is more logical to use Jakarta EE official CDI
> >> API
> >> > and
> >> > > > > > maintain this API with EE4J community.
> >> > > > > >
> >> > > > > > would also appreciate if you do a vote if you can point out
> the
> >> > > > breaking
> >> > > > > >> changes - except the package renaming - justifying to fork
> >> ourself
> >> > > and
> >> > > > > what
> >> > > > > >> does not work with current solution, can ease the
> >> decision/vote.
> >> > > > > >> Today using jakarta/EE9 API is quite easy (
> >> > > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> >> > > > > >> ).
> >> > > > > >> We should absolutely enhance the pom experience though but it
> >> is
> >> > > > > trivial to
> >> > > > > >> do at maven level - I was envisionning to do it in shade
> >> plugin to
> >> > > be
> >> > > > > more
> >> > > > > >> precise.
> >> > > > > >>
> >> > > > > > I know that there will be no functional change. But, I am also
> >> > > against
> >> > > > > > shading for jakarta.*. If there will be no change on Jakarta
> EE
> >> 10,
> >> > > > will
> >> > > > > we
> >> > > > > > continue to shade? What happens when there will be a change
> in
> >> > EJB,
> >> > > > JMS
> >> > > > > > etc specifications but no change in CDI in Jakarta EE 10?
> Also,
> >> > > VOTING
> >> > > > is
> >> > > > > > the natural thing to do for the community decision. If the
> >> > community
> >> > > > > would
> >> > > > > > like to keep it as it is via shading, it is fine.
> >> > > > > >
> >> > > > > >>
> >> > > > > >> To try to rephrase/clarify my questionning today: you ask for
> >> > > jakarta
> >> > > > > >> support, we already have it in a dev and project efficient
> way
> >> so
> >> > > why
> >> > > > > >> should we change since I don't hink there is anything new -
> >> once
> >> > > again
> >> > > > > if
> >> > > > > >> API starts to fully break discussion is different but github
> >> > doesnt
> >> > > > > reflect
> >> > > > > >> that?
> >> > > > > >>
> >> > > > > > This is not just for Jakarta EE 9 support. As we know, there
> >> will
> >> > be
> >> > > no
> >> > > > > API
> >> > > > > > (functional) change, only package renaming. But, I want to
> >> > emphasize
> >> > > > that
> >> > > > > > with such turning points, it is so logical to integrate
> official
> >> > > > Jakarta
> >> > > > > > CDI API into our master (removing the geronimo-cdi), and
> release
> >> > our
> >> > > > new
> >> > > > > > 3.x version and let the public know that OWB supports official
> >> CDI
> >> > > API
> >> > > > > > beginning with 3.x release. Yeah, shading is an option for
> >> package
> >> > > > > renaming
> >> > > > > > but think long term. Also, I am really against the shading. It
> >> > really
> >> > > > > > disturbs the users which depend on OWB implementation. For
> >> example,
> >> > > > > > currently Glassfish supports Weld integration but one can also
> >> > > > implement
> >> > > > > > OWB to replace Weld in Glassfish. Therefore, instead of using
> >> the
> >> > > > shaded
> >> > > > > > version, it is really important to have the full Jakarta EE
> CDI
> >> API
> >> > > in
> >> > > > > our
> >> > > > > > poms. You will still have javax.* dependency in ur POMs even
> if
> >> > > doing a
> >> > > > > > shade. This is not good idea to still maintain javax.* in our
> >> POM
> >> > > > files.
> >> > > > > >
> >> > > > > > What are other opinions before formal voting?
> >> > > > > > Regards.
> >> > > > > > Gurkan
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> >> > > > rmannibucau@gmail.com
> >> > > > > >
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> >> > > cgurkanerdogdu@gmail.com
> >> > > > >
> >> > > > > a
> >> > > > > >> écrit :
> >> > > > > >>
> >> > > > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also
> >> on
> >> > > > master.
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> Tomcat works with branches since years without any issue.
> >> > > > > >> All projects we tried to use branches we abandoned branches
> >> just
> >> > > after
> >> > > > > >> having done them.
> >> > > > > >> It is fine if the old branch is no more used but here we know
> >> we
> >> > > will
> >> > > > > >> maintain javax branch more than jakarta one for some time so
> I
> >> > think
> >> > > > we
> >> > > > > >> should avoid it while it is not justified or one of the 2
> >> branches
> >> > > > > (javax)
> >> > > > > >> is "almost dead".
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>> sorry but not understand the resistance on this? will you
> >> always
> >> > > > shade
> >> > > > > ?
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> As mentionned, until API needs changes we can't easily
> handle -
> >> > > today
> >> > > > > there
> >> > > > > >> is no change.
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>> creating the new master and maintain the 2.x branch, is the
> >> best
> >> > > > > logical
> >> > > > > >>> way. there will be no javax.* any more. Tomcat maintains 3
> >> > > branches
> >> > > > > and
> >> > > > > >> 1
> >> > > > > >>> master. only maintains 1 branch and 1 master is totally
> fine.
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> Fact there will be no more javax is useless IMHO, only
> >> question we
> >> > > > > should
> >> > > > > >> care about is "do we have javax users?" and should we work
> on
> >> > javax
> >> > > > > branch
> >> > > > > >> enough to care about having 2 duplicate branches. Answer is
> >> > > obviously
> >> > > > > yes
> >> > > > > >> and more than jakarta users today, therefore I think for some
> >> > months
> >> > > > > (maybe
> >> > > > > >> a few years) we should stick to javax as our primary branch
> and
> >> > > ensure
> >> > > > > the
> >> > > > > >> alignments and bugfixes can trivially - == without any action
> >> from
> >> > > dev
> >> > > > > - be
> >> > > > > >> ported. It is what we have today.
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>>
> >> > > > > >>> I will propose a vote shortly to decide on to create a
> master
> >> > with
> >> > > > 3.x
> >> > > > > >> with
> >> > > > > >>> fully support of jakarta with a normal pom dependency with
> >> > jakarta
> >> > > > api.
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >> Note we shouldn't depend on jakarta/javax api anyway (neither
> >> as
> >> > > > groupId
> >> > > > > >> nor as transitive dep so this change must stay a noop for
> >> > > consumers).
> >> > > > > >> I would also appreciate if you do a vote if you can point out
> >> the
> >> > > > > breaking
> >> > > > > >> changes - except the package renaming - justifying to fork
> >> ourself
> >> > > and
> >> > > > > what
> >> > > > > >> does not work with current solution, can ease the
> >> decision/vote.
> >> > > > > >> Today using jakarta/EE9 API is quite easy (
> >> > > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> >> > > > > >> ).
> >> > > > > >> We should absolutely enhance the pom experience though but it
> >> is
> >> > > > > trivial to
> >> > > > > >> do at maven level - I was envisionning to do it in shade
> >> plugin to
> >> > > be
> >> > > > > more
> >> > > > > >> precise.
> >> > > > > >>
> >> > > > > >> To try to rephrase/clarify my questionning today: you ask for
> >> > > jakarta
> >> > > > > >> support, we already have it in a dev and project efficient
> way
> >> so
> >> > > why
> >> > > > > >> should we change since I don't hink there is anything new -
> >> once
> >> > > again
> >> > > > > if
> >> > > > > >> API starts to fully break discussion is different but github
> >> > doesnt
> >> > > > > reflect
> >> > > > > >> that?
> >> > > > > >>
> >> > > > > >>
> >> > > > > >>>
> >> > > > > >>> Regs
> >> > > > > >>> Gurkan
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
> >> > > rmannibucau@gmail.com
> >> > > > >
> >> > > > > >>> wrote:
> >> > > > > >>>
> >> > > > > >>>> Today we don't need, tomorrow I don't know but while API
> does
> >> > not
> >> > > > > >> change
> >> > > > > >>>> (except the package) we shouldn't fork ourself IMHO (cause
> >> it is
> >> > > > what
> >> > > > > >> you
> >> > > > > >>>> propose as a consequence).
> >> > > > > >>>> If it becomes necessary let's do it but my vote is to stay
> >> lazy
> >> > on
> >> > > > > >> that.
> >> > > > > >>>>
> >> > > > > >>>>
> >> > > > > >>>> side note for G API discussion belongs to dev@G but it is
> >> less
> >> > an
> >> > > > > >> issue
> >> > > > > >>> to
> >> > > > > >>>> fork from now since we rarely update the API, the side note
> >> here
> >> > > is
> >> > > > > >> that
> >> > > > > >>>> CDI SE is already fully runnable on ASF stack with jakarta
> >> > package
> >> > > > > >> since
> >> > > > > >>>> some weeks or months, we did all the needed releases.
> >> > > > > >>>>
> >> > > > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> >> > > > > >>>> andraschko.thomas@gmail.com>
> >> > > > > >>>> a écrit :
> >> > > > > >>>>
> >> > > > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our
> >> build.
> >> > > > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
> >> > > > > >>>>>
> >> > > > > >>>>> I'm actually also a supporter of doing a hard cut but it's
> >> not
> >> > > > > >> required
> >> > > > > >>>> and
> >> > > > > >>>>> we can do it for EE 10.
> >> > > > > >>>>>
> >> > > > > >>>>> <
> >> > > > > >>>>>
> >> > > > > >>>>
> >> > > > > >>>
> >> > > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >> > > > > >>>>>>
> >> > > > > >>>>> Virenfrei.
> >> > > > > >>>>> www.avast.com
> >> > > > > >>>>> <
> >> > > > > >>>>>
> >> > > > > >>>>
> >> > > > > >>>
> >> > > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >> > > > > >>>>>>
> >> > > > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >> > > > > >>>>>
> >> > > > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> >> > > > > >>>>> cgurkanerdogdu@gmail.com>:
> >> > > > > >>>>>
> >> > > > > >>>>>> We need to maintain two branches
> >> > > > > >>>>>>
> >> > > > > >>>>>> EE 8 for javax.* package 2.x branch
> >> > > > > >>>>>> EE 9 for jakarta.* package 3.x master
> >> > > > > >>>>>>
> >> > > > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> >> > > > > >> rmannibucau@gmail.com
> >> > > > > >>>>
> >> > > > > >>>>>> wrote:
> >> > > > > >>>>>>
> >> > > > > >>>>>>> Hi,
> >> > > > > >>>>>>>
> >> > > > > >>>>>>> I'll probably restate my position on that: if EE 9
> brings
> >> > > > > >>>>> significatively
> >> > > > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8
> >> but I
> >> > > can
> >> > > > > >>> have
> >> > > > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can
> >> stay
> >> > as
> >> > > > > >> we
> >> > > > > >>>> are
> >> > > > > >>>>> I
> >> > > > > >>>>>>> think avoiding to maintain two branches we can't merge
> >> > > regularly.
> >> > > > > >>>>>>>
> >> > > > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> >> > > > > >>>> cgurkanerdogdu@gmail.com>
> >> > > > > >>>>> a
> >> > > > > >>>>>>> écrit :
> >> > > > > >>>>>>>
> >> > > > > >>>>>>>> Hi
> >> > > > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0
> to
> >> > > > > >> support
> >> > > > > >>>>>> upcoming
> >> > > > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of
> >> using
> >> > > the
> >> > > > > >>>>> Apache
> >> > > > > >>>>>>>> based api.
> >> > > > > >>>>>>>> Regards
> >> > > > > >>>>>>>> Gurkan
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>> --
> >> > > > > >>>>>>>> Gurkan Erdogdu
> >> > > > > >>>>>>>> http://gurkanerdogdu.blogspot.com
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>
> >> > > > > >>>>>> --
> >> > > > > >>>>>> Gurkan Erdogdu
> >> > > > > >>>>>> http://gurkanerdogdu.blogspot.com
> >> > > > > >>>>>>
> >> > > > > >>>>>
> >> > > > > >>>>
> >> > > > > >>> --
> >> > > > > >>> Gurkan Erdogdu
> >> > > > > >>> http://gurkanerdogdu.blogspot.com
> >> > > > > >>>
> >> > > > > >>
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > Gurkan Erdogdu
> >> > > > > > http://gurkanerdogdu.blogspot.com
> >> > > > >
> >> > > > >
> >> > > >
> >> > > > --
> >> > > > Gurkan Erdogdu
> >> > > > http://gurkanerdogdu.blogspot.com
> >> > > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Gurkan Erdogdu
> >> > http://gurkanerdogdu.blogspot.com
> >> >
> >>
> >
> >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
Re: Jakarta EE 9 Support
Posted by Gurkan Erdogdu <cg...@gmail.com>.
There are some string literals in source code using javax.*. for example,
in BeansDeployer, public static final String JAVAX_ENTERPRISE_PACKAGE =
"javax.enterprise.";.
How is the shading plugin fixes these?
Regards.
Gurkan
On Sun, Jun 7, 2020 at 10:55 PM Gurkan Erdogdu <cg...@gmail.com>
wrote:
> They also impled the bda differently than us making it only usable for
>> single bda apps and created arc@quarkus which violates that, so not sure
>> we
>> should copy what others do. I tend to prefer to add thinking on top of
>> that
>> in the context of our project which is diff than the RI (by design and by
>> workforce).
>>
> This is not copying but not going into discussion more.
>
>
>> I can agree that in one year we reverse the pattern, shade becoming javax.
>> But since we cant enforce anyone to do the sync between branches and due
>> to
>> past years contributions stats, we must not go that way IMHO, it would
>> either make us expose 2 bad branches or kill our resources for no user
>> gains. Indeed that is my opinion but from the stats i have today it is my
>> conclusion.
>
> You have concerns about the community, understanding.
>
> Please discuss it on G, it does not impact OWB - and btw this is not what
>> had been said ;).
>>
> Thanks for the pointer
>
> Regards.
> Gurkan
>
> On Sun, Jun 7, 2020 at 9:50 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu <cg...@gmail.com> a
>> écrit :
>>
>> > >
>> > > So to conclude on this point not belonging to OWB, we still need our
>> fork
>> > > and eclipse always answered saying "yes we want OSGi [but we don't
>> really
>> > > know]" - and I know eclipse+EE has a lot of OSGi experts but they
>> don't
>> > > work on that factually so OSGi is done at minimal cost.
>> >
>> > OK thanks for the clarification. I am not an OSGI expert.
>> >
>> > Ok Gurkan, let's be concrete, do you - you as you personally - accept
>> and
>> > > commit yourself to port any commit to one of the two branches to the
>> > other
>> > > for all the time the project is at apache?
>> > > if so fine, if not -1 to create us unneeded (+ still unjustified by
>> > facts)
>> > > work.
>> >
>> > :=)
>> > Hey, I'm just proposing what I think about. If nobody cares about it
>> or is
>> > not beneficial, it is ok, and also there is no need to VOTE (This is why
>> > I'd like to get more opinions on it).
>>
>>
>> It is fine, just wanted to emphasis the consequence and what it means for
>> the project.
>>
>> But look at Weld, they did the
>> > update, https://github.com/weld and full of updating their pom to use
>> > jakarta.*
>> >
>>
>> They also impled the bda differently than us making it only usable for
>> single bda apps and created arc@quarkus which violates that, so not sure
>> we
>> should copy what others do. I tend to prefer to add thinking on top of
>> that
>> in the context of our project which is diff than the RI (by design and by
>> workforce).
>>
>>
>>
>> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
>> > geronimo-...specs which depend on javax.*. Today or tomorrow, we will
>> > eventually move to jakarta.* namespace. Instead of working with such
>> > shading plugin stuff as a workaround, I just offer to take the master to
>> > jakarta.* and update all OWB modules' dependency from javax.* to
>> jakarta.*
>> > official APIS. This is not related to who will maintain the branches.
>> You
>> > know that ASF works as a voluntary based approach. You can not push
>> anybody
>> > to work on anything as in commercial companies.
>> >
>>
>> I can agree that in one year we reverse the pattern, shade becoming javax.
>> But since we cant enforce anyone to do the sync between branches and due
>> to
>> past years contributions stats, we must not go that way IMHO, it would
>> either make us expose 2 bad branches or kill our resources for no user
>> gains. Indeed that is my opinion but from the stats i have today it is my
>> conclusion.
>>
>>
>> > Also, regarding the cost and energy you mention to maintain the branch,
>> via
>> > Geronimo specs, you will need to update all of the Geronimo Specs and
>> > maintain them. I think this is not rational because now, jakarta.*
>> official
>> > API license is EPL and Apache friendly. Why do I need to maintain for
>> > example Geronimo EL?
>> >
>>
>> Please discuss it on G, it does not impact OWB - and btw this is not what
>> had been said ;).
>>
>>
>>
>> > Regards.
>> > Gurkan
>> >
>> >
>> >
>> >
>> >
>> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > wrote:
>> >
>> > > Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cg...@gmail.com>
>> a
>> > > écrit :
>> > >
>> > > > Hi David
>> > > >
>> > > > I’m not sure exactly how it impacts this decision, but IIUC the
>> > geronimo
>> > > > > cdi spec jar is rather essential for some uses as it has OSGI
>> support
>> > > > > whereas IIUC the eclipse/jakarta one doesn’t.
>> > > > >
>> > > > No, it is not correct. It has OSGI support. GlassFish is an OSGI
>> based
>> > > > server.You can grap the code from
>> https://github.com/eclipse-ee4j/cdi
>> > > and
>> > > > build. It has OSGI enabled MANIFEST.MF file.
>> > > >
>> > >
>> > > Not, it is not correct Gurkan ;).
>> > > jakarta does NOT support OSGi properly, it does it the old way and
>> break
>> > > several rules. For instance last CDI spec jar contains:
>> > >
>> > > Manifest-Version: 1.0
>> > > Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
>> > > r Java)
>> > > Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
>> > > Bundle-SymbolicName: jakarta.enterprise.cdi-api
>> > > Built-By: default
>> > > Bnd-LastModified: 1590678420932
>> > > Bundle-ManifestVersion: 2
>> > > Bundle-DocURL: https://jboss.org
>> > > Bundle-Vendor: JBoss by Red Hat, Inc.
>> > > Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
>> > > 3)",jakarta.interceptor;version="[2.0,3)"
>> > > Require-Capability: osgi.ee;filter:="(&(osgi.ee
>> =JavaSE)(version=1.8))"
>> > > Tool: Bnd-2.4.1.201501161923
>> > > Originally-Created-By: Apache Maven Bundle Plugin
>> > > Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
>> > > ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
>> > > nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
>> > > sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
>> > > arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
>> > > rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
>> > > ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
>> > > til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
>> > > ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
>> > > ct.se
>> ;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
>> > > se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
>> > > arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
>> > > ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
>> > > ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
>> > > .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
>> > > karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
>> > > ise.util",jakarta.enterprise.util;version="3.0"
>> > > Bundle-Name: CDI APIs
>> > > Bundle-Version: 3.0.0.M4
>> > > Build-Jdk-Spec: 1.8
>> > > Created-By: Apache Maven Bundle Plugin
>> > > Build-Jdk: 1.8.0_202
>> > >
>> > > Where are the osgi.serviceloader and osgi.contract ?
>> > > This is important and used by OSGi-CDI for example (even if it can be
>> > > worked around).
>> > >
>> > > So to conclude on this point not belonging to OWB, we still need our
>> fork
>> > > and eclipse always answered saying "yes we want OSGi [but we don't
>> really
>> > > know]" - and I know eclipse+EE has a lot of OSGi experts but they
>> don't
>> > > work on that factually so OSGi is done at minimal cost.
>> > >
>> > >
>> > > >
>> > > > Gurkan’s proposal will only add difficulty for developers and
>> probably
>> > > > > users.
>> > > > >
>> > > > What is the difficulty? The change will only affect maintaining the
>> > > javax.*
>> > > > branch and fully renamed jakarta.* dependencies in master.
>> > > >
>> > >
>> > > Ok Gurkan, let's be concrete, do you - you as you personally - accept
>> and
>> > > commit yourself to port any commit to one of the two branches to the
>> > other
>> > > for all the time the project is at apache?
>> > > if so fine, if not -1 to create us unneeded (+ still unjustified by
>> > facts)
>> > > work.
>> > >
>> > >
>> > > >
>> > > > Regards.
>> > > > Gurkan
>> > > >
>> > > > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <
>> david.a.jencks@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > I’m not sure exactly how it impacts this decision, but IIUC the
>> > > geronimo
>> > > > > cdi spec jar is rather essential for some uses as it has OSGI
>> support
>> > > > > whereas IIUC the eclipse/jakarta one doesn’t.
>> > > > >
>> > > > > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT
>> > > > Gurkan’s
>> > > > > proposal will only add difficulty for developers and probably
>> users.
>> > > > > Although I haven’t been active here for years I might even vote.
>> > > > >
>> > > > > thanks
>> > > > > David Jencks
>> > > > >
>> > > > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
>> > > cgurkanerdogdu@gmail.com>
>> > > > > wrote:
>> > > > > >
>> > > > > >>
>> > > > > >> Tomcat works with branches since years without any issue.
>> > > > > >> All projects we tried to use branches we abandoned branches
>> just
>> > > after
>> > > > > >> having done them.
>> > > > > >> It is fine if the old branch is no more used but here we know
>> we
>> > > will
>> > > > > >> maintain javax branch more than jakarta one for some time so I
>> > think
>> > > > we
>> > > > > >> should avoid it while it is not justified or one of the 2
>> branches
>> > > > > (javax)
>> > > > > >> is "almost dead".
>> > > > > >
>> > > > > > Working with branches always happens in all open source
>> projects.
>> > > And
>> > > > > > there are times when it is logical to create the branch. Jakarta
>> > EE 9
>> > > > API
>> > > > > > migration is the best time to create such a branch. Eventually,
>> we
>> > > will
>> > > > > > create such a branch in Jakarta EE 10.
>> > > > > >
>> > > > > > Fact there will be no more javax is useless IMHO, only question
>> we
>> > > > should
>> > > > > >> care about is "do we have javax users?" and should we work on
>> > javax
>> > > > > branch
>> > > > > >> enough to care about having 2 duplicate branches. Answer is
>> > > obviously
>> > > > > yes
>> > > > > >> and more than jakarta users today, therefore I think for some
>> > months
>> > > > > (maybe
>> > > > > >> a few years) we should stick to javax as our primary branch and
>> > > ensure
>> > > > > the
>> > > > > >> alignments and bugfixes can trivially - == without any action
>> from
>> > > dev
>> > > > > - be
>> > > > > >> ported. It is what we have today.
>> > > > > >>
>> > > > > > What could be more natural than maintaining branches (with
>> > > backporting
>> > > > > from
>> > > > > > master only if necessary). With Jakarta EE 10, we will
>> eventually
>> > > > create
>> > > > > > the branch for supporting the EE 8. Also, for the release
>> > versioning,
>> > > > it
>> > > > > is
>> > > > > > nice to have a 3.x release. The community will notice that 3.x
>> is
>> > the
>> > > > > > starting point of Jakarta EE support. Will you release 2.x with
>> the
>> > > > > > intention of supporting Jakarta EE 9? I am personally not
>> positive
>> > on
>> > > > > this.
>> > > > > > I think, 3.x release will also get more interest even if the
>> > > > > functionality
>> > > > > > and API stay the same. We can prepare the press release for it.
>> > > > > >
>> > > > > > Note we shouldn't depend on jakarta/javax api anyway (neither as
>> > > > groupId
>> > > > > >> nor as transitive dep so this change must stay a noop for
>> > > consumers).
>> > > > > >>
>> > > > > > What is the problem of depending on the official Jakarta EE CDI
>> > API?
>> > > It
>> > > > > is
>> > > > > > an Apache friendly license. Instead of maintaining the Geronimo
>> CDI
>> > > API
>> > > > > > internally, it is more logical to use Jakarta EE official CDI
>> API
>> > and
>> > > > > > maintain this API with EE4J community.
>> > > > > >
>> > > > > > would also appreciate if you do a vote if you can point out the
>> > > > breaking
>> > > > > >> changes - except the package renaming - justifying to fork
>> ourself
>> > > and
>> > > > > what
>> > > > > >> does not work with current solution, can ease the
>> decision/vote.
>> > > > > >> Today using jakarta/EE9 API is quite easy (
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
>> > > > > >> ).
>> > > > > >> We should absolutely enhance the pom experience though but it
>> is
>> > > > > trivial to
>> > > > > >> do at maven level - I was envisionning to do it in shade
>> plugin to
>> > > be
>> > > > > more
>> > > > > >> precise.
>> > > > > >>
>> > > > > > I know that there will be no functional change. But, I am also
>> > > against
>> > > > > > shading for jakarta.*. If there will be no change on Jakarta EE
>> 10,
>> > > > will
>> > > > > we
>> > > > > > continue to shade? What happens when there will be a change in
>> > EJB,
>> > > > JMS
>> > > > > > etc specifications but no change in CDI in Jakarta EE 10? Also,
>> > > VOTING
>> > > > is
>> > > > > > the natural thing to do for the community decision. If the
>> > community
>> > > > > would
>> > > > > > like to keep it as it is via shading, it is fine.
>> > > > > >
>> > > > > >>
>> > > > > >> To try to rephrase/clarify my questionning today: you ask for
>> > > jakarta
>> > > > > >> support, we already have it in a dev and project efficient way
>> so
>> > > why
>> > > > > >> should we change since I don't hink there is anything new -
>> once
>> > > again
>> > > > > if
>> > > > > >> API starts to fully break discussion is different but github
>> > doesnt
>> > > > > reflect
>> > > > > >> that?
>> > > > > >>
>> > > > > > This is not just for Jakarta EE 9 support. As we know, there
>> will
>> > be
>> > > no
>> > > > > API
>> > > > > > (functional) change, only package renaming. But, I want to
>> > emphasize
>> > > > that
>> > > > > > with such turning points, it is so logical to integrate official
>> > > > Jakarta
>> > > > > > CDI API into our master (removing the geronimo-cdi), and release
>> > our
>> > > > new
>> > > > > > 3.x version and let the public know that OWB supports official
>> CDI
>> > > API
>> > > > > > beginning with 3.x release. Yeah, shading is an option for
>> package
>> > > > > renaming
>> > > > > > but think long term. Also, I am really against the shading. It
>> > really
>> > > > > > disturbs the users which depend on OWB implementation. For
>> example,
>> > > > > > currently Glassfish supports Weld integration but one can also
>> > > > implement
>> > > > > > OWB to replace Weld in Glassfish. Therefore, instead of using
>> the
>> > > > shaded
>> > > > > > version, it is really important to have the full Jakarta EE CDI
>> API
>> > > in
>> > > > > our
>> > > > > > poms. You will still have javax.* dependency in ur POMs even if
>> > > doing a
>> > > > > > shade. This is not good idea to still maintain javax.* in our
>> POM
>> > > > files.
>> > > > > >
>> > > > > > What are other opinions before formal voting?
>> > > > > > Regards.
>> > > > > > Gurkan
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
>> > > > rmannibucau@gmail.com
>> > > > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
>> > > cgurkanerdogdu@gmail.com
>> > > > >
>> > > > > a
>> > > > > >> écrit :
>> > > > > >>
>> > > > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also
>> on
>> > > > master.
>> > > > > >>>
>> > > > > >>
>> > > > > >> Tomcat works with branches since years without any issue.
>> > > > > >> All projects we tried to use branches we abandoned branches
>> just
>> > > after
>> > > > > >> having done them.
>> > > > > >> It is fine if the old branch is no more used but here we know
>> we
>> > > will
>> > > > > >> maintain javax branch more than jakarta one for some time so I
>> > think
>> > > > we
>> > > > > >> should avoid it while it is not justified or one of the 2
>> branches
>> > > > > (javax)
>> > > > > >> is "almost dead".
>> > > > > >>
>> > > > > >>
>> > > > > >>> sorry but not understand the resistance on this? will you
>> always
>> > > > shade
>> > > > > ?
>> > > > > >>>
>> > > > > >>
>> > > > > >> As mentionned, until API needs changes we can't easily handle -
>> > > today
>> > > > > there
>> > > > > >> is no change.
>> > > > > >>
>> > > > > >>
>> > > > > >>> creating the new master and maintain the 2.x branch, is the
>> best
>> > > > > logical
>> > > > > >>> way. there will be no javax.* any more. Tomcat maintains 3
>> > > branches
>> > > > > and
>> > > > > >> 1
>> > > > > >>> master. only maintains 1 branch and 1 master is totally fine.
>> > > > > >>>
>> > > > > >>
>> > > > > >> Fact there will be no more javax is useless IMHO, only
>> question we
>> > > > > should
>> > > > > >> care about is "do we have javax users?" and should we work on
>> > javax
>> > > > > branch
>> > > > > >> enough to care about having 2 duplicate branches. Answer is
>> > > obviously
>> > > > > yes
>> > > > > >> and more than jakarta users today, therefore I think for some
>> > months
>> > > > > (maybe
>> > > > > >> a few years) we should stick to javax as our primary branch and
>> > > ensure
>> > > > > the
>> > > > > >> alignments and bugfixes can trivially - == without any action
>> from
>> > > dev
>> > > > > - be
>> > > > > >> ported. It is what we have today.
>> > > > > >>
>> > > > > >>
>> > > > > >>>
>> > > > > >>> I will propose a vote shortly to decide on to create a master
>> > with
>> > > > 3.x
>> > > > > >> with
>> > > > > >>> fully support of jakarta with a normal pom dependency with
>> > jakarta
>> > > > api.
>> > > > > >>>
>> > > > > >>
>> > > > > >> Note we shouldn't depend on jakarta/javax api anyway (neither
>> as
>> > > > groupId
>> > > > > >> nor as transitive dep so this change must stay a noop for
>> > > consumers).
>> > > > > >> I would also appreciate if you do a vote if you can point out
>> the
>> > > > > breaking
>> > > > > >> changes - except the package renaming - justifying to fork
>> ourself
>> > > and
>> > > > > what
>> > > > > >> does not work with current solution, can ease the
>> decision/vote.
>> > > > > >> Today using jakarta/EE9 API is quite easy (
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
>> > > > > >> ).
>> > > > > >> We should absolutely enhance the pom experience though but it
>> is
>> > > > > trivial to
>> > > > > >> do at maven level - I was envisionning to do it in shade
>> plugin to
>> > > be
>> > > > > more
>> > > > > >> precise.
>> > > > > >>
>> > > > > >> To try to rephrase/clarify my questionning today: you ask for
>> > > jakarta
>> > > > > >> support, we already have it in a dev and project efficient way
>> so
>> > > why
>> > > > > >> should we change since I don't hink there is anything new -
>> once
>> > > again
>> > > > > if
>> > > > > >> API starts to fully break discussion is different but github
>> > doesnt
>> > > > > reflect
>> > > > > >> that?
>> > > > > >>
>> > > > > >>
>> > > > > >>>
>> > > > > >>> Regs
>> > > > > >>> Gurkan
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
>> > > rmannibucau@gmail.com
>> > > > >
>> > > > > >>> wrote:
>> > > > > >>>
>> > > > > >>>> Today we don't need, tomorrow I don't know but while API does
>> > not
>> > > > > >> change
>> > > > > >>>> (except the package) we shouldn't fork ourself IMHO (cause
>> it is
>> > > > what
>> > > > > >> you
>> > > > > >>>> propose as a consequence).
>> > > > > >>>> If it becomes necessary let's do it but my vote is to stay
>> lazy
>> > on
>> > > > > >> that.
>> > > > > >>>>
>> > > > > >>>>
>> > > > > >>>> side note for G API discussion belongs to dev@G but it is
>> less
>> > an
>> > > > > >> issue
>> > > > > >>> to
>> > > > > >>>> fork from now since we rarely update the API, the side note
>> here
>> > > is
>> > > > > >> that
>> > > > > >>>> CDI SE is already fully runnable on ASF stack with jakarta
>> > package
>> > > > > >> since
>> > > > > >>>> some weeks or months, we did all the needed releases.
>> > > > > >>>>
>> > > > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
>> > > > > >>>> andraschko.thomas@gmail.com>
>> > > > > >>>> a écrit :
>> > > > > >>>>
>> > > > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our
>> build.
>> > > > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
>> > > > > >>>>>
>> > > > > >>>>> I'm actually also a supporter of doing a hard cut but it's
>> not
>> > > > > >> required
>> > > > > >>>> and
>> > > > > >>>>> we can do it for EE 10.
>> > > > > >>>>>
>> > > > > >>>>> <
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>>
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>> > > > > >>>>>>
>> > > > > >>>>> Virenfrei.
>> > > > > >>>>> www.avast.com
>> > > > > >>>>> <
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>>
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>> > > > > >>>>>>
>> > > > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> > > > > >>>>>
>> > > > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
>> > > > > >>>>> cgurkanerdogdu@gmail.com>:
>> > > > > >>>>>
>> > > > > >>>>>> We need to maintain two branches
>> > > > > >>>>>>
>> > > > > >>>>>> EE 8 for javax.* package 2.x branch
>> > > > > >>>>>> EE 9 for jakarta.* package 3.x master
>> > > > > >>>>>>
>> > > > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
>> > > > > >> rmannibucau@gmail.com
>> > > > > >>>>
>> > > > > >>>>>> wrote:
>> > > > > >>>>>>
>> > > > > >>>>>>> Hi,
>> > > > > >>>>>>>
>> > > > > >>>>>>> I'll probably restate my position on that: if EE 9 brings
>> > > > > >>>>> significatively
>> > > > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8
>> but I
>> > > can
>> > > > > >>> have
>> > > > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can
>> stay
>> > as
>> > > > > >> we
>> > > > > >>>> are
>> > > > > >>>>> I
>> > > > > >>>>>>> think avoiding to maintain two branches we can't merge
>> > > regularly.
>> > > > > >>>>>>>
>> > > > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
>> > > > > >>>> cgurkanerdogdu@gmail.com>
>> > > > > >>>>> a
>> > > > > >>>>>>> écrit :
>> > > > > >>>>>>>
>> > > > > >>>>>>>> Hi
>> > > > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
>> > > > > >> support
>> > > > > >>>>>> upcoming
>> > > > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of
>> using
>> > > the
>> > > > > >>>>> Apache
>> > > > > >>>>>>>> based api.
>> > > > > >>>>>>>> Regards
>> > > > > >>>>>>>> Gurkan
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> --
>> > > > > >>>>>>>> Gurkan Erdogdu
>> > > > > >>>>>>>> http://gurkanerdogdu.blogspot.com
>> > > > > >>>>>>>>
>> > > > > >>>>>>>
>> > > > > >>>>>> --
>> > > > > >>>>>> Gurkan Erdogdu
>> > > > > >>>>>> http://gurkanerdogdu.blogspot.com
>> > > > > >>>>>>
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>> --
>> > > > > >>> Gurkan Erdogdu
>> > > > > >>> http://gurkanerdogdu.blogspot.com
>> > > > > >>>
>> > > > > >>
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Gurkan Erdogdu
>> > > > > > http://gurkanerdogdu.blogspot.com
>> > > > >
>> > > > >
>> > > >
>> > > > --
>> > > > Gurkan Erdogdu
>> > > > http://gurkanerdogdu.blogspot.com
>> > > >
>> > >
>> >
>> >
>> > --
>> > Gurkan Erdogdu
>> > http://gurkanerdogdu.blogspot.com
>> >
>>
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Gurkan Erdogdu <cg...@gmail.com>.
>
> They also impled the bda differently than us making it only usable for
> single bda apps and created arc@quarkus which violates that, so not sure
> we
> should copy what others do. I tend to prefer to add thinking on top of that
> in the context of our project which is diff than the RI (by design and by
> workforce).
>
This is not copying but not going into discussion more.
> I can agree that in one year we reverse the pattern, shade becoming javax.
> But since we cant enforce anyone to do the sync between branches and due to
> past years contributions stats, we must not go that way IMHO, it would
> either make us expose 2 bad branches or kill our resources for no user
> gains. Indeed that is my opinion but from the stats i have today it is my
> conclusion.
You have concerns about the community, understanding.
Please discuss it on G, it does not impact OWB - and btw this is not what
> had been said ;).
>
Thanks for the pointer
Regards.
Gurkan
On Sun, Jun 7, 2020 at 9:50 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu <cg...@gmail.com> a
> écrit :
>
> > >
> > > So to conclude on this point not belonging to OWB, we still need our
> fork
> > > and eclipse always answered saying "yes we want OSGi [but we don't
> really
> > > know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> > > work on that factually so OSGi is done at minimal cost.
> >
> > OK thanks for the clarification. I am not an OSGI expert.
> >
> > Ok Gurkan, let's be concrete, do you - you as you personally - accept and
> > > commit yourself to port any commit to one of the two branches to the
> > other
> > > for all the time the project is at apache?
> > > if so fine, if not -1 to create us unneeded (+ still unjustified by
> > facts)
> > > work.
> >
> > :=)
> > Hey, I'm just proposing what I think about. If nobody cares about it or
> is
> > not beneficial, it is ok, and also there is no need to VOTE (This is why
> > I'd like to get more opinions on it).
>
>
> It is fine, just wanted to emphasis the consequence and what it means for
> the project.
>
> But look at Weld, they did the
> > update, https://github.com/weld and full of updating their pom to use
> > jakarta.*
> >
>
> They also impled the bda differently than us making it only usable for
> single bda apps and created arc@quarkus which violates that, so not sure
> we
> should copy what others do. I tend to prefer to add thinking on top of that
> in the context of our project which is diff than the RI (by design and by
> workforce).
>
>
>
> > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
> > geronimo-...specs which depend on javax.*. Today or tomorrow, we will
> > eventually move to jakarta.* namespace. Instead of working with such
> > shading plugin stuff as a workaround, I just offer to take the master to
> > jakarta.* and update all OWB modules' dependency from javax.* to
> jakarta.*
> > official APIS. This is not related to who will maintain the branches. You
> > know that ASF works as a voluntary based approach. You can not push
> anybody
> > to work on anything as in commercial companies.
> >
>
> I can agree that in one year we reverse the pattern, shade becoming javax.
> But since we cant enforce anyone to do the sync between branches and due to
> past years contributions stats, we must not go that way IMHO, it would
> either make us expose 2 bad branches or kill our resources for no user
> gains. Indeed that is my opinion but from the stats i have today it is my
> conclusion.
>
>
> > Also, regarding the cost and energy you mention to maintain the branch,
> via
> > Geronimo specs, you will need to update all of the Geronimo Specs and
> > maintain them. I think this is not rational because now, jakarta.*
> official
> > API license is EPL and Apache friendly. Why do I need to maintain for
> > example Geronimo EL?
> >
>
> Please discuss it on G, it does not impact OWB - and btw this is not what
> had been said ;).
>
>
>
> > Regards.
> > Gurkan
> >
> >
> >
> >
> >
> > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> > > Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cg...@gmail.com>
> a
> > > écrit :
> > >
> > > > Hi David
> > > >
> > > > I’m not sure exactly how it impacts this decision, but IIUC the
> > geronimo
> > > > > cdi spec jar is rather essential for some uses as it has OSGI
> support
> > > > > whereas IIUC the eclipse/jakarta one doesn’t.
> > > > >
> > > > No, it is not correct. It has OSGI support. GlassFish is an OSGI
> based
> > > > server.You can grap the code from
> https://github.com/eclipse-ee4j/cdi
> > > and
> > > > build. It has OSGI enabled MANIFEST.MF file.
> > > >
> > >
> > > Not, it is not correct Gurkan ;).
> > > jakarta does NOT support OSGi properly, it does it the old way and
> break
> > > several rules. For instance last CDI spec jar contains:
> > >
> > > Manifest-Version: 1.0
> > > Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
> > > r Java)
> > > Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
> > > Bundle-SymbolicName: jakarta.enterprise.cdi-api
> > > Built-By: default
> > > Bnd-LastModified: 1590678420932
> > > Bundle-ManifestVersion: 2
> > > Bundle-DocURL: https://jboss.org
> > > Bundle-Vendor: JBoss by Red Hat, Inc.
> > > Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> > > 3)",jakarta.interceptor;version="[2.0,3)"
> > > Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> > > Tool: Bnd-2.4.1.201501161923
> > > Originally-Created-By: Apache Maven Bundle Plugin
> > > Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> > > ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> > > nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> > > sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> > > arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> > > rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> > > ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> > > til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> > > ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> > > ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> > > se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> > > arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> > > ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> > > ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> > > .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> > > karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> > > ise.util",jakarta.enterprise.util;version="3.0"
> > > Bundle-Name: CDI APIs
> > > Bundle-Version: 3.0.0.M4
> > > Build-Jdk-Spec: 1.8
> > > Created-By: Apache Maven Bundle Plugin
> > > Build-Jdk: 1.8.0_202
> > >
> > > Where are the osgi.serviceloader and osgi.contract ?
> > > This is important and used by OSGi-CDI for example (even if it can be
> > > worked around).
> > >
> > > So to conclude on this point not belonging to OWB, we still need our
> fork
> > > and eclipse always answered saying "yes we want OSGi [but we don't
> really
> > > know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> > > work on that factually so OSGi is done at minimal cost.
> > >
> > >
> > > >
> > > > Gurkan’s proposal will only add difficulty for developers and
> probably
> > > > > users.
> > > > >
> > > > What is the difficulty? The change will only affect maintaining the
> > > javax.*
> > > > branch and fully renamed jakarta.* dependencies in master.
> > > >
> > >
> > > Ok Gurkan, let's be concrete, do you - you as you personally - accept
> and
> > > commit yourself to port any commit to one of the two branches to the
> > other
> > > for all the time the project is at apache?
> > > if so fine, if not -1 to create us unneeded (+ still unjustified by
> > facts)
> > > work.
> > >
> > >
> > > >
> > > > Regards.
> > > > Gurkan
> > > >
> > > > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <
> david.a.jencks@gmail.com>
> > > > wrote:
> > > >
> > > > > I’m not sure exactly how it impacts this decision, but IIUC the
> > > geronimo
> > > > > cdi spec jar is rather essential for some uses as it has OSGI
> support
> > > > > whereas IIUC the eclipse/jakarta one doesn’t.
> > > > >
> > > > > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT
> > > > Gurkan’s
> > > > > proposal will only add difficulty for developers and probably
> users.
> > > > > Although I haven’t been active here for years I might even vote.
> > > > >
> > > > > thanks
> > > > > David Jencks
> > > > >
> > > > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
> > > cgurkanerdogdu@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >>
> > > > > >> Tomcat works with branches since years without any issue.
> > > > > >> All projects we tried to use branches we abandoned branches just
> > > after
> > > > > >> having done them.
> > > > > >> It is fine if the old branch is no more used but here we know we
> > > will
> > > > > >> maintain javax branch more than jakarta one for some time so I
> > think
> > > > we
> > > > > >> should avoid it while it is not justified or one of the 2
> branches
> > > > > (javax)
> > > > > >> is "almost dead".
> > > > > >
> > > > > > Working with branches always happens in all open source projects.
> > > And
> > > > > > there are times when it is logical to create the branch. Jakarta
> > EE 9
> > > > API
> > > > > > migration is the best time to create such a branch. Eventually,
> we
> > > will
> > > > > > create such a branch in Jakarta EE 10.
> > > > > >
> > > > > > Fact there will be no more javax is useless IMHO, only question
> we
> > > > should
> > > > > >> care about is "do we have javax users?" and should we work on
> > javax
> > > > > branch
> > > > > >> enough to care about having 2 duplicate branches. Answer is
> > > obviously
> > > > > yes
> > > > > >> and more than jakarta users today, therefore I think for some
> > months
> > > > > (maybe
> > > > > >> a few years) we should stick to javax as our primary branch and
> > > ensure
> > > > > the
> > > > > >> alignments and bugfixes can trivially - == without any action
> from
> > > dev
> > > > > - be
> > > > > >> ported. It is what we have today.
> > > > > >>
> > > > > > What could be more natural than maintaining branches (with
> > > backporting
> > > > > from
> > > > > > master only if necessary). With Jakarta EE 10, we will eventually
> > > > create
> > > > > > the branch for supporting the EE 8. Also, for the release
> > versioning,
> > > > it
> > > > > is
> > > > > > nice to have a 3.x release. The community will notice that 3.x is
> > the
> > > > > > starting point of Jakarta EE support. Will you release 2.x with
> the
> > > > > > intention of supporting Jakarta EE 9? I am personally not
> positive
> > on
> > > > > this.
> > > > > > I think, 3.x release will also get more interest even if the
> > > > > functionality
> > > > > > and API stay the same. We can prepare the press release for it.
> > > > > >
> > > > > > Note we shouldn't depend on jakarta/javax api anyway (neither as
> > > > groupId
> > > > > >> nor as transitive dep so this change must stay a noop for
> > > consumers).
> > > > > >>
> > > > > > What is the problem of depending on the official Jakarta EE CDI
> > API?
> > > It
> > > > > is
> > > > > > an Apache friendly license. Instead of maintaining the Geronimo
> CDI
> > > API
> > > > > > internally, it is more logical to use Jakarta EE official CDI API
> > and
> > > > > > maintain this API with EE4J community.
> > > > > >
> > > > > > would also appreciate if you do a vote if you can point out the
> > > > breaking
> > > > > >> changes - except the package renaming - justifying to fork
> ourself
> > > and
> > > > > what
> > > > > >> does not work with current solution, can ease the decision/vote.
> > > > > >> Today using jakarta/EE9 API is quite easy (
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > > > >> ).
> > > > > >> We should absolutely enhance the pom experience though but it is
> > > > > trivial to
> > > > > >> do at maven level - I was envisionning to do it in shade plugin
> to
> > > be
> > > > > more
> > > > > >> precise.
> > > > > >>
> > > > > > I know that there will be no functional change. But, I am also
> > > against
> > > > > > shading for jakarta.*. If there will be no change on Jakarta EE
> 10,
> > > > will
> > > > > we
> > > > > > continue to shade? What happens when there will be a change in
> > EJB,
> > > > JMS
> > > > > > etc specifications but no change in CDI in Jakarta EE 10? Also,
> > > VOTING
> > > > is
> > > > > > the natural thing to do for the community decision. If the
> > community
> > > > > would
> > > > > > like to keep it as it is via shading, it is fine.
> > > > > >
> > > > > >>
> > > > > >> To try to rephrase/clarify my questionning today: you ask for
> > > jakarta
> > > > > >> support, we already have it in a dev and project efficient way
> so
> > > why
> > > > > >> should we change since I don't hink there is anything new - once
> > > again
> > > > > if
> > > > > >> API starts to fully break discussion is different but github
> > doesnt
> > > > > reflect
> > > > > >> that?
> > > > > >>
> > > > > > This is not just for Jakarta EE 9 support. As we know, there will
> > be
> > > no
> > > > > API
> > > > > > (functional) change, only package renaming. But, I want to
> > emphasize
> > > > that
> > > > > > with such turning points, it is so logical to integrate official
> > > > Jakarta
> > > > > > CDI API into our master (removing the geronimo-cdi), and release
> > our
> > > > new
> > > > > > 3.x version and let the public know that OWB supports official
> CDI
> > > API
> > > > > > beginning with 3.x release. Yeah, shading is an option for
> package
> > > > > renaming
> > > > > > but think long term. Also, I am really against the shading. It
> > really
> > > > > > disturbs the users which depend on OWB implementation. For
> example,
> > > > > > currently Glassfish supports Weld integration but one can also
> > > > implement
> > > > > > OWB to replace Weld in Glassfish. Therefore, instead of using the
> > > > shaded
> > > > > > version, it is really important to have the full Jakarta EE CDI
> API
> > > in
> > > > > our
> > > > > > poms. You will still have javax.* dependency in ur POMs even if
> > > doing a
> > > > > > shade. This is not good idea to still maintain javax.* in our POM
> > > > files.
> > > > > >
> > > > > > What are other opinions before formal voting?
> > > > > > Regards.
> > > > > > Gurkan
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> > > > rmannibucau@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> > > cgurkanerdogdu@gmail.com
> > > > >
> > > > > a
> > > > > >> écrit :
> > > > > >>
> > > > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on
> > > > master.
> > > > > >>>
> > > > > >>
> > > > > >> Tomcat works with branches since years without any issue.
> > > > > >> All projects we tried to use branches we abandoned branches just
> > > after
> > > > > >> having done them.
> > > > > >> It is fine if the old branch is no more used but here we know we
> > > will
> > > > > >> maintain javax branch more than jakarta one for some time so I
> > think
> > > > we
> > > > > >> should avoid it while it is not justified or one of the 2
> branches
> > > > > (javax)
> > > > > >> is "almost dead".
> > > > > >>
> > > > > >>
> > > > > >>> sorry but not understand the resistance on this? will you
> always
> > > > shade
> > > > > ?
> > > > > >>>
> > > > > >>
> > > > > >> As mentionned, until API needs changes we can't easily handle -
> > > today
> > > > > there
> > > > > >> is no change.
> > > > > >>
> > > > > >>
> > > > > >>> creating the new master and maintain the 2.x branch, is the
> best
> > > > > logical
> > > > > >>> way. there will be no javax.* any more. Tomcat maintains 3
> > > branches
> > > > > and
> > > > > >> 1
> > > > > >>> master. only maintains 1 branch and 1 master is totally fine.
> > > > > >>>
> > > > > >>
> > > > > >> Fact there will be no more javax is useless IMHO, only question
> we
> > > > > should
> > > > > >> care about is "do we have javax users?" and should we work on
> > javax
> > > > > branch
> > > > > >> enough to care about having 2 duplicate branches. Answer is
> > > obviously
> > > > > yes
> > > > > >> and more than jakarta users today, therefore I think for some
> > months
> > > > > (maybe
> > > > > >> a few years) we should stick to javax as our primary branch and
> > > ensure
> > > > > the
> > > > > >> alignments and bugfixes can trivially - == without any action
> from
> > > dev
> > > > > - be
> > > > > >> ported. It is what we have today.
> > > > > >>
> > > > > >>
> > > > > >>>
> > > > > >>> I will propose a vote shortly to decide on to create a master
> > with
> > > > 3.x
> > > > > >> with
> > > > > >>> fully support of jakarta with a normal pom dependency with
> > jakarta
> > > > api.
> > > > > >>>
> > > > > >>
> > > > > >> Note we shouldn't depend on jakarta/javax api anyway (neither as
> > > > groupId
> > > > > >> nor as transitive dep so this change must stay a noop for
> > > consumers).
> > > > > >> I would also appreciate if you do a vote if you can point out
> the
> > > > > breaking
> > > > > >> changes - except the package renaming - justifying to fork
> ourself
> > > and
> > > > > what
> > > > > >> does not work with current solution, can ease the decision/vote.
> > > > > >> Today using jakarta/EE9 API is quite easy (
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > > > >> ).
> > > > > >> We should absolutely enhance the pom experience though but it is
> > > > > trivial to
> > > > > >> do at maven level - I was envisionning to do it in shade plugin
> to
> > > be
> > > > > more
> > > > > >> precise.
> > > > > >>
> > > > > >> To try to rephrase/clarify my questionning today: you ask for
> > > jakarta
> > > > > >> support, we already have it in a dev and project efficient way
> so
> > > why
> > > > > >> should we change since I don't hink there is anything new - once
> > > again
> > > > > if
> > > > > >> API starts to fully break discussion is different but github
> > doesnt
> > > > > reflect
> > > > > >> that?
> > > > > >>
> > > > > >>
> > > > > >>>
> > > > > >>> Regs
> > > > > >>> Gurkan
> > > > > >>>
> > > > > >>>
> > > > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> Today we don't need, tomorrow I don't know but while API does
> > not
> > > > > >> change
> > > > > >>>> (except the package) we shouldn't fork ourself IMHO (cause it
> is
> > > > what
> > > > > >> you
> > > > > >>>> propose as a consequence).
> > > > > >>>> If it becomes necessary let's do it but my vote is to stay
> lazy
> > on
> > > > > >> that.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> side note for G API discussion belongs to dev@G but it is
> less
> > an
> > > > > >> issue
> > > > > >>> to
> > > > > >>>> fork from now since we rarely update the API, the side note
> here
> > > is
> > > > > >> that
> > > > > >>>> CDI SE is already fully runnable on ASF stack with jakarta
> > package
> > > > > >> since
> > > > > >>>> some weeks or months, we did all the needed releases.
> > > > > >>>>
> > > > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > > > > >>>> andraschko.thomas@gmail.com>
> > > > > >>>> a écrit :
> > > > > >>>>
> > > > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our
> build.
> > > > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
> > > > > >>>>>
> > > > > >>>>> I'm actually also a supporter of doing a hard cut but it's
> not
> > > > > >> required
> > > > > >>>> and
> > > > > >>>>> we can do it for EE 10.
> > > > > >>>>>
> > > > > >>>>> <
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > > >>>>>>
> > > > > >>>>> Virenfrei.
> > > > > >>>>> www.avast.com
> > > > > >>>>> <
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > > >>>>>>
> > > > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > > >>>>>
> > > > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> > > > > >>>>> cgurkanerdogdu@gmail.com>:
> > > > > >>>>>
> > > > > >>>>>> We need to maintain two branches
> > > > > >>>>>>
> > > > > >>>>>> EE 8 for javax.* package 2.x branch
> > > > > >>>>>> EE 9 for jakarta.* package 3.x master
> > > > > >>>>>>
> > > > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> > > > > >> rmannibucau@gmail.com
> > > > > >>>>
> > > > > >>>>>> wrote:
> > > > > >>>>>>
> > > > > >>>>>>> Hi,
> > > > > >>>>>>>
> > > > > >>>>>>> I'll probably restate my position on that: if EE 9 brings
> > > > > >>>>> significatively
> > > > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but
> I
> > > can
> > > > > >>> have
> > > > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can
> stay
> > as
> > > > > >> we
> > > > > >>>> are
> > > > > >>>>> I
> > > > > >>>>>>> think avoiding to maintain two branches we can't merge
> > > regularly.
> > > > > >>>>>>>
> > > > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > > > > >>>> cgurkanerdogdu@gmail.com>
> > > > > >>>>> a
> > > > > >>>>>>> écrit :
> > > > > >>>>>>>
> > > > > >>>>>>>> Hi
> > > > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
> > > > > >> support
> > > > > >>>>>> upcoming
> > > > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> > > > > >>>>>>>>
> > > > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of
> using
> > > the
> > > > > >>>>> Apache
> > > > > >>>>>>>> based api.
> > > > > >>>>>>>> Regards
> > > > > >>>>>>>> Gurkan
> > > > > >>>>>>>>
> > > > > >>>>>>>> --
> > > > > >>>>>>>> Gurkan Erdogdu
> > > > > >>>>>>>> http://gurkanerdogdu.blogspot.com
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>> --
> > > > > >>>>>> Gurkan Erdogdu
> > > > > >>>>>> http://gurkanerdogdu.blogspot.com
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>> --
> > > > > >>> Gurkan Erdogdu
> > > > > >>> http://gurkanerdogdu.blogspot.com
> > > > > >>>
> > > > > >>
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Gurkan Erdogdu
> > > > > > http://gurkanerdogdu.blogspot.com
> > > > >
> > > > >
> > > >
> > > > --
> > > > Gurkan Erdogdu
> > > > http://gurkanerdogdu.blogspot.com
> > > >
> > >
> >
> >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu <cg...@gmail.com> a
écrit :
> >
> > So to conclude on this point not belonging to OWB, we still need our fork
> > and eclipse always answered saying "yes we want OSGi [but we don't really
> > know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> > work on that factually so OSGi is done at minimal cost.
>
> OK thanks for the clarification. I am not an OSGI expert.
>
> Ok Gurkan, let's be concrete, do you - you as you personally - accept and
> > commit yourself to port any commit to one of the two branches to the
> other
> > for all the time the project is at apache?
> > if so fine, if not -1 to create us unneeded (+ still unjustified by
> facts)
> > work.
>
> :=)
> Hey, I'm just proposing what I think about. If nobody cares about it or is
> not beneficial, it is ok, and also there is no need to VOTE (This is why
> I'd like to get more opinions on it).
It is fine, just wanted to emphasis the consequence and what it means for
the project.
But look at Weld, they did the
> update, https://github.com/weld and full of updating their pom to use
> jakarta.*
>
They also impled the bda differently than us making it only usable for
single bda apps and created arc@quarkus which violates that, so not sure we
should copy what others do. I tend to prefer to add thinking on top of that
in the context of our project which is diff than the RI (by design and by
workforce).
> Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
> geronimo-...specs which depend on javax.*. Today or tomorrow, we will
> eventually move to jakarta.* namespace. Instead of working with such
> shading plugin stuff as a workaround, I just offer to take the master to
> jakarta.* and update all OWB modules' dependency from javax.* to jakarta.*
> official APIS. This is not related to who will maintain the branches. You
> know that ASF works as a voluntary based approach. You can not push anybody
> to work on anything as in commercial companies.
>
I can agree that in one year we reverse the pattern, shade becoming javax.
But since we cant enforce anyone to do the sync between branches and due to
past years contributions stats, we must not go that way IMHO, it would
either make us expose 2 bad branches or kill our resources for no user
gains. Indeed that is my opinion but from the stats i have today it is my
conclusion.
> Also, regarding the cost and energy you mention to maintain the branch, via
> Geronimo specs, you will need to update all of the Geronimo Specs and
> maintain them. I think this is not rational because now, jakarta.* official
> API license is EPL and Apache friendly. Why do I need to maintain for
> example Geronimo EL?
>
Please discuss it on G, it does not impact OWB - and btw this is not what
had been said ;).
> Regards.
> Gurkan
>
>
>
>
>
> On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cg...@gmail.com> a
> > écrit :
> >
> > > Hi David
> > >
> > > I’m not sure exactly how it impacts this decision, but IIUC the
> geronimo
> > > > cdi spec jar is rather essential for some uses as it has OSGI support
> > > > whereas IIUC the eclipse/jakarta one doesn’t.
> > > >
> > > No, it is not correct. It has OSGI support. GlassFish is an OSGI based
> > > server.You can grap the code from https://github.com/eclipse-ee4j/cdi
> > and
> > > build. It has OSGI enabled MANIFEST.MF file.
> > >
> >
> > Not, it is not correct Gurkan ;).
> > jakarta does NOT support OSGi properly, it does it the old way and break
> > several rules. For instance last CDI spec jar contains:
> >
> > Manifest-Version: 1.0
> > Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
> > r Java)
> > Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
> > Bundle-SymbolicName: jakarta.enterprise.cdi-api
> > Built-By: default
> > Bnd-LastModified: 1590678420932
> > Bundle-ManifestVersion: 2
> > Bundle-DocURL: https://jboss.org
> > Bundle-Vendor: JBoss by Red Hat, Inc.
> > Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> > 3)",jakarta.interceptor;version="[2.0,3)"
> > Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> > Tool: Bnd-2.4.1.201501161923
> > Originally-Created-By: Apache Maven Bundle Plugin
> > Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> > ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> > nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> > sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> > arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> > rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> > ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> > til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> > ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> > ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> > se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> > arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> > ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> > ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> > .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> > karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> > ise.util",jakarta.enterprise.util;version="3.0"
> > Bundle-Name: CDI APIs
> > Bundle-Version: 3.0.0.M4
> > Build-Jdk-Spec: 1.8
> > Created-By: Apache Maven Bundle Plugin
> > Build-Jdk: 1.8.0_202
> >
> > Where are the osgi.serviceloader and osgi.contract ?
> > This is important and used by OSGi-CDI for example (even if it can be
> > worked around).
> >
> > So to conclude on this point not belonging to OWB, we still need our fork
> > and eclipse always answered saying "yes we want OSGi [but we don't really
> > know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> > work on that factually so OSGi is done at minimal cost.
> >
> >
> > >
> > > Gurkan’s proposal will only add difficulty for developers and probably
> > > > users.
> > > >
> > > What is the difficulty? The change will only affect maintaining the
> > javax.*
> > > branch and fully renamed jakarta.* dependencies in master.
> > >
> >
> > Ok Gurkan, let's be concrete, do you - you as you personally - accept and
> > commit yourself to port any commit to one of the two branches to the
> other
> > for all the time the project is at apache?
> > if so fine, if not -1 to create us unneeded (+ still unjustified by
> facts)
> > work.
> >
> >
> > >
> > > Regards.
> > > Gurkan
> > >
> > > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <da...@gmail.com>
> > > wrote:
> > >
> > > > I’m not sure exactly how it impacts this decision, but IIUC the
> > geronimo
> > > > cdi spec jar is rather essential for some uses as it has OSGI support
> > > > whereas IIUC the eclipse/jakarta one doesn’t.
> > > >
> > > > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT
> > > Gurkan’s
> > > > proposal will only add difficulty for developers and probably users.
> > > > Although I haven’t been active here for years I might even vote.
> > > >
> > > > thanks
> > > > David Jencks
> > > >
> > > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
> > cgurkanerdogdu@gmail.com>
> > > > wrote:
> > > > >
> > > > >>
> > > > >> Tomcat works with branches since years without any issue.
> > > > >> All projects we tried to use branches we abandoned branches just
> > after
> > > > >> having done them.
> > > > >> It is fine if the old branch is no more used but here we know we
> > will
> > > > >> maintain javax branch more than jakarta one for some time so I
> think
> > > we
> > > > >> should avoid it while it is not justified or one of the 2 branches
> > > > (javax)
> > > > >> is "almost dead".
> > > > >
> > > > > Working with branches always happens in all open source projects.
> > And
> > > > > there are times when it is logical to create the branch. Jakarta
> EE 9
> > > API
> > > > > migration is the best time to create such a branch. Eventually, we
> > will
> > > > > create such a branch in Jakarta EE 10.
> > > > >
> > > > > Fact there will be no more javax is useless IMHO, only question we
> > > should
> > > > >> care about is "do we have javax users?" and should we work on
> javax
> > > > branch
> > > > >> enough to care about having 2 duplicate branches. Answer is
> > obviously
> > > > yes
> > > > >> and more than jakarta users today, therefore I think for some
> months
> > > > (maybe
> > > > >> a few years) we should stick to javax as our primary branch and
> > ensure
> > > > the
> > > > >> alignments and bugfixes can trivially - == without any action from
> > dev
> > > > - be
> > > > >> ported. It is what we have today.
> > > > >>
> > > > > What could be more natural than maintaining branches (with
> > backporting
> > > > from
> > > > > master only if necessary). With Jakarta EE 10, we will eventually
> > > create
> > > > > the branch for supporting the EE 8. Also, for the release
> versioning,
> > > it
> > > > is
> > > > > nice to have a 3.x release. The community will notice that 3.x is
> the
> > > > > starting point of Jakarta EE support. Will you release 2.x with the
> > > > > intention of supporting Jakarta EE 9? I am personally not positive
> on
> > > > this.
> > > > > I think, 3.x release will also get more interest even if the
> > > > functionality
> > > > > and API stay the same. We can prepare the press release for it.
> > > > >
> > > > > Note we shouldn't depend on jakarta/javax api anyway (neither as
> > > groupId
> > > > >> nor as transitive dep so this change must stay a noop for
> > consumers).
> > > > >>
> > > > > What is the problem of depending on the official Jakarta EE CDI
> API?
> > It
> > > > is
> > > > > an Apache friendly license. Instead of maintaining the Geronimo CDI
> > API
> > > > > internally, it is more logical to use Jakarta EE official CDI API
> and
> > > > > maintain this API with EE4J community.
> > > > >
> > > > > would also appreciate if you do a vote if you can point out the
> > > breaking
> > > > >> changes - except the package renaming - justifying to fork ourself
> > and
> > > > what
> > > > >> does not work with current solution, can ease the decision/vote.
> > > > >> Today using jakarta/EE9 API is quite easy (
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > > >> ).
> > > > >> We should absolutely enhance the pom experience though but it is
> > > > trivial to
> > > > >> do at maven level - I was envisionning to do it in shade plugin to
> > be
> > > > more
> > > > >> precise.
> > > > >>
> > > > > I know that there will be no functional change. But, I am also
> > against
> > > > > shading for jakarta.*. If there will be no change on Jakarta EE 10,
> > > will
> > > > we
> > > > > continue to shade? What happens when there will be a change in
> EJB,
> > > JMS
> > > > > etc specifications but no change in CDI in Jakarta EE 10? Also,
> > VOTING
> > > is
> > > > > the natural thing to do for the community decision. If the
> community
> > > > would
> > > > > like to keep it as it is via shading, it is fine.
> > > > >
> > > > >>
> > > > >> To try to rephrase/clarify my questionning today: you ask for
> > jakarta
> > > > >> support, we already have it in a dev and project efficient way so
> > why
> > > > >> should we change since I don't hink there is anything new - once
> > again
> > > > if
> > > > >> API starts to fully break discussion is different but github
> doesnt
> > > > reflect
> > > > >> that?
> > > > >>
> > > > > This is not just for Jakarta EE 9 support. As we know, there will
> be
> > no
> > > > API
> > > > > (functional) change, only package renaming. But, I want to
> emphasize
> > > that
> > > > > with such turning points, it is so logical to integrate official
> > > Jakarta
> > > > > CDI API into our master (removing the geronimo-cdi), and release
> our
> > > new
> > > > > 3.x version and let the public know that OWB supports official CDI
> > API
> > > > > beginning with 3.x release. Yeah, shading is an option for package
> > > > renaming
> > > > > but think long term. Also, I am really against the shading. It
> really
> > > > > disturbs the users which depend on OWB implementation. For example,
> > > > > currently Glassfish supports Weld integration but one can also
> > > implement
> > > > > OWB to replace Weld in Glassfish. Therefore, instead of using the
> > > shaded
> > > > > version, it is really important to have the full Jakarta EE CDI API
> > in
> > > > our
> > > > > poms. You will still have javax.* dependency in ur POMs even if
> > doing a
> > > > > shade. This is not good idea to still maintain javax.* in our POM
> > > files.
> > > > >
> > > > > What are other opinions before formal voting?
> > > > > Regards.
> > > > > Gurkan
> > > > >
> > > > >
> > > > >
> > > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> > cgurkanerdogdu@gmail.com
> > > >
> > > > a
> > > > >> écrit :
> > > > >>
> > > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on
> > > master.
> > > > >>>
> > > > >>
> > > > >> Tomcat works with branches since years without any issue.
> > > > >> All projects we tried to use branches we abandoned branches just
> > after
> > > > >> having done them.
> > > > >> It is fine if the old branch is no more used but here we know we
> > will
> > > > >> maintain javax branch more than jakarta one for some time so I
> think
> > > we
> > > > >> should avoid it while it is not justified or one of the 2 branches
> > > > (javax)
> > > > >> is "almost dead".
> > > > >>
> > > > >>
> > > > >>> sorry but not understand the resistance on this? will you always
> > > shade
> > > > ?
> > > > >>>
> > > > >>
> > > > >> As mentionned, until API needs changes we can't easily handle -
> > today
> > > > there
> > > > >> is no change.
> > > > >>
> > > > >>
> > > > >>> creating the new master and maintain the 2.x branch, is the best
> > > > logical
> > > > >>> way. there will be no javax.* any more. Tomcat maintains 3
> > branches
> > > > and
> > > > >> 1
> > > > >>> master. only maintains 1 branch and 1 master is totally fine.
> > > > >>>
> > > > >>
> > > > >> Fact there will be no more javax is useless IMHO, only question we
> > > > should
> > > > >> care about is "do we have javax users?" and should we work on
> javax
> > > > branch
> > > > >> enough to care about having 2 duplicate branches. Answer is
> > obviously
> > > > yes
> > > > >> and more than jakarta users today, therefore I think for some
> months
> > > > (maybe
> > > > >> a few years) we should stick to javax as our primary branch and
> > ensure
> > > > the
> > > > >> alignments and bugfixes can trivially - == without any action from
> > dev
> > > > - be
> > > > >> ported. It is what we have today.
> > > > >>
> > > > >>
> > > > >>>
> > > > >>> I will propose a vote shortly to decide on to create a master
> with
> > > 3.x
> > > > >> with
> > > > >>> fully support of jakarta with a normal pom dependency with
> jakarta
> > > api.
> > > > >>>
> > > > >>
> > > > >> Note we shouldn't depend on jakarta/javax api anyway (neither as
> > > groupId
> > > > >> nor as transitive dep so this change must stay a noop for
> > consumers).
> > > > >> I would also appreciate if you do a vote if you can point out the
> > > > breaking
> > > > >> changes - except the package renaming - justifying to fork ourself
> > and
> > > > what
> > > > >> does not work with current solution, can ease the decision/vote.
> > > > >> Today using jakarta/EE9 API is quite easy (
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > > >> ).
> > > > >> We should absolutely enhance the pom experience though but it is
> > > > trivial to
> > > > >> do at maven level - I was envisionning to do it in shade plugin to
> > be
> > > > more
> > > > >> precise.
> > > > >>
> > > > >> To try to rephrase/clarify my questionning today: you ask for
> > jakarta
> > > > >> support, we already have it in a dev and project efficient way so
> > why
> > > > >> should we change since I don't hink there is anything new - once
> > again
> > > > if
> > > > >> API starts to fully break discussion is different but github
> doesnt
> > > > reflect
> > > > >> that?
> > > > >>
> > > > >>
> > > > >>>
> > > > >>> Regs
> > > > >>> Gurkan
> > > > >>>
> > > > >>>
> > > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > > >>> wrote:
> > > > >>>
> > > > >>>> Today we don't need, tomorrow I don't know but while API does
> not
> > > > >> change
> > > > >>>> (except the package) we shouldn't fork ourself IMHO (cause it is
> > > what
> > > > >> you
> > > > >>>> propose as a consequence).
> > > > >>>> If it becomes necessary let's do it but my vote is to stay lazy
> on
> > > > >> that.
> > > > >>>>
> > > > >>>>
> > > > >>>> side note for G API discussion belongs to dev@G but it is less
> an
> > > > >> issue
> > > > >>> to
> > > > >>>> fork from now since we rarely update the API, the side note here
> > is
> > > > >> that
> > > > >>>> CDI SE is already fully runnable on ASF stack with jakarta
> package
> > > > >> since
> > > > >>>> some weeks or months, we did all the needed releases.
> > > > >>>>
> > > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > > > >>>> andraschko.thomas@gmail.com>
> > > > >>>> a écrit :
> > > > >>>>
> > > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our build.
> > > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
> > > > >>>>>
> > > > >>>>> I'm actually also a supporter of doing a hard cut but it's not
> > > > >> required
> > > > >>>> and
> > > > >>>>> we can do it for EE 10.
> > > > >>>>>
> > > > >>>>> <
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > >>>>>>
> > > > >>>>> Virenfrei.
> > > > >>>>> www.avast.com
> > > > >>>>> <
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > >>>>>>
> > > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > >>>>>
> > > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> > > > >>>>> cgurkanerdogdu@gmail.com>:
> > > > >>>>>
> > > > >>>>>> We need to maintain two branches
> > > > >>>>>>
> > > > >>>>>> EE 8 for javax.* package 2.x branch
> > > > >>>>>> EE 9 for jakarta.* package 3.x master
> > > > >>>>>>
> > > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> > > > >> rmannibucau@gmail.com
> > > > >>>>
> > > > >>>>>> wrote:
> > > > >>>>>>
> > > > >>>>>>> Hi,
> > > > >>>>>>>
> > > > >>>>>>> I'll probably restate my position on that: if EE 9 brings
> > > > >>>>> significatively
> > > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but I
> > can
> > > > >>> have
> > > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can stay
> as
> > > > >> we
> > > > >>>> are
> > > > >>>>> I
> > > > >>>>>>> think avoiding to maintain two branches we can't merge
> > regularly.
> > > > >>>>>>>
> > > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > > > >>>> cgurkanerdogdu@gmail.com>
> > > > >>>>> a
> > > > >>>>>>> écrit :
> > > > >>>>>>>
> > > > >>>>>>>> Hi
> > > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
> > > > >> support
> > > > >>>>>> upcoming
> > > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> > > > >>>>>>>>
> > > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of using
> > the
> > > > >>>>> Apache
> > > > >>>>>>>> based api.
> > > > >>>>>>>> Regards
> > > > >>>>>>>> Gurkan
> > > > >>>>>>>>
> > > > >>>>>>>> --
> > > > >>>>>>>> Gurkan Erdogdu
> > > > >>>>>>>> http://gurkanerdogdu.blogspot.com
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>> --
> > > > >>>>>> Gurkan Erdogdu
> > > > >>>>>> http://gurkanerdogdu.blogspot.com
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>> --
> > > > >>> Gurkan Erdogdu
> > > > >>> http://gurkanerdogdu.blogspot.com
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Gurkan Erdogdu
> > > > > http://gurkanerdogdu.blogspot.com
> > > >
> > > >
> > >
> > > --
> > > Gurkan Erdogdu
> > > http://gurkanerdogdu.blogspot.com
> > >
> >
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
Re: Jakarta EE 9 Support
Posted by Gurkan Erdogdu <cg...@gmail.com>.
>
> So to conclude on this point not belonging to OWB, we still need our fork
> and eclipse always answered saying "yes we want OSGi [but we don't really
> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> work on that factually so OSGi is done at minimal cost.
OK thanks for the clarification. I am not an OSGI expert.
Ok Gurkan, let's be concrete, do you - you as you personally - accept and
> commit yourself to port any commit to one of the two branches to the other
> for all the time the project is at apache?
> if so fine, if not -1 to create us unneeded (+ still unjustified by facts)
> work.
:=)
Hey, I'm just proposing what I think about. If nobody cares about it or is
not beneficial, it is ok, and also there is no need to VOTE (This is why
I'd like to get more opinions on it). But look at Weld, they did the
update, https://github.com/weld and full of updating their pom to use
jakarta.*
Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use
geronimo-...specs which depend on javax.*. Today or tomorrow, we will
eventually move to jakarta.* namespace. Instead of working with such
shading plugin stuff as a workaround, I just offer to take the master to
jakarta.* and update all OWB modules' dependency from javax.* to jakarta.*
official APIS. This is not related to who will maintain the branches. You
know that ASF works as a voluntary based approach. You can not push anybody
to work on anything as in commercial companies.
Also, regarding the cost and energy you mention to maintain the branch, via
Geronimo specs, you will need to update all of the Geronimo Specs and
maintain them. I think this is not rational because now, jakarta.* official
API license is EPL and Apache friendly. Why do I need to maintain for
example Geronimo EL?
Regards.
Gurkan
On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cg...@gmail.com> a
> écrit :
>
> > Hi David
> >
> > I’m not sure exactly how it impacts this decision, but IIUC the geronimo
> > > cdi spec jar is rather essential for some uses as it has OSGI support
> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > >
> > No, it is not correct. It has OSGI support. GlassFish is an OSGI based
> > server.You can grap the code from https://github.com/eclipse-ee4j/cdi
> and
> > build. It has OSGI enabled MANIFEST.MF file.
> >
>
> Not, it is not correct Gurkan ;).
> jakarta does NOT support OSGi properly, it does it the old way and break
> several rules. For instance last CDI spec jar contains:
>
> Manifest-Version: 1.0
> Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
> r Java)
> Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
> Bundle-SymbolicName: jakarta.enterprise.cdi-api
> Built-By: default
> Bnd-LastModified: 1590678420932
> Bundle-ManifestVersion: 2
> Bundle-DocURL: https://jboss.org
> Bundle-Vendor: JBoss by Red Hat, Inc.
> Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
> 3)",jakarta.interceptor;version="[2.0,3)"
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Tool: Bnd-2.4.1.201501161923
> Originally-Created-By: Apache Maven Bundle Plugin
> Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
> ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
> nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
> sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
> arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
> rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
> ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
> til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
> ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
> ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
> se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
> arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
> ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
> ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
> .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
> karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
> ise.util",jakarta.enterprise.util;version="3.0"
> Bundle-Name: CDI APIs
> Bundle-Version: 3.0.0.M4
> Build-Jdk-Spec: 1.8
> Created-By: Apache Maven Bundle Plugin
> Build-Jdk: 1.8.0_202
>
> Where are the osgi.serviceloader and osgi.contract ?
> This is important and used by OSGi-CDI for example (even if it can be
> worked around).
>
> So to conclude on this point not belonging to OWB, we still need our fork
> and eclipse always answered saying "yes we want OSGi [but we don't really
> know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
> work on that factually so OSGi is done at minimal cost.
>
>
> >
> > Gurkan’s proposal will only add difficulty for developers and probably
> > > users.
> > >
> > What is the difficulty? The change will only affect maintaining the
> javax.*
> > branch and fully renamed jakarta.* dependencies in master.
> >
>
> Ok Gurkan, let's be concrete, do you - you as you personally - accept and
> commit yourself to port any commit to one of the two branches to the other
> for all the time the project is at apache?
> if so fine, if not -1 to create us unneeded (+ still unjustified by facts)
> work.
>
>
> >
> > Regards.
> > Gurkan
> >
> > On Sun, Jun 7, 2020 at 8:58 PM David Jencks <da...@gmail.com>
> > wrote:
> >
> > > I’m not sure exactly how it impacts this decision, but IIUC the
> geronimo
> > > cdi spec jar is rather essential for some uses as it has OSGI support
> > > whereas IIUC the eclipse/jakarta one doesn’t.
> > >
> > > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT
> > Gurkan’s
> > > proposal will only add difficulty for developers and probably users.
> > > Although I haven’t been active here for years I might even vote.
> > >
> > > thanks
> > > David Jencks
> > >
> > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <
> cgurkanerdogdu@gmail.com>
> > > wrote:
> > > >
> > > >>
> > > >> Tomcat works with branches since years without any issue.
> > > >> All projects we tried to use branches we abandoned branches just
> after
> > > >> having done them.
> > > >> It is fine if the old branch is no more used but here we know we
> will
> > > >> maintain javax branch more than jakarta one for some time so I think
> > we
> > > >> should avoid it while it is not justified or one of the 2 branches
> > > (javax)
> > > >> is "almost dead".
> > > >
> > > > Working with branches always happens in all open source projects.
> And
> > > > there are times when it is logical to create the branch. Jakarta EE 9
> > API
> > > > migration is the best time to create such a branch. Eventually, we
> will
> > > > create such a branch in Jakarta EE 10.
> > > >
> > > > Fact there will be no more javax is useless IMHO, only question we
> > should
> > > >> care about is "do we have javax users?" and should we work on javax
> > > branch
> > > >> enough to care about having 2 duplicate branches. Answer is
> obviously
> > > yes
> > > >> and more than jakarta users today, therefore I think for some months
> > > (maybe
> > > >> a few years) we should stick to javax as our primary branch and
> ensure
> > > the
> > > >> alignments and bugfixes can trivially - == without any action from
> dev
> > > - be
> > > >> ported. It is what we have today.
> > > >>
> > > > What could be more natural than maintaining branches (with
> backporting
> > > from
> > > > master only if necessary). With Jakarta EE 10, we will eventually
> > create
> > > > the branch for supporting the EE 8. Also, for the release versioning,
> > it
> > > is
> > > > nice to have a 3.x release. The community will notice that 3.x is the
> > > > starting point of Jakarta EE support. Will you release 2.x with the
> > > > intention of supporting Jakarta EE 9? I am personally not positive on
> > > this.
> > > > I think, 3.x release will also get more interest even if the
> > > functionality
> > > > and API stay the same. We can prepare the press release for it.
> > > >
> > > > Note we shouldn't depend on jakarta/javax api anyway (neither as
> > groupId
> > > >> nor as transitive dep so this change must stay a noop for
> consumers).
> > > >>
> > > > What is the problem of depending on the official Jakarta EE CDI API?
> It
> > > is
> > > > an Apache friendly license. Instead of maintaining the Geronimo CDI
> API
> > > > internally, it is more logical to use Jakarta EE official CDI API and
> > > > maintain this API with EE4J community.
> > > >
> > > > would also appreciate if you do a vote if you can point out the
> > breaking
> > > >> changes - except the package renaming - justifying to fork ourself
> and
> > > what
> > > >> does not work with current solution, can ease the decision/vote.
> > > >> Today using jakarta/EE9 API is quite easy (
> > > >>
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > >> ).
> > > >> We should absolutely enhance the pom experience though but it is
> > > trivial to
> > > >> do at maven level - I was envisionning to do it in shade plugin to
> be
> > > more
> > > >> precise.
> > > >>
> > > > I know that there will be no functional change. But, I am also
> against
> > > > shading for jakarta.*. If there will be no change on Jakarta EE 10,
> > will
> > > we
> > > > continue to shade? What happens when there will be a change in EJB,
> > JMS
> > > > etc specifications but no change in CDI in Jakarta EE 10? Also,
> VOTING
> > is
> > > > the natural thing to do for the community decision. If the community
> > > would
> > > > like to keep it as it is via shading, it is fine.
> > > >
> > > >>
> > > >> To try to rephrase/clarify my questionning today: you ask for
> jakarta
> > > >> support, we already have it in a dev and project efficient way so
> why
> > > >> should we change since I don't hink there is anything new - once
> again
> > > if
> > > >> API starts to fully break discussion is different but github doesnt
> > > reflect
> > > >> that?
> > > >>
> > > > This is not just for Jakarta EE 9 support. As we know, there will be
> no
> > > API
> > > > (functional) change, only package renaming. But, I want to emphasize
> > that
> > > > with such turning points, it is so logical to integrate official
> > Jakarta
> > > > CDI API into our master (removing the geronimo-cdi), and release our
> > new
> > > > 3.x version and let the public know that OWB supports official CDI
> API
> > > > beginning with 3.x release. Yeah, shading is an option for package
> > > renaming
> > > > but think long term. Also, I am really against the shading. It really
> > > > disturbs the users which depend on OWB implementation. For example,
> > > > currently Glassfish supports Weld integration but one can also
> > implement
> > > > OWB to replace Weld in Glassfish. Therefore, instead of using the
> > shaded
> > > > version, it is really important to have the full Jakarta EE CDI API
> in
> > > our
> > > > poms. You will still have javax.* dependency in ur POMs even if
> doing a
> > > > shade. This is not good idea to still maintain javax.* in our POM
> > files.
> > > >
> > > > What are other opinions before formal voting?
> > > > Regards.
> > > > Gurkan
> > > >
> > > >
> > > >
> > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> cgurkanerdogdu@gmail.com
> > >
> > > a
> > > >> écrit :
> > > >>
> > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on
> > master.
> > > >>>
> > > >>
> > > >> Tomcat works with branches since years without any issue.
> > > >> All projects we tried to use branches we abandoned branches just
> after
> > > >> having done them.
> > > >> It is fine if the old branch is no more used but here we know we
> will
> > > >> maintain javax branch more than jakarta one for some time so I think
> > we
> > > >> should avoid it while it is not justified or one of the 2 branches
> > > (javax)
> > > >> is "almost dead".
> > > >>
> > > >>
> > > >>> sorry but not understand the resistance on this? will you always
> > shade
> > > ?
> > > >>>
> > > >>
> > > >> As mentionned, until API needs changes we can't easily handle -
> today
> > > there
> > > >> is no change.
> > > >>
> > > >>
> > > >>> creating the new master and maintain the 2.x branch, is the best
> > > logical
> > > >>> way. there will be no javax.* any more. Tomcat maintains 3
> branches
> > > and
> > > >> 1
> > > >>> master. only maintains 1 branch and 1 master is totally fine.
> > > >>>
> > > >>
> > > >> Fact there will be no more javax is useless IMHO, only question we
> > > should
> > > >> care about is "do we have javax users?" and should we work on javax
> > > branch
> > > >> enough to care about having 2 duplicate branches. Answer is
> obviously
> > > yes
> > > >> and more than jakarta users today, therefore I think for some months
> > > (maybe
> > > >> a few years) we should stick to javax as our primary branch and
> ensure
> > > the
> > > >> alignments and bugfixes can trivially - == without any action from
> dev
> > > - be
> > > >> ported. It is what we have today.
> > > >>
> > > >>
> > > >>>
> > > >>> I will propose a vote shortly to decide on to create a master with
> > 3.x
> > > >> with
> > > >>> fully support of jakarta with a normal pom dependency with jakarta
> > api.
> > > >>>
> > > >>
> > > >> Note we shouldn't depend on jakarta/javax api anyway (neither as
> > groupId
> > > >> nor as transitive dep so this change must stay a noop for
> consumers).
> > > >> I would also appreciate if you do a vote if you can point out the
> > > breaking
> > > >> changes - except the package renaming - justifying to fork ourself
> and
> > > what
> > > >> does not work with current solution, can ease the decision/vote.
> > > >> Today using jakarta/EE9 API is quite easy (
> > > >>
> > >
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > > >> ).
> > > >> We should absolutely enhance the pom experience though but it is
> > > trivial to
> > > >> do at maven level - I was envisionning to do it in shade plugin to
> be
> > > more
> > > >> precise.
> > > >>
> > > >> To try to rephrase/clarify my questionning today: you ask for
> jakarta
> > > >> support, we already have it in a dev and project efficient way so
> why
> > > >> should we change since I don't hink there is anything new - once
> again
> > > if
> > > >> API starts to fully break discussion is different but github doesnt
> > > reflect
> > > >> that?
> > > >>
> > > >>
> > > >>>
> > > >>> Regs
> > > >>> Gurkan
> > > >>>
> > > >>>
> > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > > >>> wrote:
> > > >>>
> > > >>>> Today we don't need, tomorrow I don't know but while API does not
> > > >> change
> > > >>>> (except the package) we shouldn't fork ourself IMHO (cause it is
> > what
> > > >> you
> > > >>>> propose as a consequence).
> > > >>>> If it becomes necessary let's do it but my vote is to stay lazy on
> > > >> that.
> > > >>>>
> > > >>>>
> > > >>>> side note for G API discussion belongs to dev@G but it is less an
> > > >> issue
> > > >>> to
> > > >>>> fork from now since we rarely update the API, the side note here
> is
> > > >> that
> > > >>>> CDI SE is already fully runnable on ASF stack with jakarta package
> > > >> since
> > > >>>> some weeks or months, we did all the needed releases.
> > > >>>>
> > > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > > >>>> andraschko.thomas@gmail.com>
> > > >>>> a écrit :
> > > >>>>
> > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our build.
> > > >>>>> As EE9 just changes the namespace, it's perfectly fine.
> > > >>>>>
> > > >>>>> I'm actually also a supporter of doing a hard cut but it's not
> > > >> required
> > > >>>> and
> > > >>>>> we can do it for EE 10.
> > > >>>>>
> > > >>>>> <
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > >>>>>>
> > > >>>>> Virenfrei.
> > > >>>>> www.avast.com
> > > >>>>> <
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > >>>>>>
> > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > >>>>>
> > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> > > >>>>> cgurkanerdogdu@gmail.com>:
> > > >>>>>
> > > >>>>>> We need to maintain two branches
> > > >>>>>>
> > > >>>>>> EE 8 for javax.* package 2.x branch
> > > >>>>>> EE 9 for jakarta.* package 3.x master
> > > >>>>>>
> > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> > > >> rmannibucau@gmail.com
> > > >>>>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Hi,
> > > >>>>>>>
> > > >>>>>>> I'll probably restate my position on that: if EE 9 brings
> > > >>>>> significatively
> > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but I
> can
> > > >>> have
> > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can stay as
> > > >> we
> > > >>>> are
> > > >>>>> I
> > > >>>>>>> think avoiding to maintain two branches we can't merge
> regularly.
> > > >>>>>>>
> > > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > > >>>> cgurkanerdogdu@gmail.com>
> > > >>>>> a
> > > >>>>>>> écrit :
> > > >>>>>>>
> > > >>>>>>>> Hi
> > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
> > > >> support
> > > >>>>>> upcoming
> > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> > > >>>>>>>>
> > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of using
> the
> > > >>>>> Apache
> > > >>>>>>>> based api.
> > > >>>>>>>> Regards
> > > >>>>>>>> Gurkan
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>> Gurkan Erdogdu
> > > >>>>>>>> http://gurkanerdogdu.blogspot.com
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>> --
> > > >>>>>> Gurkan Erdogdu
> > > >>>>>> http://gurkanerdogdu.blogspot.com
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>> --
> > > >>> Gurkan Erdogdu
> > > >>> http://gurkanerdogdu.blogspot.com
> > > >>>
> > > >>
> > > >
> > > >
> > > > --
> > > > Gurkan Erdogdu
> > > > http://gurkanerdogdu.blogspot.com
> > >
> > >
> >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cg...@gmail.com> a
écrit :
> Hi David
>
> I’m not sure exactly how it impacts this decision, but IIUC the geronimo
> > cdi spec jar is rather essential for some uses as it has OSGI support
> > whereas IIUC the eclipse/jakarta one doesn’t.
> >
> No, it is not correct. It has OSGI support. GlassFish is an OSGI based
> server.You can grap the code from https://github.com/eclipse-ee4j/cdi and
> build. It has OSGI enabled MANIFEST.MF file.
>
Not, it is not correct Gurkan ;).
jakarta does NOT support OSGi properly, it does it the old way and break
several rules. For instance last CDI spec jar contains:
Manifest-Version: 1.0
Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo
r Java)
Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt
Bundle-SymbolicName: jakarta.enterprise.cdi-api
Built-By: default
Bnd-LastModified: 1590678420932
Bundle-ManifestVersion: 2
Bundle-DocURL: https://jboss.org
Bundle-Vendor: JBoss by Red Hat, Inc.
Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0,
3)",jakarta.interceptor;version="[2.0,3)"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-2.4.1.201501161923
Originally-Created-By: Apache Maven Bundle Plugin
Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr
ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e
nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver
sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak
arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve
rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject
;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u
til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u
ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje
ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri
se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak
arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar
ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar
ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3
.0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja
karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr
ise.util",jakarta.enterprise.util;version="3.0"
Bundle-Name: CDI APIs
Bundle-Version: 3.0.0.M4
Build-Jdk-Spec: 1.8
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.8.0_202
Where are the osgi.serviceloader and osgi.contract ?
This is important and used by OSGi-CDI for example (even if it can be
worked around).
So to conclude on this point not belonging to OWB, we still need our fork
and eclipse always answered saying "yes we want OSGi [but we don't really
know]" - and I know eclipse+EE has a lot of OSGi experts but they don't
work on that factually so OSGi is done at minimal cost.
>
> Gurkan’s proposal will only add difficulty for developers and probably
> > users.
> >
> What is the difficulty? The change will only affect maintaining the javax.*
> branch and fully renamed jakarta.* dependencies in master.
>
Ok Gurkan, let's be concrete, do you - you as you personally - accept and
commit yourself to port any commit to one of the two branches to the other
for all the time the project is at apache?
if so fine, if not -1 to create us unneeded (+ still unjustified by facts)
work.
>
> Regards.
> Gurkan
>
> On Sun, Jun 7, 2020 at 8:58 PM David Jencks <da...@gmail.com>
> wrote:
>
> > I’m not sure exactly how it impacts this decision, but IIUC the geronimo
> > cdi spec jar is rather essential for some uses as it has OSGI support
> > whereas IIUC the eclipse/jakarta one doesn’t.
> >
> > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT
> Gurkan’s
> > proposal will only add difficulty for developers and probably users.
> > Although I haven’t been active here for years I might even vote.
> >
> > thanks
> > David Jencks
> >
> > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <cg...@gmail.com>
> > wrote:
> > >
> > >>
> > >> Tomcat works with branches since years without any issue.
> > >> All projects we tried to use branches we abandoned branches just after
> > >> having done them.
> > >> It is fine if the old branch is no more used but here we know we will
> > >> maintain javax branch more than jakarta one for some time so I think
> we
> > >> should avoid it while it is not justified or one of the 2 branches
> > (javax)
> > >> is "almost dead".
> > >
> > > Working with branches always happens in all open source projects. And
> > > there are times when it is logical to create the branch. Jakarta EE 9
> API
> > > migration is the best time to create such a branch. Eventually, we will
> > > create such a branch in Jakarta EE 10.
> > >
> > > Fact there will be no more javax is useless IMHO, only question we
> should
> > >> care about is "do we have javax users?" and should we work on javax
> > branch
> > >> enough to care about having 2 duplicate branches. Answer is obviously
> > yes
> > >> and more than jakarta users today, therefore I think for some months
> > (maybe
> > >> a few years) we should stick to javax as our primary branch and ensure
> > the
> > >> alignments and bugfixes can trivially - == without any action from dev
> > - be
> > >> ported. It is what we have today.
> > >>
> > > What could be more natural than maintaining branches (with backporting
> > from
> > > master only if necessary). With Jakarta EE 10, we will eventually
> create
> > > the branch for supporting the EE 8. Also, for the release versioning,
> it
> > is
> > > nice to have a 3.x release. The community will notice that 3.x is the
> > > starting point of Jakarta EE support. Will you release 2.x with the
> > > intention of supporting Jakarta EE 9? I am personally not positive on
> > this.
> > > I think, 3.x release will also get more interest even if the
> > functionality
> > > and API stay the same. We can prepare the press release for it.
> > >
> > > Note we shouldn't depend on jakarta/javax api anyway (neither as
> groupId
> > >> nor as transitive dep so this change must stay a noop for consumers).
> > >>
> > > What is the problem of depending on the official Jakarta EE CDI API? It
> > is
> > > an Apache friendly license. Instead of maintaining the Geronimo CDI API
> > > internally, it is more logical to use Jakarta EE official CDI API and
> > > maintain this API with EE4J community.
> > >
> > > would also appreciate if you do a vote if you can point out the
> breaking
> > >> changes - except the package renaming - justifying to fork ourself and
> > what
> > >> does not work with current solution, can ease the decision/vote.
> > >> Today using jakarta/EE9 API is quite easy (
> > >>
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > >> ).
> > >> We should absolutely enhance the pom experience though but it is
> > trivial to
> > >> do at maven level - I was envisionning to do it in shade plugin to be
> > more
> > >> precise.
> > >>
> > > I know that there will be no functional change. But, I am also against
> > > shading for jakarta.*. If there will be no change on Jakarta EE 10,
> will
> > we
> > > continue to shade? What happens when there will be a change in EJB,
> JMS
> > > etc specifications but no change in CDI in Jakarta EE 10? Also, VOTING
> is
> > > the natural thing to do for the community decision. If the community
> > would
> > > like to keep it as it is via shading, it is fine.
> > >
> > >>
> > >> To try to rephrase/clarify my questionning today: you ask for jakarta
> > >> support, we already have it in a dev and project efficient way so why
> > >> should we change since I don't hink there is anything new - once again
> > if
> > >> API starts to fully break discussion is different but github doesnt
> > reflect
> > >> that?
> > >>
> > > This is not just for Jakarta EE 9 support. As we know, there will be no
> > API
> > > (functional) change, only package renaming. But, I want to emphasize
> that
> > > with such turning points, it is so logical to integrate official
> Jakarta
> > > CDI API into our master (removing the geronimo-cdi), and release our
> new
> > > 3.x version and let the public know that OWB supports official CDI API
> > > beginning with 3.x release. Yeah, shading is an option for package
> > renaming
> > > but think long term. Also, I am really against the shading. It really
> > > disturbs the users which depend on OWB implementation. For example,
> > > currently Glassfish supports Weld integration but one can also
> implement
> > > OWB to replace Weld in Glassfish. Therefore, instead of using the
> shaded
> > > version, it is really important to have the full Jakarta EE CDI API in
> > our
> > > poms. You will still have javax.* dependency in ur POMs even if doing a
> > > shade. This is not good idea to still maintain javax.* in our POM
> files.
> > >
> > > What are other opinions before formal voting?
> > > Regards.
> > > Gurkan
> > >
> > >
> > >
> > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > > wrote:
> > >
> > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <cgurkanerdogdu@gmail.com
> >
> > a
> > >> écrit :
> > >>
> > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on
> master.
> > >>>
> > >>
> > >> Tomcat works with branches since years without any issue.
> > >> All projects we tried to use branches we abandoned branches just after
> > >> having done them.
> > >> It is fine if the old branch is no more used but here we know we will
> > >> maintain javax branch more than jakarta one for some time so I think
> we
> > >> should avoid it while it is not justified or one of the 2 branches
> > (javax)
> > >> is "almost dead".
> > >>
> > >>
> > >>> sorry but not understand the resistance on this? will you always
> shade
> > ?
> > >>>
> > >>
> > >> As mentionned, until API needs changes we can't easily handle - today
> > there
> > >> is no change.
> > >>
> > >>
> > >>> creating the new master and maintain the 2.x branch, is the best
> > logical
> > >>> way. there will be no javax.* any more. Tomcat maintains 3 branches
> > and
> > >> 1
> > >>> master. only maintains 1 branch and 1 master is totally fine.
> > >>>
> > >>
> > >> Fact there will be no more javax is useless IMHO, only question we
> > should
> > >> care about is "do we have javax users?" and should we work on javax
> > branch
> > >> enough to care about having 2 duplicate branches. Answer is obviously
> > yes
> > >> and more than jakarta users today, therefore I think for some months
> > (maybe
> > >> a few years) we should stick to javax as our primary branch and ensure
> > the
> > >> alignments and bugfixes can trivially - == without any action from dev
> > - be
> > >> ported. It is what we have today.
> > >>
> > >>
> > >>>
> > >>> I will propose a vote shortly to decide on to create a master with
> 3.x
> > >> with
> > >>> fully support of jakarta with a normal pom dependency with jakarta
> api.
> > >>>
> > >>
> > >> Note we shouldn't depend on jakarta/javax api anyway (neither as
> groupId
> > >> nor as transitive dep so this change must stay a noop for consumers).
> > >> I would also appreciate if you do a vote if you can point out the
> > breaking
> > >> changes - except the package renaming - justifying to fork ourself and
> > what
> > >> does not work with current solution, can ease the decision/vote.
> > >> Today using jakarta/EE9 API is quite easy (
> > >>
> >
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> > >> ).
> > >> We should absolutely enhance the pom experience though but it is
> > trivial to
> > >> do at maven level - I was envisionning to do it in shade plugin to be
> > more
> > >> precise.
> > >>
> > >> To try to rephrase/clarify my questionning today: you ask for jakarta
> > >> support, we already have it in a dev and project efficient way so why
> > >> should we change since I don't hink there is anything new - once again
> > if
> > >> API starts to fully break discussion is different but github doesnt
> > reflect
> > >> that?
> > >>
> > >>
> > >>>
> > >>> Regs
> > >>> Gurkan
> > >>>
> > >>>
> > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > >>> wrote:
> > >>>
> > >>>> Today we don't need, tomorrow I don't know but while API does not
> > >> change
> > >>>> (except the package) we shouldn't fork ourself IMHO (cause it is
> what
> > >> you
> > >>>> propose as a consequence).
> > >>>> If it becomes necessary let's do it but my vote is to stay lazy on
> > >> that.
> > >>>>
> > >>>>
> > >>>> side note for G API discussion belongs to dev@G but it is less an
> > >> issue
> > >>> to
> > >>>> fork from now since we rarely update the API, the side note here is
> > >> that
> > >>>> CDI SE is already fully runnable on ASF stack with jakarta package
> > >> since
> > >>>> some weeks or months, we did all the needed releases.
> > >>>>
> > >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > >>>> andraschko.thomas@gmail.com>
> > >>>> a écrit :
> > >>>>
> > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our build.
> > >>>>> As EE9 just changes the namespace, it's perfectly fine.
> > >>>>>
> > >>>>> I'm actually also a supporter of doing a hard cut but it's not
> > >> required
> > >>>> and
> > >>>>> we can do it for EE 10.
> > >>>>>
> > >>>>> <
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > >>>>>>
> > >>>>> Virenfrei.
> > >>>>> www.avast.com
> > >>>>> <
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > >>>>>>
> > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >>>>>
> > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> > >>>>> cgurkanerdogdu@gmail.com>:
> > >>>>>
> > >>>>>> We need to maintain two branches
> > >>>>>>
> > >>>>>> EE 8 for javax.* package 2.x branch
> > >>>>>> EE 9 for jakarta.* package 3.x master
> > >>>>>>
> > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> > >> rmannibucau@gmail.com
> > >>>>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>> I'll probably restate my position on that: if EE 9 brings
> > >>>>> significatively
> > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but I can
> > >>> have
> > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can stay as
> > >> we
> > >>>> are
> > >>>>> I
> > >>>>>>> think avoiding to maintain two branches we can't merge regularly.
> > >>>>>>>
> > >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > >>>> cgurkanerdogdu@gmail.com>
> > >>>>> a
> > >>>>>>> écrit :
> > >>>>>>>
> > >>>>>>>> Hi
> > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
> > >> support
> > >>>>>> upcoming
> > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> > >>>>>>>>
> > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of using the
> > >>>>> Apache
> > >>>>>>>> based api.
> > >>>>>>>> Regards
> > >>>>>>>> Gurkan
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Gurkan Erdogdu
> > >>>>>>>> http://gurkanerdogdu.blogspot.com
> > >>>>>>>>
> > >>>>>>>
> > >>>>>> --
> > >>>>>> Gurkan Erdogdu
> > >>>>>> http://gurkanerdogdu.blogspot.com
> > >>>>>>
> > >>>>>
> > >>>>
> > >>> --
> > >>> Gurkan Erdogdu
> > >>> http://gurkanerdogdu.blogspot.com
> > >>>
> > >>
> > >
> > >
> > > --
> > > Gurkan Erdogdu
> > > http://gurkanerdogdu.blogspot.com
> >
> >
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
Re: Jakarta EE 9 Support
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Hi David
I’m not sure exactly how it impacts this decision, but IIUC the geronimo
> cdi spec jar is rather essential for some uses as it has OSGI support
> whereas IIUC the eclipse/jakarta one doesn’t.
>
No, it is not correct. It has OSGI support. GlassFish is an OSGI based
server.You can grap the code from https://github.com/eclipse-ee4j/cdi and
build. It has OSGI enabled MANIFEST.MF file.
Gurkan’s proposal will only add difficulty for developers and probably
> users.
>
What is the difficulty? The change will only affect maintaining the javax.*
branch and fully renamed jakarta.* dependencies in master.
Regards.
Gurkan
On Sun, Jun 7, 2020 at 8:58 PM David Jencks <da...@gmail.com>
wrote:
> I’m not sure exactly how it impacts this decision, but IIUC the geronimo
> cdi spec jar is rather essential for some uses as it has OSGI support
> whereas IIUC the eclipse/jakarta one doesn’t.
>
> Personally I’m afraid I’m totally on Romain’s side so far, AFAICT Gurkan’s
> proposal will only add difficulty for developers and probably users.
> Although I haven’t been active here for years I might even vote.
>
> thanks
> David Jencks
>
> > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <cg...@gmail.com>
> wrote:
> >
> >>
> >> Tomcat works with branches since years without any issue.
> >> All projects we tried to use branches we abandoned branches just after
> >> having done them.
> >> It is fine if the old branch is no more used but here we know we will
> >> maintain javax branch more than jakarta one for some time so I think we
> >> should avoid it while it is not justified or one of the 2 branches
> (javax)
> >> is "almost dead".
> >
> > Working with branches always happens in all open source projects. And
> > there are times when it is logical to create the branch. Jakarta EE 9 API
> > migration is the best time to create such a branch. Eventually, we will
> > create such a branch in Jakarta EE 10.
> >
> > Fact there will be no more javax is useless IMHO, only question we should
> >> care about is "do we have javax users?" and should we work on javax
> branch
> >> enough to care about having 2 duplicate branches. Answer is obviously
> yes
> >> and more than jakarta users today, therefore I think for some months
> (maybe
> >> a few years) we should stick to javax as our primary branch and ensure
> the
> >> alignments and bugfixes can trivially - == without any action from dev
> - be
> >> ported. It is what we have today.
> >>
> > What could be more natural than maintaining branches (with backporting
> from
> > master only if necessary). With Jakarta EE 10, we will eventually create
> > the branch for supporting the EE 8. Also, for the release versioning, it
> is
> > nice to have a 3.x release. The community will notice that 3.x is the
> > starting point of Jakarta EE support. Will you release 2.x with the
> > intention of supporting Jakarta EE 9? I am personally not positive on
> this.
> > I think, 3.x release will also get more interest even if the
> functionality
> > and API stay the same. We can prepare the press release for it.
> >
> > Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
> >> nor as transitive dep so this change must stay a noop for consumers).
> >>
> > What is the problem of depending on the official Jakarta EE CDI API? It
> is
> > an Apache friendly license. Instead of maintaining the Geronimo CDI API
> > internally, it is more logical to use Jakarta EE official CDI API and
> > maintain this API with EE4J community.
> >
> > would also appreciate if you do a vote if you can point out the breaking
> >> changes - except the package renaming - justifying to fork ourself and
> what
> >> does not work with current solution, can ease the decision/vote.
> >> Today using jakarta/EE9 API is quite easy (
> >>
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> >> ).
> >> We should absolutely enhance the pom experience though but it is
> trivial to
> >> do at maven level - I was envisionning to do it in shade plugin to be
> more
> >> precise.
> >>
> > I know that there will be no functional change. But, I am also against
> > shading for jakarta.*. If there will be no change on Jakarta EE 10, will
> we
> > continue to shade? What happens when there will be a change in EJB, JMS
> > etc specifications but no change in CDI in Jakarta EE 10? Also, VOTING is
> > the natural thing to do for the community decision. If the community
> would
> > like to keep it as it is via shading, it is fine.
> >
> >>
> >> To try to rephrase/clarify my questionning today: you ask for jakarta
> >> support, we already have it in a dev and project efficient way so why
> >> should we change since I don't hink there is anything new - once again
> if
> >> API starts to fully break discussion is different but github doesnt
> reflect
> >> that?
> >>
> > This is not just for Jakarta EE 9 support. As we know, there will be no
> API
> > (functional) change, only package renaming. But, I want to emphasize that
> > with such turning points, it is so logical to integrate official Jakarta
> > CDI API into our master (removing the geronimo-cdi), and release our new
> > 3.x version and let the public know that OWB supports official CDI API
> > beginning with 3.x release. Yeah, shading is an option for package
> renaming
> > but think long term. Also, I am really against the shading. It really
> > disturbs the users which depend on OWB implementation. For example,
> > currently Glassfish supports Weld integration but one can also implement
> > OWB to replace Weld in Glassfish. Therefore, instead of using the shaded
> > version, it is really important to have the full Jakarta EE CDI API in
> our
> > poms. You will still have javax.* dependency in ur POMs even if doing a
> > shade. This is not good idea to still maintain javax.* in our POM files.
> >
> > What are other opinions before formal voting?
> > Regards.
> > Gurkan
> >
> >
> >
> > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <cg...@gmail.com>
> a
> >> écrit :
> >>
> >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on master.
> >>>
> >>
> >> Tomcat works with branches since years without any issue.
> >> All projects we tried to use branches we abandoned branches just after
> >> having done them.
> >> It is fine if the old branch is no more used but here we know we will
> >> maintain javax branch more than jakarta one for some time so I think we
> >> should avoid it while it is not justified or one of the 2 branches
> (javax)
> >> is "almost dead".
> >>
> >>
> >>> sorry but not understand the resistance on this? will you always shade
> ?
> >>>
> >>
> >> As mentionned, until API needs changes we can't easily handle - today
> there
> >> is no change.
> >>
> >>
> >>> creating the new master and maintain the 2.x branch, is the best
> logical
> >>> way. there will be no javax.* any more. Tomcat maintains 3 branches
> and
> >> 1
> >>> master. only maintains 1 branch and 1 master is totally fine.
> >>>
> >>
> >> Fact there will be no more javax is useless IMHO, only question we
> should
> >> care about is "do we have javax users?" and should we work on javax
> branch
> >> enough to care about having 2 duplicate branches. Answer is obviously
> yes
> >> and more than jakarta users today, therefore I think for some months
> (maybe
> >> a few years) we should stick to javax as our primary branch and ensure
> the
> >> alignments and bugfixes can trivially - == without any action from dev
> - be
> >> ported. It is what we have today.
> >>
> >>
> >>>
> >>> I will propose a vote shortly to decide on to create a master with 3.x
> >> with
> >>> fully support of jakarta with a normal pom dependency with jakarta api.
> >>>
> >>
> >> Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
> >> nor as transitive dep so this change must stay a noop for consumers).
> >> I would also appreciate if you do a vote if you can point out the
> breaking
> >> changes - except the package renaming - justifying to fork ourself and
> what
> >> does not work with current solution, can ease the decision/vote.
> >> Today using jakarta/EE9 API is quite easy (
> >>
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> >> ).
> >> We should absolutely enhance the pom experience though but it is
> trivial to
> >> do at maven level - I was envisionning to do it in shade plugin to be
> more
> >> precise.
> >>
> >> To try to rephrase/clarify my questionning today: you ask for jakarta
> >> support, we already have it in a dev and project efficient way so why
> >> should we change since I don't hink there is anything new - once again
> if
> >> API starts to fully break discussion is different but github doesnt
> reflect
> >> that?
> >>
> >>
> >>>
> >>> Regs
> >>> Gurkan
> >>>
> >>>
> >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <rm...@gmail.com>
> >>> wrote:
> >>>
> >>>> Today we don't need, tomorrow I don't know but while API does not
> >> change
> >>>> (except the package) we shouldn't fork ourself IMHO (cause it is what
> >> you
> >>>> propose as a consequence).
> >>>> If it becomes necessary let's do it but my vote is to stay lazy on
> >> that.
> >>>>
> >>>>
> >>>> side note for G API discussion belongs to dev@G but it is less an
> >> issue
> >>> to
> >>>> fork from now since we rarely update the API, the side note here is
> >> that
> >>>> CDI SE is already fully runnable on ASF stack with jakarta package
> >> since
> >>>> some weeks or months, we did all the needed releases.
> >>>>
> >>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> >>>> andraschko.thomas@gmail.com>
> >>>> a écrit :
> >>>>
> >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our build.
> >>>>> As EE9 just changes the namespace, it's perfectly fine.
> >>>>>
> >>>>> I'm actually also a supporter of doing a hard cut but it's not
> >> required
> >>>> and
> >>>>> we can do it for EE 10.
> >>>>>
> >>>>> <
> >>>>>
> >>>>
> >>>
> >>
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >>>>>>
> >>>>> Virenfrei.
> >>>>> www.avast.com
> >>>>> <
> >>>>>
> >>>>
> >>>
> >>
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >>>>>>
> >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >>>>>
> >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> >>>>> cgurkanerdogdu@gmail.com>:
> >>>>>
> >>>>>> We need to maintain two branches
> >>>>>>
> >>>>>> EE 8 for javax.* package 2.x branch
> >>>>>> EE 9 for jakarta.* package 3.x master
> >>>>>>
> >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> >> rmannibucau@gmail.com
> >>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I'll probably restate my position on that: if EE 9 brings
> >>>>> significatively
> >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but I can
> >>> have
> >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can stay as
> >> we
> >>>> are
> >>>>> I
> >>>>>>> think avoiding to maintain two branches we can't merge regularly.
> >>>>>>>
> >>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> >>>> cgurkanerdogdu@gmail.com>
> >>>>> a
> >>>>>>> écrit :
> >>>>>>>
> >>>>>>>> Hi
> >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
> >> support
> >>>>>> upcoming
> >>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
> >>>>>>>>
> >>>>>>>> I also favor to use the Jakarta EE CDI API instead of using the
> >>>>> Apache
> >>>>>>>> based api.
> >>>>>>>> Regards
> >>>>>>>> Gurkan
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Gurkan Erdogdu
> >>>>>>>> http://gurkanerdogdu.blogspot.com
> >>>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>>> Gurkan Erdogdu
> >>>>>> http://gurkanerdogdu.blogspot.com
> >>>>>>
> >>>>>
> >>>>
> >>> --
> >>> Gurkan Erdogdu
> >>> http://gurkanerdogdu.blogspot.com
> >>>
> >>
> >
> >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
>
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by David Jencks <da...@gmail.com>.
I’m not sure exactly how it impacts this decision, but IIUC the geronimo cdi spec jar is rather essential for some uses as it has OSGI support whereas IIUC the eclipse/jakarta one doesn’t.
Personally I’m afraid I’m totally on Romain’s side so far, AFAICT Gurkan’s proposal will only add difficulty for developers and probably users. Although I haven’t been active here for years I might even vote.
thanks
David Jencks
> On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu <cg...@gmail.com> wrote:
>
>>
>> Tomcat works with branches since years without any issue.
>> All projects we tried to use branches we abandoned branches just after
>> having done them.
>> It is fine if the old branch is no more used but here we know we will
>> maintain javax branch more than jakarta one for some time so I think we
>> should avoid it while it is not justified or one of the 2 branches (javax)
>> is "almost dead".
>
> Working with branches always happens in all open source projects. And
> there are times when it is logical to create the branch. Jakarta EE 9 API
> migration is the best time to create such a branch. Eventually, we will
> create such a branch in Jakarta EE 10.
>
> Fact there will be no more javax is useless IMHO, only question we should
>> care about is "do we have javax users?" and should we work on javax branch
>> enough to care about having 2 duplicate branches. Answer is obviously yes
>> and more than jakarta users today, therefore I think for some months (maybe
>> a few years) we should stick to javax as our primary branch and ensure the
>> alignments and bugfixes can trivially - == without any action from dev - be
>> ported. It is what we have today.
>>
> What could be more natural than maintaining branches (with backporting from
> master only if necessary). With Jakarta EE 10, we will eventually create
> the branch for supporting the EE 8. Also, for the release versioning, it is
> nice to have a 3.x release. The community will notice that 3.x is the
> starting point of Jakarta EE support. Will you release 2.x with the
> intention of supporting Jakarta EE 9? I am personally not positive on this.
> I think, 3.x release will also get more interest even if the functionality
> and API stay the same. We can prepare the press release for it.
>
> Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
>> nor as transitive dep so this change must stay a noop for consumers).
>>
> What is the problem of depending on the official Jakarta EE CDI API? It is
> an Apache friendly license. Instead of maintaining the Geronimo CDI API
> internally, it is more logical to use Jakarta EE official CDI API and
> maintain this API with EE4J community.
>
> would also appreciate if you do a vote if you can point out the breaking
>> changes - except the package renaming - justifying to fork ourself and what
>> does not work with current solution, can ease the decision/vote.
>> Today using jakarta/EE9 API is quite easy (
>> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
>> ).
>> We should absolutely enhance the pom experience though but it is trivial to
>> do at maven level - I was envisionning to do it in shade plugin to be more
>> precise.
>>
> I know that there will be no functional change. But, I am also against
> shading for jakarta.*. If there will be no change on Jakarta EE 10, will we
> continue to shade? What happens when there will be a change in EJB, JMS
> etc specifications but no change in CDI in Jakarta EE 10? Also, VOTING is
> the natural thing to do for the community decision. If the community would
> like to keep it as it is via shading, it is fine.
>
>>
>> To try to rephrase/clarify my questionning today: you ask for jakarta
>> support, we already have it in a dev and project efficient way so why
>> should we change since I don't hink there is anything new - once again if
>> API starts to fully break discussion is different but github doesnt reflect
>> that?
>>
> This is not just for Jakarta EE 9 support. As we know, there will be no API
> (functional) change, only package renaming. But, I want to emphasize that
> with such turning points, it is so logical to integrate official Jakarta
> CDI API into our master (removing the geronimo-cdi), and release our new
> 3.x version and let the public know that OWB supports official CDI API
> beginning with 3.x release. Yeah, shading is an option for package renaming
> but think long term. Also, I am really against the shading. It really
> disturbs the users which depend on OWB implementation. For example,
> currently Glassfish supports Weld integration but one can also implement
> OWB to replace Weld in Glassfish. Therefore, instead of using the shaded
> version, it is really important to have the full Jakarta EE CDI API in our
> poms. You will still have javax.* dependency in ur POMs even if doing a
> shade. This is not good idea to still maintain javax.* in our POM files.
>
> What are other opinions before formal voting?
> Regards.
> Gurkan
>
>
>
> On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <cg...@gmail.com> a
>> écrit :
>>
>>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on master.
>>>
>>
>> Tomcat works with branches since years without any issue.
>> All projects we tried to use branches we abandoned branches just after
>> having done them.
>> It is fine if the old branch is no more used but here we know we will
>> maintain javax branch more than jakarta one for some time so I think we
>> should avoid it while it is not justified or one of the 2 branches (javax)
>> is "almost dead".
>>
>>
>>> sorry but not understand the resistance on this? will you always shade ?
>>>
>>
>> As mentionned, until API needs changes we can't easily handle - today there
>> is no change.
>>
>>
>>> creating the new master and maintain the 2.x branch, is the best logical
>>> way. there will be no javax.* any more. Tomcat maintains 3 branches and
>> 1
>>> master. only maintains 1 branch and 1 master is totally fine.
>>>
>>
>> Fact there will be no more javax is useless IMHO, only question we should
>> care about is "do we have javax users?" and should we work on javax branch
>> enough to care about having 2 duplicate branches. Answer is obviously yes
>> and more than jakarta users today, therefore I think for some months (maybe
>> a few years) we should stick to javax as our primary branch and ensure the
>> alignments and bugfixes can trivially - == without any action from dev - be
>> ported. It is what we have today.
>>
>>
>>>
>>> I will propose a vote shortly to decide on to create a master with 3.x
>> with
>>> fully support of jakarta with a normal pom dependency with jakarta api.
>>>
>>
>> Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
>> nor as transitive dep so this change must stay a noop for consumers).
>> I would also appreciate if you do a vote if you can point out the breaking
>> changes - except the package renaming - justifying to fork ourself and what
>> does not work with current solution, can ease the decision/vote.
>> Today using jakarta/EE9 API is quite easy (
>> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
>> ).
>> We should absolutely enhance the pom experience though but it is trivial to
>> do at maven level - I was envisionning to do it in shade plugin to be more
>> precise.
>>
>> To try to rephrase/clarify my questionning today: you ask for jakarta
>> support, we already have it in a dev and project efficient way so why
>> should we change since I don't hink there is anything new - once again if
>> API starts to fully break discussion is different but github doesnt reflect
>> that?
>>
>>
>>>
>>> Regs
>>> Gurkan
>>>
>>>
>>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>
>>>> Today we don't need, tomorrow I don't know but while API does not
>> change
>>>> (except the package) we shouldn't fork ourself IMHO (cause it is what
>> you
>>>> propose as a consequence).
>>>> If it becomes necessary let's do it but my vote is to stay lazy on
>> that.
>>>>
>>>>
>>>> side note for G API discussion belongs to dev@G but it is less an
>> issue
>>> to
>>>> fork from now since we rarely update the API, the side note here is
>> that
>>>> CDI SE is already fully runnable on ASF stack with jakarta package
>> since
>>>> some weeks or months, we did all the needed releases.
>>>>
>>>> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
>>>> andraschko.thomas@gmail.com>
>>>> a écrit :
>>>>
>>>>> AFAIR we dont need it as we shade a -jakarta.jar via our build.
>>>>> As EE9 just changes the namespace, it's perfectly fine.
>>>>>
>>>>> I'm actually also a supporter of doing a hard cut but it's not
>> required
>>>> and
>>>>> we can do it for EE 10.
>>>>>
>>>>> <
>>>>>
>>>>
>>>
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>>>>>>
>>>>> Virenfrei.
>>>>> www.avast.com
>>>>> <
>>>>>
>>>>
>>>
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>>>>>>
>>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>>
>>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
>>>>> cgurkanerdogdu@gmail.com>:
>>>>>
>>>>>> We need to maintain two branches
>>>>>>
>>>>>> EE 8 for javax.* package 2.x branch
>>>>>> EE 9 for jakarta.* package 3.x master
>>>>>>
>>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
>> rmannibucau@gmail.com
>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'll probably restate my position on that: if EE 9 brings
>>>>> significatively
>>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but I can
>>> have
>>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can stay as
>> we
>>>> are
>>>>> I
>>>>>>> think avoiding to maintain two branches we can't merge regularly.
>>>>>>>
>>>>>>> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
>>>> cgurkanerdogdu@gmail.com>
>>>>> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> Hi
>>>>>>>> After the 2.x release, can we get the master to 3.0.0 to
>> support
>>>>>> upcoming
>>>>>>>> Jakarta EE 9 release with jakarta.* namespace?
>>>>>>>>
>>>>>>>> I also favor to use the Jakarta EE CDI API instead of using the
>>>>> Apache
>>>>>>>> based api.
>>>>>>>> Regards
>>>>>>>> Gurkan
>>>>>>>>
>>>>>>>> --
>>>>>>>> Gurkan Erdogdu
>>>>>>>> http://gurkanerdogdu.blogspot.com
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Gurkan Erdogdu
>>>>>> http://gurkanerdogdu.blogspot.com
>>>>>>
>>>>>
>>>>
>>> --
>>> Gurkan Erdogdu
>>> http://gurkanerdogdu.blogspot.com
>>>
>>
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Gurkan Erdogdu <cg...@gmail.com>.
>
> Tomcat works with branches since years without any issue.
> All projects we tried to use branches we abandoned branches just after
> having done them.
> It is fine if the old branch is no more used but here we know we will
> maintain javax branch more than jakarta one for some time so I think we
> should avoid it while it is not justified or one of the 2 branches (javax)
> is "almost dead".
Working with branches always happens in all open source projects. And
there are times when it is logical to create the branch. Jakarta EE 9 API
migration is the best time to create such a branch. Eventually, we will
create such a branch in Jakarta EE 10.
Fact there will be no more javax is useless IMHO, only question we should
> care about is "do we have javax users?" and should we work on javax branch
> enough to care about having 2 duplicate branches. Answer is obviously yes
> and more than jakarta users today, therefore I think for some months (maybe
> a few years) we should stick to javax as our primary branch and ensure the
> alignments and bugfixes can trivially - == without any action from dev - be
> ported. It is what we have today.
>
What could be more natural than maintaining branches (with backporting from
master only if necessary). With Jakarta EE 10, we will eventually create
the branch for supporting the EE 8. Also, for the release versioning, it is
nice to have a 3.x release. The community will notice that 3.x is the
starting point of Jakarta EE support. Will you release 2.x with the
intention of supporting Jakarta EE 9? I am personally not positive on this.
I think, 3.x release will also get more interest even if the functionality
and API stay the same. We can prepare the press release for it.
Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
> nor as transitive dep so this change must stay a noop for consumers).
>
What is the problem of depending on the official Jakarta EE CDI API? It is
an Apache friendly license. Instead of maintaining the Geronimo CDI API
internally, it is more logical to use Jakarta EE official CDI API and
maintain this API with EE4J community.
would also appreciate if you do a vote if you can point out the breaking
> changes - except the package renaming - justifying to fork ourself and what
> does not work with current solution, can ease the decision/vote.
> Today using jakarta/EE9 API is quite easy (
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> ).
> We should absolutely enhance the pom experience though but it is trivial to
> do at maven level - I was envisionning to do it in shade plugin to be more
> precise.
>
I know that there will be no functional change. But, I am also against
shading for jakarta.*. If there will be no change on Jakarta EE 10, will we
continue to shade? What happens when there will be a change in EJB, JMS
etc specifications but no change in CDI in Jakarta EE 10? Also, VOTING is
the natural thing to do for the community decision. If the community would
like to keep it as it is via shading, it is fine.
>
> To try to rephrase/clarify my questionning today: you ask for jakarta
> support, we already have it in a dev and project efficient way so why
> should we change since I don't hink there is anything new - once again if
> API starts to fully break discussion is different but github doesnt reflect
> that?
>
This is not just for Jakarta EE 9 support. As we know, there will be no API
(functional) change, only package renaming. But, I want to emphasize that
with such turning points, it is so logical to integrate official Jakarta
CDI API into our master (removing the geronimo-cdi), and release our new
3.x version and let the public know that OWB supports official CDI API
beginning with 3.x release. Yeah, shading is an option for package renaming
but think long term. Also, I am really against the shading. It really
disturbs the users which depend on OWB implementation. For example,
currently Glassfish supports Weld integration but one can also implement
OWB to replace Weld in Glassfish. Therefore, instead of using the shaded
version, it is really important to have the full Jakarta EE CDI API in our
poms. You will still have javax.* dependency in ur POMs even if doing a
shade. This is not good idea to still maintain javax.* in our POM files.
What are other opinions before formal voting?
Regards.
Gurkan
On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <cg...@gmail.com> a
> écrit :
>
> > Tomcat created branch 10 for jakarta ee 9. Glassfish is also on master.
> >
>
> Tomcat works with branches since years without any issue.
> All projects we tried to use branches we abandoned branches just after
> having done them.
> It is fine if the old branch is no more used but here we know we will
> maintain javax branch more than jakarta one for some time so I think we
> should avoid it while it is not justified or one of the 2 branches (javax)
> is "almost dead".
>
>
> > sorry but not understand the resistance on this? will you always shade ?
> >
>
> As mentionned, until API needs changes we can't easily handle - today there
> is no change.
>
>
> > creating the new master and maintain the 2.x branch, is the best logical
> > way. there will be no javax.* any more. Tomcat maintains 3 branches and
> 1
> > master. only maintains 1 branch and 1 master is totally fine.
> >
>
> Fact there will be no more javax is useless IMHO, only question we should
> care about is "do we have javax users?" and should we work on javax branch
> enough to care about having 2 duplicate branches. Answer is obviously yes
> and more than jakarta users today, therefore I think for some months (maybe
> a few years) we should stick to javax as our primary branch and ensure the
> alignments and bugfixes can trivially - == without any action from dev - be
> ported. It is what we have today.
>
>
> >
> > I will propose a vote shortly to decide on to create a master with 3.x
> with
> > fully support of jakarta with a normal pom dependency with jakarta api.
> >
>
> Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
> nor as transitive dep so this change must stay a noop for consumers).
> I would also appreciate if you do a vote if you can point out the breaking
> changes - except the package renaming - justifying to fork ourself and what
> does not work with current solution, can ease the decision/vote.
> Today using jakarta/EE9 API is quite easy (
> https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
> ).
> We should absolutely enhance the pom experience though but it is trivial to
> do at maven level - I was envisionning to do it in shade plugin to be more
> precise.
>
> To try to rephrase/clarify my questionning today: you ask for jakarta
> support, we already have it in a dev and project efficient way so why
> should we change since I don't hink there is anything new - once again if
> API starts to fully break discussion is different but github doesnt reflect
> that?
>
>
> >
> > Regs
> > Gurkan
> >
> >
> > On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> >
> > > Today we don't need, tomorrow I don't know but while API does not
> change
> > > (except the package) we shouldn't fork ourself IMHO (cause it is what
> you
> > > propose as a consequence).
> > > If it becomes necessary let's do it but my vote is to stay lazy on
> that.
> > >
> > >
> > > side note for G API discussion belongs to dev@G but it is less an
> issue
> > to
> > > fork from now since we rarely update the API, the side note here is
> that
> > > CDI SE is already fully runnable on ASF stack with jakarta package
> since
> > > some weeks or months, we did all the needed releases.
> > >
> > > 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > > andraschko.thomas@gmail.com>
> > > a écrit :
> > >
> > > > AFAIR we dont need it as we shade a -jakarta.jar via our build.
> > > > As EE9 just changes the namespace, it's perfectly fine.
> > > >
> > > > I'm actually also a supporter of doing a hard cut but it's not
> required
> > > and
> > > > we can do it for EE 10.
> > > >
> > > > <
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > >
> > > > Virenfrei.
> > > > www.avast.com
> > > > <
> > > >
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > > >
> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > >
> > > > Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> > > > cgurkanerdogdu@gmail.com>:
> > > >
> > > > > We need to maintain two branches
> > > > >
> > > > > EE 8 for javax.* package 2.x branch
> > > > > EE 9 for jakarta.* package 3.x master
> > > > >
> > > > > On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'll probably restate my position on that: if EE 9 brings
> > > > significatively
> > > > > > new API yes - a quick review shows it is 1-1 with EE 8 but I can
> > have
> > > > > > missed sthg, looked quite fast. if EE9==EE8 then we can stay as
> we
> > > are
> > > > I
> > > > > > think avoiding to maintain two branches we can't merge regularly.
> > > > > >
> > > > > > 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > > cgurkanerdogdu@gmail.com>
> > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > Hi
> > > > > > > After the 2.x release, can we get the master to 3.0.0 to
> support
> > > > > upcoming
> > > > > > > Jakarta EE 9 release with jakarta.* namespace?
> > > > > > >
> > > > > > > I also favor to use the Jakarta EE CDI API instead of using the
> > > > Apache
> > > > > > > based api.
> > > > > > > Regards
> > > > > > > Gurkan
> > > > > > >
> > > > > > > --
> > > > > > > Gurkan Erdogdu
> > > > > > > http://gurkanerdogdu.blogspot.com
> > > > > > >
> > > > > >
> > > > > --
> > > > > Gurkan Erdogdu
> > > > > http://gurkanerdogdu.blogspot.com
> > > > >
> > > >
> > >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <cg...@gmail.com> a
écrit :
> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on master.
>
Tomcat works with branches since years without any issue.
All projects we tried to use branches we abandoned branches just after
having done them.
It is fine if the old branch is no more used but here we know we will
maintain javax branch more than jakarta one for some time so I think we
should avoid it while it is not justified or one of the 2 branches (javax)
is "almost dead".
> sorry but not understand the resistance on this? will you always shade ?
>
As mentionned, until API needs changes we can't easily handle - today there
is no change.
> creating the new master and maintain the 2.x branch, is the best logical
> way. there will be no javax.* any more. Tomcat maintains 3 branches and 1
> master. only maintains 1 branch and 1 master is totally fine.
>
Fact there will be no more javax is useless IMHO, only question we should
care about is "do we have javax users?" and should we work on javax branch
enough to care about having 2 duplicate branches. Answer is obviously yes
and more than jakarta users today, therefore I think for some months (maybe
a few years) we should stick to javax as our primary branch and ensure the
alignments and bugfixes can trivially - == without any action from dev - be
ported. It is what we have today.
>
> I will propose a vote shortly to decide on to create a master with 3.x with
> fully support of jakarta with a normal pom dependency with jakarta api.
>
Note we shouldn't depend on jakarta/javax api anyway (neither as groupId
nor as transitive dep so this change must stay a noop for consumers).
I would also appreciate if you do a vote if you can point out the breaking
changes - except the package renaming - justifying to fork ourself and what
does not work with current solution, can ease the decision/vote.
Today using jakarta/EE9 API is quite easy (
https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt
).
We should absolutely enhance the pom experience though but it is trivial to
do at maven level - I was envisionning to do it in shade plugin to be more
precise.
To try to rephrase/clarify my questionning today: you ask for jakarta
support, we already have it in a dev and project efficient way so why
should we change since I don't hink there is anything new - once again if
API starts to fully break discussion is different but github doesnt reflect
that?
>
> Regs
> Gurkan
>
>
> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Today we don't need, tomorrow I don't know but while API does not change
> > (except the package) we shouldn't fork ourself IMHO (cause it is what you
> > propose as a consequence).
> > If it becomes necessary let's do it but my vote is to stay lazy on that.
> >
> >
> > side note for G API discussion belongs to dev@G but it is less an issue
> to
> > fork from now since we rarely update the API, the side note here is that
> > CDI SE is already fully runnable on ASF stack with jakarta package since
> > some weeks or months, we did all the needed releases.
> >
> > 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> > andraschko.thomas@gmail.com>
> > a écrit :
> >
> > > AFAIR we dont need it as we shade a -jakarta.jar via our build.
> > > As EE9 just changes the namespace, it's perfectly fine.
> > >
> > > I'm actually also a supporter of doing a hard cut but it's not required
> > and
> > > we can do it for EE 10.
> > >
> > > <
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > >
> > > Virenfrei.
> > > www.avast.com
> > > <
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > > >
> > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >
> > > Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> > > cgurkanerdogdu@gmail.com>:
> > >
> > > > We need to maintain two branches
> > > >
> > > > EE 8 for javax.* package 2.x branch
> > > > EE 9 for jakarta.* package 3.x master
> > > >
> > > > On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I'll probably restate my position on that: if EE 9 brings
> > > significatively
> > > > > new API yes - a quick review shows it is 1-1 with EE 8 but I can
> have
> > > > > missed sthg, looked quite fast. if EE9==EE8 then we can stay as we
> > are
> > > I
> > > > > think avoiding to maintain two branches we can't merge regularly.
> > > > >
> > > > > 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> > cgurkanerdogdu@gmail.com>
> > > a
> > > > > écrit :
> > > > >
> > > > > > Hi
> > > > > > After the 2.x release, can we get the master to 3.0.0 to support
> > > > upcoming
> > > > > > Jakarta EE 9 release with jakarta.* namespace?
> > > > > >
> > > > > > I also favor to use the Jakarta EE CDI API instead of using the
> > > Apache
> > > > > > based api.
> > > > > > Regards
> > > > > > Gurkan
> > > > > >
> > > > > > --
> > > > > > Gurkan Erdogdu
> > > > > > http://gurkanerdogdu.blogspot.com
> > > > > >
> > > > >
> > > > --
> > > > Gurkan Erdogdu
> > > > http://gurkanerdogdu.blogspot.com
> > > >
> > >
> >
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
Re: Jakarta EE 9 Support
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Tomcat created branch 10 for jakarta ee 9. Glassfish is also on master.
sorry but not understand the resistance on this? will you always shade ?
creating the new master and maintain the 2.x branch, is the best logical
way. there will be no javax.* any more. Tomcat maintains 3 branches and 1
master. only maintains 1 branch and 1 master is totally fine.
I will propose a vote shortly to decide on to create a master with 3.x with
fully support of jakarta with a normal pom dependency with jakarta api.
Regs
Gurkan
On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau <rm...@gmail.com> wrote:
> Today we don't need, tomorrow I don't know but while API does not change
> (except the package) we shouldn't fork ourself IMHO (cause it is what you
> propose as a consequence).
> If it becomes necessary let's do it but my vote is to stay lazy on that.
>
>
> side note for G API discussion belongs to dev@G but it is less an issue to
> fork from now since we rarely update the API, the side note here is that
> CDI SE is already fully runnable on ASF stack with jakarta package since
> some weeks or months, we did all the needed releases.
>
> 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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <
> andraschko.thomas@gmail.com>
> a écrit :
>
> > AFAIR we dont need it as we shade a -jakarta.jar via our build.
> > As EE9 just changes the namespace, it's perfectly fine.
> >
> > I'm actually also a supporter of doing a hard cut but it's not required
> and
> > we can do it for EE 10.
> >
> > <
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > >
> > Virenfrei.
> > www.avast.com
> > <
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> > cgurkanerdogdu@gmail.com>:
> >
> > > We need to maintain two branches
> > >
> > > EE 8 for javax.* package 2.x branch
> > > EE 9 for jakarta.* package 3.x master
> > >
> > > On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <rm...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I'll probably restate my position on that: if EE 9 brings
> > significatively
> > > > new API yes - a quick review shows it is 1-1 with EE 8 but I can have
> > > > missed sthg, looked quite fast. if EE9==EE8 then we can stay as we
> are
> > I
> > > > think avoiding to maintain two branches we can't merge regularly.
> > > >
> > > > 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <
> cgurkanerdogdu@gmail.com>
> > a
> > > > écrit :
> > > >
> > > > > Hi
> > > > > After the 2.x release, can we get the master to 3.0.0 to support
> > > upcoming
> > > > > Jakarta EE 9 release with jakarta.* namespace?
> > > > >
> > > > > I also favor to use the Jakarta EE CDI API instead of using the
> > Apache
> > > > > based api.
> > > > > Regards
> > > > > Gurkan
> > > > >
> > > > > --
> > > > > Gurkan Erdogdu
> > > > > http://gurkanerdogdu.blogspot.com
> > > > >
> > > >
> > > --
> > > Gurkan Erdogdu
> > > http://gurkanerdogdu.blogspot.com
> > >
> >
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Today we don't need, tomorrow I don't know but while API does not change
(except the package) we shouldn't fork ourself IMHO (cause it is what you
propose as a consequence).
If it becomes necessary let's do it but my vote is to stay lazy on that.
side note for G API discussion belongs to dev@G but it is less an issue to
fork from now since we rarely update the API, the side note here is that
CDI SE is already fully runnable on ASF stack with jakarta package since
some weeks or months, we did all the needed releases.
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 dim. 7 juin 2020 à 16:42, Thomas Andraschko <an...@gmail.com>
a écrit :
> AFAIR we dont need it as we shade a -jakarta.jar via our build.
> As EE9 just changes the namespace, it's perfectly fine.
>
> I'm actually also a supporter of doing a hard cut but it's not required and
> we can do it for EE 10.
>
> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> Virenfrei.
> www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
> cgurkanerdogdu@gmail.com>:
>
> > We need to maintain two branches
> >
> > EE 8 for javax.* package 2.x branch
> > EE 9 for jakarta.* package 3.x master
> >
> > On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I'll probably restate my position on that: if EE 9 brings
> significatively
> > > new API yes - a quick review shows it is 1-1 with EE 8 but I can have
> > > missed sthg, looked quite fast. if EE9==EE8 then we can stay as we are
> I
> > > think avoiding to maintain two branches we can't merge regularly.
> > >
> > > 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <cg...@gmail.com>
> a
> > > écrit :
> > >
> > > > Hi
> > > > After the 2.x release, can we get the master to 3.0.0 to support
> > upcoming
> > > > Jakarta EE 9 release with jakarta.* namespace?
> > > >
> > > > I also favor to use the Jakarta EE CDI API instead of using the
> Apache
> > > > based api.
> > > > Regards
> > > > Gurkan
> > > >
> > > > --
> > > > Gurkan Erdogdu
> > > > http://gurkanerdogdu.blogspot.com
> > > >
> > >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
Re: Jakarta EE 9 Support
Posted by Thomas Andraschko <an...@gmail.com>.
AFAIR we dont need it as we shade a -jakarta.jar via our build.
As EE9 just changes the namespace, it's perfectly fine.
I'm actually also a supporter of doing a hard cut but it's not required and
we can do it for EE 10.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virenfrei.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu <
cgurkanerdogdu@gmail.com>:
> We need to maintain two branches
>
> EE 8 for javax.* package 2.x branch
> EE 9 for jakarta.* package 3.x master
>
> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I'll probably restate my position on that: if EE 9 brings significatively
> > new API yes - a quick review shows it is 1-1 with EE 8 but I can have
> > missed sthg, looked quite fast. if EE9==EE8 then we can stay as we are I
> > think avoiding to maintain two branches we can't merge regularly.
> >
> > 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <cg...@gmail.com> a
> > écrit :
> >
> > > Hi
> > > After the 2.x release, can we get the master to 3.0.0 to support
> upcoming
> > > Jakarta EE 9 release with jakarta.* namespace?
> > >
> > > I also favor to use the Jakarta EE CDI API instead of using the Apache
> > > based api.
> > > Regards
> > > Gurkan
> > >
> > > --
> > > Gurkan Erdogdu
> > > http://gurkanerdogdu.blogspot.com
> > >
> >
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
Re: Jakarta EE 9 Support
Posted by Gurkan Erdogdu <cg...@gmail.com>.
We need to maintain two branches
EE 8 for javax.* package 2.x branch
EE 9 for jakarta.* package 3.x master
On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau <rm...@gmail.com> wrote:
> Hi,
>
> I'll probably restate my position on that: if EE 9 brings significatively
> new API yes - a quick review shows it is 1-1 with EE 8 but I can have
> missed sthg, looked quite fast. if EE9==EE8 then we can stay as we are I
> think avoiding to maintain two branches we can't merge regularly.
>
> 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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <cg...@gmail.com> a
> écrit :
>
> > Hi
> > After the 2.x release, can we get the master to 3.0.0 to support upcoming
> > Jakarta EE 9 release with jakarta.* namespace?
> >
> > I also favor to use the Jakarta EE CDI API instead of using the Apache
> > based api.
> > Regards
> > Gurkan
> >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Jakarta EE 9 Support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
I'll probably restate my position on that: if EE 9 brings significatively
new API yes - a quick review shows it is 1-1 with EE 8 but I can have
missed sthg, looked quite fast. if EE9==EE8 then we can stay as we are I
think avoiding to maintain two branches we can't merge regularly.
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 dim. 7 juin 2020 à 10:26, Gurkan Erdogdu <cg...@gmail.com> a
écrit :
> Hi
> After the 2.x release, can we get the master to 3.0.0 to support upcoming
> Jakarta EE 9 release with jakarta.* namespace?
>
> I also favor to use the Jakarta EE CDI API instead of using the Apache
> based api.
> Regards
> Gurkan
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>