Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-03 Thread Mark Struberg
 +1
LieGrue,strub

On Monday, 3 May 2021, 11:30:50 CEST, Alex The Rocker 
 wrote:  
 
 +1 (non-binding) for this 8.0.7 release, I'll test it as soon as link
to binaries is available !

Alex

Le lun. 3 mai 2021 à 10:24, David Blevins  a écrit :
>
> Dear Community.
>
> The time has come :)
  

Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-03 Thread Alex The Rocker
+1 (non-binding) for this 8.0.7 release, I'll test it as soon as link
to binaries is available !

Alex

Le lun. 3 mai 2021 à 10:24, David Blevins  a écrit :
>
> Dear Community.
>
> The time has come :)


Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-03 Thread David Blevins
Dear Community.

The time has come :)

smime.p7s
Description: S/MIME cryptographic signature


Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-03 Thread Wiesner, Martin
Hello all, hello (tired) David

I'm in favor of rolling a release (vote). Here's my „+1“.

Thx in advance to all contributors who made this great progress possible!

Best
Martin
—
https://twitter.com/mawiesne


Am 01.05.2021 um 17:01 schrieb Daniel Dias Dos Santos 
mailto:daniel.dias.analist...@gmail.com>>:

Hello David,

I am in favor of releasing the vote, here's my +1


Em sex., 30 de abr. de 2021 às 22:32, David Blevins 
mailto:david.blev...@gmail.com>>
escreveu:

Heads up that we are narrowing in in the last few TCK issues and there is
still some chance we can be Jakarta EE 9.1 Web Profile certified in time
for the Jakarta EE 9.1 release vote Monday.

It would be super super and I mean *super* tight

However, if we can get it done we'll need to do a release vote by no later
than Sunday afternoon and file our certification request.  We don't need to
have concluded our vote to make the Jakarta EE 9.1 release ballot, we just
need final binaries of our own to be at least in staging and in the process
of our own vote.

We do need that vote pass, however, so that would require some pragmatism
on all our parts.

For that reason I recommend we do not try to push out a 9.0.0 final, but
go ahead with 9.0.0-M7. If there are some issues with the binaries we put
up for vote, unless they are legal issues, we can still release them and
immediately fix the issues next week in a subsequent 8.0.8 and 9.0.0-M8.
There's no reason to "wait", we can simply release twice.  Version numbers
are free.

The Jakarta EE 9.1 release vote lasts for two weeks and an announcement
would happen some days after that.  Ff we did want to push out a 9.0.0 for
the announcement, we'd have at least till May 17th to do that, perhaps even
the 20th.

The reason we want to get certified in time for the ballot is recently
there was a change that implementations listed on the ballot get a special
place at the top of the specification page.  Any implementations that come
even one day later cannot be included and will not be accepted or given
special designation.  This lasts forever and is a permanent advantage to
those in the list.  It's also a permanent *disadvantage* to those not on
the list.  It's eat or be eaten.

So that's what we're going for:  A staged binary up for a vote here,
passing the TCK, in time to be listed on the Jakarta EE 9.1 release ballot
Monday.


-David





Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-03 Thread Zowalla, Richard
Hi Alexandre,

in 8.0.7, Tomcat is @ version 9.0.45 atm (TOMEE-2998).
We also updated the related web.xml files for mime type mapping (TOMEE-
3718).

Gruss
Richard


