Re: [VOTE] Release Apache OpenWebBeans-2.0.17

[Daniel Dias Dos Santos]

+1
--

*Daniel Dias dos Santos*
Java Developer
SouJava & JCP Member
GitHub: https://github.com/Daniel-Dos
Linkedin: www.linkedin.com/in/danieldiasjava
Twitter: http://twitter.com/danieldiasjava


Em dom., 7 de jun. de 2020 às 18:30, Mark Struberg
 escreveu:

> hi!
>
> I'd like to call a VOTE on releasing Apache OpenWebBeans-2.0.17
>
> The following tickets have been resolved:
>
> Bug
>
> [OWB-1214 ] - Package
> annotation access is fragile
> Task
>
> [OWB-1322 ] - SLF4J
> integration workaround for log4j2-slf4j implementation which can fail in
> NPE on java >= 9
> [OWB-1323 ] - Upgrade to
> asm8
> [OWB-1324 ] - Support
> maven shade 3.2.3
> [OWB-1325 ] - Provide a
> spy flavor of ClassDefiningService
> [OWB-1326 ] -
> Bean#isNullable is ignored since CDI-1.1.
>
>
>
> The staging repo is
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/
> <
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/
> >
>
> commit in our repo is 20d2b83390996007873abb2338a8b1fb61a55ceb
>
> The source release can be found in
>
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/org/apache/openwebbeans/openwebbeans/2.0.17/
> <
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/org/apache/openwebbeans/openwebbeans/2.0.17/
> >
>
> sha1 is 192bd3654375640ac5ceb365e728bba67bed16b4
>
> Please VOTE:
> [+1] let's ship it
> [0] meh, don't care
> [-1] stop there is a ${showstopper}
>
> The VOTE is open for 72h
>
>
> txs and LieGrue,
> strub
>
>

[VOTE] Release Apache OpenWebBeans-2.0.17

[Mark Struberg]

hi!

I'd like to call a VOTE on releasing Apache OpenWebBeans-2.0.17

The following tickets have been resolved:

Bug

[OWB-1214 ] - Package 
annotation access is fragile
Task

[OWB-1322 ] - SLF4J integration 
workaround for log4j2-slf4j implementation which can fail in NPE on java >= 9
[OWB-1323 ] - Upgrade to asm8
[OWB-1324 ] - Support maven 
shade 3.2.3
[OWB-1325 ] - Provide a spy 
flavor of ClassDefiningService
[OWB-1326 ] - Bean#isNullable 
is ignored since CDI-1.1.



The staging repo is
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/ 


commit in our repo is 20d2b83390996007873abb2338a8b1fb61a55ceb

The source release can be found in 
https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/org/apache/openwebbeans/openwebbeans/2.0.17/
 


sha1 is 192bd3654375640ac5ceb365e728bba67bed16b4

Please VOTE:
[+1] let's ship it
[0] meh, don't care
[-1] stop there is a ${showstopper}

The VOTE is open for 72h


txs and LieGrue,
strub

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

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 
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 
> wrote:
>
>> Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu  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 
>> 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 

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

>
> 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 
wrote:

> Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu  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  >
> > wrote:
> >
> > > Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu 
> 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: 

Re: Jakarta EE 9 Support

[Romain Manni-Bucau]

Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu  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 
> wrote:
>
> > Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu  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
> >  

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

> 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 
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 
> wrote:
>
>> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu  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"

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

>
> 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 
wrote:

> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu  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 

Re: Jakarta EE 9 Support

[Romain Manni-Bucau]

PS: for ref, the original thread on this topic
https://markmail.org/message/76uveuuvvhxx6b3v

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 7 juin 2020 à 20:25, Romain Manni-Bucau  a
écrit :

>
>
> Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu  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 
>> 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 > >
>> > 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 

Re: Jakarta EE 9 Support

[Romain Manni-Bucau]

Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu  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 
> 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 
> > 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 

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

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 
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 
> 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 

Re: Jakarta EE 9 Support

[David Jencks]

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  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?
> 

Re: Jakarta EE 9 Support

[Romain Manni-Bucau]

Le dim. 7 juin 2020 à 19:47, Gurkan Erdogdu  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 

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

>
> 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 
wrote:

> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu  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".
>
>

Re: Jakarta EE 9 Support

