I uploaded the version 3.0.1 to the maven central.
Do you mean API 3.0.1, or TCK 3.0.1?
The files inside jars were created on 11. 7. 2022 at 18:17-18,
obviously by the same script. So I suppose the job published both
api and tck.
I did it via job "concurrency-api-release-build" in https://ci.eclipse.org/cu/.
For some reason, this job is no more present and I don't
see, what is its new name. I don't have privileges to
see deleted jobs.
That job was renamed to
"concurrency_api_1-build-and-stage", since what it did was
building the API and then staging it.
The job's history doesn't contain the script I was running. I
suppose it was created as a new one and the content was copied,
the old job deleted. As I don't see deleted jobs, I cannot say,
what was exactly executed.
Petr
From staging to release (maven central) is
"concurrency_api_3-staging-to-release".
Note that this is the name pattern used by most other
EE4J CIs.
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx>On Behalf Of arjan tijms Sent: 30 August 2022 13:25 To: cu developer discussions <cu-dev@xxxxxxxxxxx> Subject: Re: [cu-dev]
[jakartaee-platform-dev] Latest CU results with
Eclipse GlassFish
As far
as I can see, there were/are only two jobs dealing
with the TCK.
There's
tck build and stage, which does what the name
implies. It first builds the TCK, then stages it
using:
(I
just noticed the jobs hardcode version numbers,
which we should replace by a placeholder).
At a
glance, no other jobs contain anything related
to the TCK. There's a bunch of ancient jobs that
havent been run in years and that I haven't
looked at. Seems unlikely though they had been
used before.
At
any length, ideally we first add an option to
build the EPL version of the TCK (which only
differs in its license file), and then simply
add deploy code to push that to sonatype staging
(can copy from the API job).
There was a job
to do this. Not sure what it called now.
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx>
On Behalf Of arjan tijms Sent: 30 August 2022 12:42 To: Nathan Rauh <nathan.rauh@xxxxxxxxxx> Cc: cu developer discussions
<cu-dev@xxxxxxxxxxx> Subject: Re: [cu-dev]
[jakartaee-platform-dev] Latest CU
results with Eclipse GlassFish
Hi,
We haven't
introduced any job (or code within a
job) afaik to generate an EPL version
and stage (and subsequently push) to
maven. I'm not sure how that was done
before. Did someone do it locally on
their system, or perhaps manually in
some way?
Of course we
can add/update a job to do this, but
as said it doesn't seem to be there
now.
Thanks! Are we
now at a point where we can
run the job (I think this
one) to push the 3.0.2
TCK and API jars to Maven?
That will also some vendors to
start using the 3.0.2 TCK in
automated test.
From: arjan tijms <arjan.tijms@xxxxxxxxx> Date: Thursday,
August 25, 2022 at 3:41 AM To: cu developer
discussions <cu-dev@xxxxxxxxxxx> Cc: Nathan Rauh <nathan.rauh@xxxxxxxxxx> Subject: [EXTERNAL]
Re: [cu-dev]
[jakartaee-platform-dev]
Latest CU results with
Eclipse GlassFish
Hi, Following
discussion and
subsequent requests in the
platform call, the 3. 0. 1
and 3. 0. 2 TCKs were added
to the specification page,
and the 3. 0. 2 TCK as
previously in staging was
promoted.
See https: //github. com/jakartaee/specifications/pull/531
ZjQcmQRYFpfptBannerStart
This
Message Is
From an
External
Sender
This
message came
from outside
your
organization.
ZjQcmQRYFpfptBannerEnd
Hi,
Following
discussion and
subsequent requests in the
platform call, the 3.0.1
and 3.0.2 TCKs were added
to the specification page,
and the 3.0.2 TCK as
previously in staging was
promoted.
We will test with draft
pull request
https://github.com/eclipse-ee4j/jakartaee-tck/pull/1111 If the test
shows that
GlassFish can pass
the Concurrency
TCK tests in Web
Profile mode, one
of the committers
can update the PR
from draft to
`Ready
If the
test shows that
GlassFish can pass
the Concurrency TCK
tests in Web Profile
mode, one of the
committers can
update the PR from
draft to `Ready for
review` and when
approved, then
merged in.
Since
no one has spoken
up against running
the
`ee.jakarta.tck.concurrent.spec.ManagedExecutorService.resourcedef.ManagedExecutorDefinitionWebTests.testCopyCompletableFutureEJB`
test separately, I
think we should
try that in our
Platform TCK CI
environment.
Then
we just need to
invoke the
suite-web-group1.xml
tests first and
then the
suite-web-group2.xml
tests (perhaps
just copy each of
these files to
suite-web.xml and
run Web Profile
tests). Or if you
have a better way,
that is fine also.
Scott
On 8/11/22 8:33 AM, Scott
Marlow wrote:
Ed,
Thanks
for sending this
note.
I
find Ondro's comment to be very
interesting in
that we may have
a workaround of
running the
ee.jakarta.tck.concurrent.spec.ManagedExecutorService.resourcedef.ManagedExecutorDefinitionWebTests.testCopyCompletableFutureEJB
test separately
so it won't
fail.
That
sounds like a
valid workaround
to me. If
anyone disagrees
please comment
on the issue as to why.
Scott
On 8/10/22 11:17 AM, Ed
Bratt wrote:
In
the Platform
Committer team
meeting
yesterday, we
were
discussing the
latest updates
with
Concurrency
Utilities and
the impact on
Eclipse
GlassFish 7.
The
revised CU TCK
(3.0.2) was
run against
GlassFish 7
(latest
snapshot) and
there is still
one test
failure. The
issue
discription is
captured in GlassFish Issue 24509. GlassFish and TCK
teams are
currently
working to
determine if
this is an
issue that can
be resolved in
GlassFish.
You
can view the
latest status
via the issue
conversation.