Am Sonntag, den 02.05.2021, 19:22 +0200 schrieb Alex The Rocker:
> Hi David,
> 
> Thanks for your answer, this is perfectly clear.
> 
> Will this upcoming TomEE 8.0.7 release include latest Tomcat / CXF
> dependencies that fixes CVEs that showed up since 8.0.6 release ?
> 
> Kind regards,
> Alexandre
> 
> Le dim. 2 mai 2021 à 19:09, David Blevins  a
> écrit :
> > > On May 2, 2021, at 9:39 AM, Alex The Rocker  > > > wrote:
> > > 
> > > I am a bit confused : I thought that renaming of javax.* into
> > > jakarta.* packages for the EE API is only targeted for TomEE 9.x.
> > 
> > All the source code is in TomEE 8.0 and TomEE 9.0.x is just created
> > through bytecode transformation.  The long and short of that is
> > they pass/fail almost the exact same tests as it's the same code.
> > We can do library upgrades in the `tomee-jakarta` repo and add a
> > patch file for third-party dependencies here and there, but any
> > fixes on the TomEE side go into 8 and are automatically picked up
> > in via bytecode transformation of 9 as well.
> > 
> > In fact, I've been doing most my local work exclusively running the
> > Jakarta EE 8 TCK and just letting the automated systems do the
> > running of the EE 9 TCK.
> > 
> > > In such case, what would be the content of a TomEE 8.0.7 release?
> > 
> > Everything in this list is fixed, except about 10 tests which are
> > not part of the Web Profile and therefore not required for
> > certification and will be fixed later.  Though it says "EE 9" these
> > failed for both 8 and 9 TCKs:
> > 
> >  - https://issues.apache.org/jira/browse/TOMEE-3140
> > 
> > We're still one TCK test shy of passing and have some work to do on
> > the API jars to pass the signature tests, but it's looking good.
> > 
> > Brief pause for me to take a nap, however, as I've been up for 24
> > hours and keep nodding off at the keyboard :)
> > 
> > 
> > -David
> > 
> > 
> > > In any cases, I'd be happy to see a TomEE 8.0.7 release soon, in
> > > order
> > > to get latest CVE fixes since 8.0.6.
> > > 
> > > Kind regards,
> > > Alexandre
> > > 
> > > Le sam. 1 mai 2021 à 03:32, David Blevins <
> > > david.blev...@gmail.com> a écrit :
> > > > Heads up that we are narrowing in in the last few TCK issues
> > > > and there is still some chance we can be Jakarta EE 9.1 Web
> > > > Profile certified in time for the Jakarta EE 9.1 release vote
> > > > Monday.
> > > > 
> > > > It would be super super and I mean *super* tight
> > > > 
> > > > However, if we can get it done we'll need to do a release vote
> > > > by no later than Sunday afternoon and file our certification
> > > > request.  We don't need to have concluded our vote to make the
> > > > Jakarta EE 9.1 release ballot, we just need final binaries of
> > > > our own to be at least in staging and in the process of our own
> > > > vote.
> > > > 
> > > > We do need that vote pass, however, so that would require some
> > > > pragmatism on all our parts.
> > > > 
> > > > For that reason I recommend we do not try to push out a 9.0.0
> > > > final, but go ahead with 9.0.0-M7. If there are some issues
> > > > with the binaries we put up for vote, unless they are legal
> > > > issues, we can still release them and immediately fix the
> > > > issues next week in a subsequent 8.0.8 and 9.0.0-M8.  There's
> > > > no reason to "wait", we can simply release twice.  Version
> > > > numbers are free.
> > > > 
> > > > The Jakarta EE 9.1 release vote lasts for two weeks and an
> > > > announcement would happen some days after that.  Ff we did want
> > > > to push out a 9.0.0 for the announcement, we'd have at least
> > > > till May 17th to do that, perhaps even the 20th.
> > > > 
> > > > The reason we want to get certified in time for the ballot is
> > > > recently there was a change that implementations listed on the
> > > > ballot get a special place at the top of the specification
> > > > page.  Any implementations that come even one day later cannot
> > > > be included and will not be accepted or given special
> > > > designation.  This lasts forever and is a permanent advantage
> > > > to those in the list.  It's also a permanent *disadvantage* to
> > > > those not on the list.  It's eat or be eaten.
> > > > 
> > > > So that's what we're going for:  A staged binary up for a vote
> > > > here, passing the TCK, in time to be listed on the Jakarta EE
> > > > 9.1 release ballot Monday.
> > > > 
> > > > 
> > > > -David
> > > > 
-- 
Richard Zowalla, M.Sc.
Research Associate, PhD Student | Medical Informatics

Hochschule Heilbronn – University of Applied Sciences
Max-Planck-Str. 39 
D-74081 Heilbronn 
phone: +49 7131 504 6791 (zur Zeit nicht via Telefon erreichbar)
mail: richard.zowa...@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/ 


smime.p7s
Description: S/MIME cryptographic signature


Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-02 Thread Alex The Rocker
Okay great for TomEE, but take some rest : it won't help if you get a
burn out trying not to sleep for too long!

