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 <cgurkanerdo...@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 <cgurkanerdo...@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 <rmannibu...@gmail.com
> >
> > wrote:
> >
> >> Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu <cgurkanerdo...@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 <
> >> rmannibu...@gmail.com>
> >> > wrote:
> >> >
> >> > > Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <
> cgurkanerdo...@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.jen...@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 <
> >> > > cgurkanerdo...@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 <
> >> > > > rmannibu...@gmail.com
> >> > > > > >
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu <
> >> > > cgurkanerdo...@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 <
> >> > > rmannibu...@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.tho...@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 <
> >> > > > > >>>>> cgurkanerdo...@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 <
> >> > > > > >> rmannibu...@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 <
> >> > > > > >>>> cgurkanerdo...@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
>