[Romain Manni-Bucau]

Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu  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 
> 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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | 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_source=link_campaign=sig-email_content=webmail
> > > >
> > > Virenfrei.
> > > www.avast.com
> > > <
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_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  >
> > > > 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 

Re: Jakarta EE 9 Support

[Gurkan Erdogdu]

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  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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | 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_source=link_campaign=sig-email_content=webmail
> > >
> > Virenfrei.
> > www.avast.com
> > <
> >
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_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 
> > > 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  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | 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

Re: Jakarta EE 9 Support

[Thomas Andraschko]

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.


Virenfrei.
www.avast.com

<#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 
> 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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le dim. 7 juin 2020 à 10:26, Gurkan Erdogdu  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

[Gurkan Erdogdu]

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  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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 7 juin 2020 à 10:26, Gurkan Erdogdu  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

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 7 juin 2020 à 10:26, Gurkan Erdogdu  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
>

Re: Will start with the release tomorrow

[Romain Manni-Bucau]

Le dim. 7 juin 2020 à 10:23, Gurkan Erdogdu  a
écrit :

>  Does current master support jakarta.*? What do you mean by comply? Did you
> run latest Jakarta EE 9 Cdi TCK?
>

Yes, no we are EE 8 compliant.


>
> On 7 Jun 2020 Sun at 11:16 Romain Manni-Bucau 
> wrote:
>
> > +1 for the release
> >
> > Let's discuss it in another thread since today we are already compliant
> and
> > just need to setup tck in the build
> >
> > Le dim. 7 juin 2020 à 10:13, Gurkan Erdogdu  a
> > écrit :
> >
> > > Hi Mark
> > > After the release, can we make master 3.0.0 for
> > > Jakarta EE 9 and adapting the Jakarta  Cdi API?
> > > Regards
> > > Gurkan
> > >
> > > On 6 Jun 2020 Sat at 23:34 Mark Struberg 
> > > wrote:
> > >
> > > > hi folks!
> > > >
> > > > Gonna start with the OWB release tomorrow.
> > > > If there is anything to fix before that then shout.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > > --
> > > Gurkan Erdogdu
> > > http://gurkanerdogdu.blogspot.com
> > >
> >
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>

Jakarta EE 9 Support

[Gurkan Erdogdu]

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: Will start with the release tomorrow

[Gurkan Erdogdu]

 Does current master support jakarta.*? What do you mean by comply? Did you
run latest Jakarta EE 9 Cdi TCK?

On 7 Jun 2020 Sun at 11:16 Romain Manni-Bucau  wrote:

> +1 for the release
>
> Let's discuss it in another thread since today we are already compliant and
> just need to setup tck in the build
>
> Le dim. 7 juin 2020 à 10:13, Gurkan Erdogdu  a
> écrit :
>
> > Hi Mark
> > After the release, can we make master 3.0.0 for
> > Jakarta EE 9 and adapting the Jakarta  Cdi API?
> > Regards
> > Gurkan
> >
> > On 6 Jun 2020 Sat at 23:34 Mark Struberg 
> > wrote:
> >
> > > hi folks!
> > >
> > > Gonna start with the OWB release tomorrow.
> > > If there is anything to fix before that then shout.
> > >
> > > LieGrue,
> > > strub
> > >
> > > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Will start with the release tomorrow

[Romain Manni-Bucau]

+1 for the release

Let's discuss it in another thread since today we are already compliant and
just need to setup tck in the build

Le dim. 7 juin 2020 à 10:13, Gurkan Erdogdu  a
écrit :

> Hi Mark
> After the release, can we make master 3.0.0 for
> Jakarta EE 9 and adapting the Jakarta  Cdi API?
> Regards
> Gurkan
>
> On 6 Jun 2020 Sat at 23:34 Mark Struberg 
> wrote:
>
> > hi folks!
> >
> > Gonna start with the OWB release tomorrow.
> > If there is anything to fix before that then shout.
> >
> > LieGrue,
> > strub
> >
> > --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>

Re: Will start with the release tomorrow

[Gurkan Erdogdu]

Hi Mark
After the release, can we make master 3.0.0 for
Jakarta EE 9 and adapting the Jakarta  Cdi API?
Regards
Gurkan

On 6 Jun 2020 Sat at 23:34 Mark Struberg  wrote:

> hi folks!
>
> Gonna start with the OWB release tomorrow.
> If there is anything to fix before that then shout.
>
> LieGrue,
> strub
>
> --
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com