Le dim. 2 mai 2021 à 19:32, David Blevins  a écrit :
>
> > On May 2, 2021, at 10:22 AM, Alex The Rocker  wrote:
> >
> > Hi David,
> >
> > Thanks for your answer, this is perfectly clear.
> >
> > Will this upcoming TomEE 8.0.7 release include latest Tomcat / CXF
> > dependencies that fixes CVEs that showed up since 8.0.6 release ?
>
> It'll definitely contain the latest CXF as many of the TCK failures were 
> there.  We're actually building against the unreleased 3.5.0-SNAPSHOT, but 
> hopefully we can back that down to the last release, 3.4.3. I don't know the 
> status of the Tomcat version as I've not been doing those TCK fixes, but I 
> suspect it's the latest latest.
>
> If anything is missed, we can roll a 8.0.8 immediately even as soon as 
> Tuesday.  Basically, if we don't get a release vote up in the 8 to 16 hours, 
> we'll miss the Jakarta EE 9.1 release window.
>
> -David
>
> >
> > Le dim. 2 mai 2021 à 19:09, David Blevins  a écrit :
> >>
> >>> On May 2, 2021, at 9:39 AM, Alex The Rocker  wrote:
> >>>
> >>> I am a bit confused : I thought that renaming of javax.* into
> >>> jakarta.* packages for the EE API is only targeted for TomEE 9.x.
> >>
> >> All the source code is in TomEE 8.0 and TomEE 9.0.x is just created 
> >> through bytecode transformation.  The long and short of that is they 
> >> pass/fail almost the exact same tests as it's the same code. We can do 
> >> library upgrades in the `tomee-jakarta` repo and add a patch file for 
> >> third-party dependencies here and there, but any fixes on the TomEE side 
> >> go into 8 and are automatically picked up in via bytecode transformation 
> >> of 9 as well.
> >>
> >> In fact, I've been doing most my local work exclusively running the 
> >> Jakarta EE 8 TCK and just letting the automated systems do the running of 
> >> the EE 9 TCK.
> >>
> >>> In such case, what would be the content of a TomEE 8.0.7 release?
> >>
> >> Everything in this list is fixed, except about 10 tests which are not part 
> >> of the Web Profile and therefore not required for certification and will 
> >> be fixed later.  Though it says "EE 9" these failed for both 8 and 9 TCKs:
> >>
> >> - https://issues.apache.org/jira/browse/TOMEE-3140
> >>
> >> We're still one TCK test shy of passing and have some work to do on the 
> >> API jars to pass the signature tests, but it's looking good.
> >>
> >> Brief pause for me to take a nap, however, as I've been up for 24 hours 
> >> and keep nodding off at the keyboard :)
> >>
> >>
> >> -David
> >>
> >>
> >>>
> >>> In any cases, I'd be happy to see a TomEE 8.0.7 release soon, in order
> >>> to get latest CVE fixes since 8.0.6.
> >>>
> >>> Kind regards,
> >>> Alexandre
> >>>
> >>> Le sam. 1 mai 2021 à 03:32, David Blevins  a 
> >>> écrit :
> 
>  Heads up that we are narrowing in in the last few TCK issues and there 
>  is still some chance we can be Jakarta EE 9.1 Web Profile certified in 
>  time for the Jakarta EE 9.1 release vote Monday.
> 
>  It would be super super and I mean *super* tight
> 
>  However, if we can get it done we'll need to do a release vote by no 
>  later than Sunday afternoon and file our certification request.  We 
>  don't need to have concluded our vote to make the Jakarta EE 9.1 release 
>  ballot, we just need final binaries of our own to be at least in staging 
>  and in the process of our own vote.
> 
>  We do need that vote pass, however, so that would require some 
>  pragmatism on all our parts.
> 
>  For that reason I recommend we do not try to push out a 9.0.0 final, but 
>  go ahead with 9.0.0-M7. If there are some issues with the binaries we 
>  put up for vote, unless they are legal issues, we can still release them 
>  and immediately fix the issues next week in a subsequent 8.0.8 and 
>  9.0.0-M8.  There's no reason to "wait", we can simply release twice.  
>  Version numbers are free.
> 
>  The Jakarta EE 9.1 release vote lasts for two weeks and an announcement 
>  would happen some days after that.  Ff we did want to push out a 9.0.0 
>  for the announcement, we'd have at least till May 17th to do that, 
>  perhaps even the 20th.
> 
>  The reason we want to get certified in time for the ballot is recently 
>  there was a change that implementations listed on the ballot get a 
>  special place at the top of the specification page.  Any implementations 
>  that come even one day later cannot be included and will not be accepted 
>  or given special designation.  This lasts forever and is a permanent 
>  advantage to those in the list.  It's also a permanent *disadvantage* to 
>  those not on the list.  It's eat or be eaten.
> 
>  So that's what we're going for:  A staged binary up for a vote here, 
>  passing the TCK, in time to 

Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-02 Thread David Blevins
> On May 2, 2021, at 10:22 AM, Alex The Rocker  wrote:
> 
> Hi David,
> 
> Thanks for your answer, this is perfectly clear.
> 
> Will this upcoming TomEE 8.0.7 release include latest Tomcat / CXF
> dependencies that fixes CVEs that showed up since 8.0.6 release ?

