[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cu-dev] [jakartaee-platform-dev] Latest CU results with Eclipse GlassFish
|
Hello all, sorry for not watching the list.
I uploaded the version 3.0.1 to the maven central. 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.
Petr
On 8/30/22 14:50, Steve Millidge
(Payara) wrote:
No
idea but 3.0.1 is on maven central and I definitely didn’t
do it manually see
jakarta.enterprise.concurrent :
jakarta.enterprise.concurrent-tck : 3.0.1 - Maven Central
Repository Search
Steve
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:
scp
${SSH_OPTS}
${BUILD_TARGET}/concurrency-tck-${TCK_VERSION}-dist.zip
${SSH_HOST}:${STAGING_PATH}/concurrency-tck-${TCK_VERSION}.zip
scp ${SSH_OPTS}
${BUILD_TARGET}/concurrency-tck-${TCK_VERSION}.info
${SSH_HOST}:${STAGING_PATH}
ssh ${SSH_OPTS} ${SSH_HOST} ls -al ${STAGING_PATH}
Then the
second job is staging to promoted, which copies the TCK
from the staging location to the promoted location:
(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.
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.
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
|
This
Message Is
From an
External
Sender
|
|
This
message came
from outside
your
organization.
|
|
|
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.
Jobs have indeed been
renamed on the CI btw, and the name
is now consistent with those on most
other EE4J/Jakarta EE CI instances.
On 8/23/22 9:46 AM,
Nathan Rauh wrote:
Have all of the
issues running the TCK on
Glassfish been resolved, and
if so, can a 3.0.2 release of
Concurrency be created and
promoted?
Yes, see results
https://github.com/eclipse-ee4j/jakartaee-tck/wiki/Jakarta-EE-10.0-TCK-results
(thanks Guru!) which show the
staged Concurrency TCK (3.0.2) is
passing on both JDK 11 (as of
today) + JDK 17 (as of yesterday).
To confirm, I opened
https://ci.eclipse.org/jakartaee-tck/job/10/job/jakarta-concurrency-tck-glassfish-run/118/consoleFull
and see that
https://download.eclipse.org/ee4j/cu/jakartaee10/staged/eftl/concurrency-tck-3.0.2.zip
was used for the testing.
Scott
The Jenkins jobs
all look different from when I
last looked at them from the
3.0.0 release, but this one
appears to have a 3.0.2 build
of the TCK from August 9,
https://ci.eclipse.org/cu/job/concurrency_tck_1-build-and-stage/
|
This
Message Is
From an
External
Sender
|
|
This
message came
from outside
your
organization.
|
|
|
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 for
review` and when approved,
then merged in.
Then
https://ci.eclipse.org/jakartaee-tck/job/10/job/jakarta-concurrency-tck-glassfish-run
+
https://ci.eclipse.org/jakartaee-tck/job/10/job/jakarta-concurrency-tck-glassfish-run-jdk17
can be updated to run both the
`suite-web.xml` (won't run
currently failing test) +
`suite-web-group2.xml` (will
run currently failing test in
isolation from other tests)
separately, at least that is
the idea.
Scott
On 8/11/22
11:38 AM, Scott Marlow
wrote:
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.
Any volunteers
to update
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/glassfish-runner/concurrency-tck/suite-web.xml
(+ rename to
suite-web-group1.xml) to
exclude the
`ee.jakarta.tck.concurrent.spec.ManagedExecutorService.resourcedef.ManagedExecutorDefinitionWebTests.testCopyCompletableFutureEJB`
test and add a
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/glassfish-runner/concurrency-tck/suite-web-group2.xml
that does run
`ee.jakarta.tck.concurrent.spec.ManagedExecutorService.resourcedef.ManagedExecutorDefinitionWebTests.testCopyCompletableFutureEJB`?
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.
Cheers,
-- Ed
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
