You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2021/05/01 01:32:14 UTC
Potential release vote for 8.0.7 and 9.0.0-M7
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
Posted by "Wiesner, Martin" <ma...@hs-heilbronn.de>.
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 <da...@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 <da...@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
Posted by Daniel Dias Dos Santos <da...@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 <da...@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
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Skip my previous question.
Regards.
Gurkan
On Sat, May 1, 2021 at 8:57 AM Gurkan Erdogdu <cg...@gmail.com> 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 <da...@gmail.com>
> 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
Posted by Gurkan Erdogdu <cg...@gmail.com>.
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 <da...@gmail.com>
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
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
+1
LieGrue,strub
On Monday, 3 May 2021, 11:30:50 CEST, Alex The Rocker <al...@gmail.com> 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 <da...@gmail.com> a écrit :
>
> Dear Community.
>
> The time has come :)
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Posted by Alex The Rocker <al...@gmail.com>.
+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 <da...@gmail.com> a écrit :
>
> Dear Community.
>
> The time has come :)
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Posted by David Blevins <da...@gmail.com>.
Dear Community.
The time has come :)
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
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 <db...@tomitribe.com> a
> écrit :
> > > On May 2, 2021, at 9:39 AM, Alex The Rocker <alex.m3tal@gmail.com
> > > > 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.blevins@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.zowalla@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Posted by Alex The Rocker <al...@gmail.com>.
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 <db...@tomitribe.com> a écrit :
>
> > On May 2, 2021, at 10:22 AM, Alex The Rocker <al...@gmail.com> 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 <db...@tomitribe.com> a écrit :
> >>
> >>> On May 2, 2021, at 9:39 AM, Alex The Rocker <al...@gmail.com> 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 <da...@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
> >>>>
> >>
>
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Posted by David Blevins <db...@tomitribe.com>.
> On May 2, 2021, at 10:22 AM, Alex The Rocker <al...@gmail.com> 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 <db...@tomitribe.com> a écrit :
>>
>>> On May 2, 2021, at 9:39 AM, Alex The Rocker <al...@gmail.com> 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 <da...@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
>>>>
>>
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Posted by Alex The Rocker <al...@gmail.com>.
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 <db...@tomitribe.com> a écrit :
>
> > On May 2, 2021, at 9:39 AM, Alex The Rocker <al...@gmail.com> 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 <da...@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
> >>
>
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Posted by David Blevins <db...@tomitribe.com>.
> On May 2, 2021, at 9:39 AM, Alex The Rocker <al...@gmail.com> 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 <da...@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
>>
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Posted by Alex The Rocker <al...@gmail.com>.
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 <da...@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
>
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Posted by David Blevins <da...@gmail.com>.
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