It'll definitely contain the latest CXF as many of the TCK failures were there. 
 We're actually building against the unreleased 3.5.0-SNAPSHOT, but hopefully 
we can back that down to the last release, 3.4.3. I don't know the status of 
the Tomcat version as I've not been doing those TCK fixes, but I suspect it's 
the latest latest.

If anything is missed, we can roll a 8.0.8 immediately even as soon as Tuesday. 
 Basically, if we don't get a release vote up in the 8 to 16 hours, we'll miss 
the Jakarta EE 9.1 release window.

-David

> 
> Le dim. 2 mai 2021 à 19:09, David Blevins  a écrit :
>> 
>>> On May 2, 2021, at 9:39 AM, Alex The Rocker  wrote:
>>> 
>>> I am a bit confused : I thought that renaming of javax.* into
>>> jakarta.* packages for the EE API is only targeted for TomEE 9.x.
>> 
>> All the source code is in TomEE 8.0 and TomEE 9.0.x is just created through 
>> bytecode transformation.  The long and short of that is they pass/fail 
>> almost the exact same tests as it's the same code. We can do library 
>> upgrades in the `tomee-jakarta` repo and add a patch file for third-party 
>> dependencies here and there, but any fixes on the TomEE side go into 8 and 
>> are automatically picked up in via bytecode transformation of 9 as well.
>> 
>> In fact, I've been doing most my local work exclusively running the Jakarta 
>> EE 8 TCK and just letting the automated systems do the running of the EE 9 
>> TCK.
>> 
>>> In such case, what would be the content of a TomEE 8.0.7 release?
>> 
>> Everything in this list is fixed, except about 10 tests which are not part 
>> of the Web Profile and therefore not required for certification and will be 
>> fixed later.  Though it says "EE 9" these failed for both 8 and 9 TCKs:
>> 
>> - https://issues.apache.org/jira/browse/TOMEE-3140
>> 
>> We're still one TCK test shy of passing and have some work to do on the API 
>> jars to pass the signature tests, but it's looking good.
>> 
>> Brief pause for me to take a nap, however, as I've been up for 24 hours and 
>> keep nodding off at the keyboard :)
>> 
>> 
>> -David
>> 
>> 
>>> 
>>> In any cases, I'd be happy to see a TomEE 8.0.7 release soon, in order
>>> to get latest CVE fixes since 8.0.6.
>>> 
>>> Kind regards,
>>> Alexandre
>>> 
>>> Le sam. 1 mai 2021 à 03:32, David Blevins  a écrit 
>>> :
 
 Heads up that we are narrowing in in the last few TCK issues and there is 
 still some chance we can be Jakarta EE 9.1 Web Profile certified in time 
 for the Jakarta EE 9.1 release vote Monday.
 
 It would be super super and I mean *super* tight
 
 However, if we can get it done we'll need to do a release vote by no later 
 than Sunday afternoon and file our certification request.  We don't need 
 to have concluded our vote to make the Jakarta EE 9.1 release ballot, we 
 just need final binaries of our own to be at least in staging and in the 
 process of our own vote.
 
 We do need that vote pass, however, so that would require some pragmatism 
 on all our parts.
 
 For that reason I recommend we do not try to push out a 9.0.0 final, but 
 go ahead with 9.0.0-M7. If there are some issues with the binaries we put 
 up for vote, unless they are legal issues, we can still release them and 
 immediately fix the issues next week in a subsequent 8.0.8 and 9.0.0-M8.  
 There's no reason to "wait", we can simply release twice.  Version numbers 
 are free.
 
 The Jakarta EE 9.1 release vote lasts for two weeks and an announcement 
 would happen some days after that.  Ff we did want to push out a 9.0.0 for 
 the announcement, we'd have at least till May 17th to do that, perhaps 
 even the 20th.
 
 The reason we want to get certified in time for the ballot is recently 
 there was a change that implementations listed on the ballot get a special 
 place at the top of the specification page.  Any implementations that come 
 even one day later cannot be included and will not be accepted or given 
 special designation.  This lasts forever and is a permanent advantage to 
 those in the list.  It's also a permanent *disadvantage* to those not on 
 the list.  It's eat or be eaten.
 
 So that's what we're going for:  A staged binary up for a vote here, 
 passing the TCK, in time to be listed on the Jakarta EE 9.1 release ballot 
 Monday.
 
 
 -David
 
>> 



Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-02 Thread Alex The Rocker
Hi David,

Thanks for your answer, this is perfectly clear.

Will this upcoming TomEE 8.0.7 release include latest Tomcat / CXF
dependencies that fixes CVEs that showed up since 8.0.6 release ?

Kind regards,
Alexandre

Le dim. 2 mai 2021 à 19:09, David Blevins  a écrit :
>
> > On May 2, 2021, at 9:39 AM, Alex The Rocker  wrote:
> >
> > I am a bit confused : I thought that renaming of javax.* into
> > jakarta.* packages for the EE API is only targeted for TomEE 9.x.
>
> All the source code is in TomEE 8.0 and TomEE 9.0.x is just created through 
> bytecode transformation.  The long and short of that is they pass/fail almost 
> the exact same tests as it's the same code. We can do library upgrades in the 
> `tomee-jakarta` repo and add a patch file for third-party dependencies here 
> and there, but any fixes on the TomEE side go into 8 and are automatically 
> picked up in via bytecode transformation of 9 as well.
>
> In fact, I've been doing most my local work exclusively running the Jakarta 
> EE 8 TCK and just letting the automated systems do the running of the EE 9 
> TCK.
>
> > In such case, what would be the content of a TomEE 8.0.7 release?
>
> Everything in this list is fixed, except about 10 tests which are not part of 
> the Web Profile and therefore not required for certification and will be 
> fixed later.  Though it says "EE 9" these failed for both 8 and 9 TCKs:
>
>  - https://issues.apache.org/jira/browse/TOMEE-3140
>
> We're still one TCK test shy of passing and have some work to do on the API 
> jars to pass the signature tests, but it's looking good.
>
> Brief pause for me to take a nap, however, as I've been up for 24 hours and 
> keep nodding off at the keyboard :)
>
>
> -David
>
>
> >
> > In any cases, I'd be happy to see a TomEE 8.0.7 release soon, in order
> > to get latest CVE fixes since 8.0.6.
> >
> > Kind regards,
> > Alexandre
> >
> > Le sam. 1 mai 2021 à 03:32, David Blevins  a écrit 
> > :
> >>
> >> Heads up that we are narrowing in in the last few TCK issues and there is 
> >> still some chance we can be Jakarta EE 9.1 Web Profile certified in time 
> >> for the Jakarta EE 9.1 release vote Monday.
> >>
> >> It would be super super and I mean *super* tight
> >>
> >> However, if we can get it done we'll need to do a release vote by no later 
> >> than Sunday afternoon and file our certification request.  We don't need 
> >> to have concluded our vote to make the Jakarta EE 9.1 release ballot, we 
> >> just need final binaries of our own to be at least in staging and in the 
> >> process of our own vote.
> >>
> >> We do need that vote pass, however, so that would require some pragmatism 
> >> on all our parts.
> >>
> >> For that reason I recommend we do not try to push out a 9.0.0 final, but 
> >> go ahead with 9.0.0-M7. If there are some issues with the binaries we put 
> >> up for vote, unless they are legal issues, we can still release them and 
> >> immediately fix the issues next week in a subsequent 8.0.8 and 9.0.0-M8.  
> >> There's no reason to "wait", we can simply release twice.  Version numbers 
> >> are free.
> >>
> >> The Jakarta EE 9.1 release vote lasts for two weeks and an announcement 
> >> would happen some days after that.  Ff we did want to push out a 9.0.0 for 
> >> the announcement, we'd have at least till May 17th to do that, perhaps 
> >> even the 20th.
> >>
> >> The reason we want to get certified in time for the ballot is recently 
> >> there was a change that implementations listed on the ballot get a special 
> >> place at the top of the specification page.  Any implementations that come 
> >> even one day later cannot be included and will not be accepted or given 
> >> special designation.  This lasts forever and is a permanent advantage to 
> >> those in the list.  It's also a permanent *disadvantage* to those not on 
> >> the list.  It's eat or be eaten.
> >>
> >> So that's what we're going for:  A staged binary up for a vote here, 
> >> passing the TCK, in time to be listed on the Jakarta EE 9.1 release ballot 
> >> Monday.
> >>
> >>
> >> -David
> >>
>


Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-02 Thread David Blevins
> On May 2, 2021, at 9:39 AM, Alex The Rocker  wrote:
> 
> I am a bit confused : I thought that renaming of javax.* into
> jakarta.* packages for the EE API is only targeted for TomEE 9.x.

All the source code is in TomEE 8.0 and TomEE 9.0.x is just created through 
bytecode transformation.  The long and short of that is they pass/fail almost 
the exact same tests as it's the same code. We can do library upgrades in the 
`tomee-jakarta` repo and add a patch file for third-party dependencies here and 
there, but any fixes on the TomEE side go into 8 and are automatically picked 
up in via bytecode transformation of 9 as well.

In fact, I've been doing most my local work exclusively running the Jakarta EE 
8 TCK and just letting the automated systems do the running of the EE 9 TCK.

> In such case, what would be the content of a TomEE 8.0.7 release?

Everything in this list is fixed, except about 10 tests which are not part of 
the Web Profile and therefore not required for certification and will be fixed 
later.  Though it says "EE 9" these failed for both 8 and 9 TCKs:

 - https://issues.apache.org/jira/browse/TOMEE-3140

We're still one TCK test shy of passing and have some work to do on the API 
jars to pass the signature tests, but it's looking good.

Brief pause for me to take a nap, however, as I've been up for 24 hours and 
keep nodding off at the keyboard :)


-David


> 
> In any cases, I'd be happy to see a TomEE 8.0.7 release soon, in order
> to get latest CVE fixes since 8.0.6.
> 
> Kind regards,
> Alexandre
> 
> Le sam. 1 mai 2021 à 03:32, David Blevins  a écrit :
>> 
>> Heads up that we are narrowing in in the last few TCK issues and there is 
>> still some chance we can be Jakarta EE 9.1 Web Profile certified in time for 
>> the Jakarta EE 9.1 release vote Monday.
>> 
>> It would be super super and I mean *super* tight
>> 
>> However, if we can get it done we'll need to do a release vote by no later 
>> than Sunday afternoon and file our certification request.  We don't need to 
>> have concluded our vote to make the Jakarta EE 9.1 release ballot, we just 
>> need final binaries of our own to be at least in staging and in the process 
>> of our own vote.
>> 
>> We do need that vote pass, however, so that would require some pragmatism on 
>> all our parts.
>> 
>> For that reason I recommend we do not try to push out a 9.0.0 final, but go 
>> ahead with 9.0.0-M7. If there are some issues with the binaries we put up 
>> for vote, unless they are legal issues, we can still release them and 
>> immediately fix the issues next week in a subsequent 8.0.8 and 9.0.0-M8.  
>> There's no reason to "wait", we can simply release twice.  Version numbers 
>> are free.
>> 
>> The Jakarta EE 9.1 release vote lasts for two weeks and an announcement 
>> would happen some days after that.  Ff we did want to push out a 9.0.0 for 
>> the announcement, we'd have at least till May 17th to do that, perhaps even 
>> the 20th.
>> 
>> The reason we want to get certified in time for the ballot is recently there 
>> was a change that implementations listed on the ballot get a special place 
>> at the top of the specification page.  Any implementations that come even 
>> one day later cannot be included and will not be accepted or given special 
>> designation.  This lasts forever and is a permanent advantage to those in 
>> the list.  It's also a permanent *disadvantage* to those not on the list.  
>> It's eat or be eaten.
>> 
>> So that's what we're going for:  A staged binary up for a vote here, passing 
>> the TCK, in time to be listed on the Jakarta EE 9.1 release ballot Monday.
>> 
>> 
>> -David
>> 



Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-02 Thread Alex The Rocker
I am a bit confused : I thought that renaming of javax.* into
jakarta.* packages for the EE API is only targeted for TomEE 9.x.

In such case, what would be the content of a TomEE 8.0.7 release?

In any cases, I'd be happy to see a TomEE 8.0.7 release soon, in order
to get latest CVE fixes since 8.0.6.

Kind regards,
Alexandre

Le sam. 1 mai 2021 à 03:32, David Blevins  a écrit :
>
> Heads up that we are narrowing in in the last few TCK issues and there is 
> still some chance we can be Jakarta EE 9.1 Web Profile certified in time for 
> the Jakarta EE 9.1 release vote Monday.
>
> It would be super super and I mean *super* tight
>
> However, if we can get it done we'll need to do a release vote by no later 
> than Sunday afternoon and file our certification request.  We don't need to 
> have concluded our vote to make the Jakarta EE 9.1 release ballot, we just 
> need final binaries of our own to be at least in staging and in the process 
> of our own vote.
>
> We do need that vote pass, however, so that would require some pragmatism on 
> all our parts.
>
> For that reason I recommend we do not try to push out a 9.0.0 final, but go 
> ahead with 9.0.0-M7. If there are some issues with the binaries we put up for 
> vote, unless they are legal issues, we can still release them and immediately 
> fix the issues next week in a subsequent 8.0.8 and 9.0.0-M8.  There's no 
> reason to "wait", we can simply release twice.  Version numbers are free.
>
> The Jakarta EE 9.1 release vote lasts for two weeks and an announcement would 
> happen some days after that.  Ff we did want to push out a 9.0.0 for the 
> announcement, we'd have at least till May 17th to do that, perhaps even the 
> 20th.
>
> The reason we want to get certified in time for the ballot is recently there 
> was a change that implementations listed on the ballot get a special place at 
> the top of the specification page.  Any implementations that come even one 
> day later cannot be included and will not be accepted or given special 
> designation.  This lasts forever and is a permanent advantage to those in the 
> list.  It's also a permanent *disadvantage* to those not on the list.  It's 
> eat or be eaten.
>
> So that's what we're going for:  A staged binary up for a vote here, passing 
> the TCK, in time to be listed on the Jakarta EE 9.1 release ballot Monday.
>
>
> -David
>


Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-01 Thread David Blevins
Status update:

 - We're down to our last 7 failures on the general portion of the EE 9.1 TCK.  
Jean-Louis and I are on it.
 - 3 jaxrs
 - 1 servlet
 - 1 securityapi
 - 2 websocket
  
 - We have the signature tests to configure and run still and there will be 
failures there, but they should be easy to correct.  Jon is currently looking 
at this.

 - Jakarta CDI and @Inject standalone TCKs are all in good shape as those are 
setup and run against the CDI 3.0.0 TCK in OpenWebBeans 

 - Jakarta Debugging Support for Other Languages 2.0 TCK is passing.  Thanks, 
Cesar!

 - Jakarta XML Binding 3.0 TCK results will be obtained from the Eclipse JAXB 
implementation.

 - Jakarta Bean Validation 3.0.0 TCK results against Apache BVal needs 
considerable more work and won't be ready for tomorrow.  Jon spent a good 26 
hours on it and could get many tests passing, but there appear to be issues 
with the bytecode transformation.  As such TomEE 9 Plume has been momentarily 
switched to Hibernate Validator which is Apache License v2 and safe to ship.  
We'll use that to certify so we have time invest in getting Apache BVal to be 
Jakarta Bean Validation 3.0 compliant and can switch Plume back to Apache BVal.

If all the above can land in the next 24 hours, we'll be able to start the 
release process at this same time tomorrow and not just be certified for the 
first time since Java EE 6, but be included in the Jakarta EE 9.1 release 
itself!

If we can make this happen, it will be the biggest milestone this project has 
crossed since the Java EE 6 Web Profile certification of TomEE 1.0.0-M1 in 
October, 2011.

On a related note, Jean-Louis and myself are also responsible for conducting 
the actual Jakarta EE 9.1 release ballot over on the Eclipse side.  Needless to 
say, it's a historic moment for the project and we should all be so incredibly 
proud.

Let's make this happen!  We can do this!


-David



smime.p7s
Description: S/MIME cryptographic signature


Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-05-01 Thread Gurkan Erdogdu
Skip my previous question.
Regards.
Gurkan

On Sat, May 1, 2021 at 8:57 AM Gurkan Erdogdu  wrote:

> AFAIK, (please correct me if I am wrong), ASF is not a member of the
> Jakarta EE working group and is not able to get certified. How will TomEE
> get certified?
> Because of this, Tomcat is not able to be listed in certification pages of
> Servlet specification.
>
> Regards.
> Gurkan
>
> On Sat, May 1, 2021 at 4:32 AM David Blevins 
> wrote:
>
>> Heads up that we are narrowing in in the last few TCK issues and there is
>> still some chance we can be Jakarta EE 9.1 Web Profile certified in time
>> for the Jakarta EE 9.1 release vote Monday.
>>
>> It would be super super and I mean *super* tight
>>
>> However, if we can get it done we'll need to do a release vote by no
>> later than Sunday afternoon and file our certification request.  We don't
>> need to have concluded our vote to make the Jakarta EE 9.1 release ballot,
>> we just need final binaries of our own to be at least in staging and in the
>> process of our own vote.
>>
>> We do need that vote pass, however, so that would require some pragmatism
>> on all our parts.
>>
>> For that reason I recommend we do not try to push out a 9.0.0 final, but
>> go ahead with 9.0.0-M7. If there are some issues with the binaries we put
>> up for vote, unless they are legal issues, we can still release them and
>> immediately fix the issues next week in a subsequent 8.0.8 and 9.0.0-M8.
>> There's no reason to "wait", we can simply release twice.  Version numbers
>> are free.
>>
>> The Jakarta EE 9.1 release vote lasts for two weeks and an announcement
>> would happen some days after that.  Ff we did want to push out a 9.0.0 for
>> the announcement, we'd have at least till May 17th to do that, perhaps even
>> the 20th.
>>
>> The reason we want to get certified in time for the ballot is recently
>> there was a change that implementations listed on the ballot get a special
>> place at the top of the specification page.  Any implementations that come
>> even one day later cannot be included and will not be accepted or given
>> special designation.  This lasts forever and is a permanent advantage to
>> those in the list.  It's also a permanent *disadvantage* to those not on
>> the list.  It's eat or be eaten.
>>
>> So that's what we're going for:  A staged binary up for a vote here,
>> passing the TCK, in time to be listed on the Jakarta EE 9.1 release ballot
>> Monday.
>>
>>
>> -David
>>
>>


Re: Potential release vote for 8.0.7 and 9.0.0-M7

2021-04-30 Thread Gurkan Erdogdu
AFAIK, (please correct me if I am wrong), ASF is not a member of the
Jakarta EE working group and is not able to get certified. How will TomEE
get certified?
Because of this, Tomcat is not able to be listed in certification pages of
Servlet specification.

Regards.
Gurkan

On Sat, May 1, 2021 at 4:32 AM David Blevins 
wrote:

> Heads up that we are narrowing in in the last few TCK issues and there is
> still some chance we can be Jakarta EE 9.1 Web Profile certified in time
> for the Jakarta EE 9.1 release vote Monday.
>
> It would be super super and I mean *super* tight
>
> However, if we can get it done we'll need to do a release vote by no later
> than Sunday afternoon and file our certification request.  We don't need to
> have concluded our vote to make the Jakarta EE 9.1 release ballot, we just
> need final binaries of our own to be at least in staging and in the process
> of our own vote.
>
> We do need that vote pass, however, so that would require some pragmatism
> on all our parts.
>
> For that reason I recommend we do not try to push out a 9.0.0 final, but
> go ahead with 9.0.0-M7. If there are some issues with the binaries we put
> up for vote, unless they are legal issues, we can still release them and
> immediately fix the issues next week in a subsequent 8.0.8 and 9.0.0-M8.
> There's no reason to "wait", we can simply release twice.  Version numbers
> are free.
>
> The Jakarta EE 9.1 release vote lasts for two weeks and an announcement
> would happen some days after that.  Ff we did want to push out a 9.0.0 for
> the announcement, we'd have at least till May 17th to do that, perhaps even
> the 20th.
>
> The reason we want to get certified in time for the ballot is recently
> there was a change that implementations listed on the ballot get a special
> place at the top of the specification page.  Any implementations that come
> even one day later cannot be included and will not be accepted or given
> special designation.  This lasts forever and is a permanent advantage to
> those in the list.  It's also a permanent *disadvantage* to those not on
> the list.  It's eat or be eaten.
>
> So that's what we're going for:  A staged binary up for a vote here,
> passing the TCK, in time to be listed on the Jakarta EE 9.1 release ballot
> Monday.
>
>
> -David
>
>