Yes, I saw the JavaDocs
on staging so we can use the official copy.
That's good to
know you built the specification doc locally last time and they accepted
that. Then we can plan to do the same for 3.0.
Thanks again!
From:
"Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:
"Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>, "Nathan
Rauh" <nathan.rauh@xxxxxxxxxx>, "Dmitry Kornilov"
<dmitry.kornilov@xxxxxxxxxx>, "Ed Bratt" <ed.bratt@xxxxxxxxxx>,
"Maxim Nesen" <maxim.nesen@xxxxxxxxxx>
Cc:
"cu
developer discussions" <cu-dev@xxxxxxxxxxx>
Date:
01/21/2022
09:47 AM
Subject:
[EXTERNAL]
RE: [cu-dev] : RE: Checking in -- progress towards finishing Concurrency
Utilities 3.0?
Forgot to add for the javadocs
I downloaded and extracted the staged Javadoc jar in the correct place
to make the spec PR. From: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Sent: 21 January 2022 15:45 ZjQcmQRYFpfptBannerStart
This Message Is
>From an External Sender This
message came from outside your organization.
ZjQcmQRYFpfptBannerEndForgot
to add for the javadocs I downloaded and extracted the staged Javadoc
jar in the correct place to make the spec PR.
From:Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Sent: 21 January 2022 15:45
To: Nathan Rauh <nathan.rauh@xxxxxxxxxx>; Steve Millidge (Payara)
<steve.millidge@xxxxxxxxxxx>; Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>;
Ed Bratt <ed.bratt@xxxxxxxxxx>; Maxim Nesen <maxim.nesen@xxxxxxxxxx>
Cc: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: RE: [cu-dev] : RE: Checking in -- progress towards finishing
Concurrency Utilities 3.0?
Previously
I think I built them locally and created the PR to the specifications repository
using the locally build PDF and html document.
From:Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 21 January 2022 15:26
To: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>;
Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>;
Ed Bratt <ed.bratt@xxxxxxxxxx>;
Maxim Nesen <maxim.nesen@xxxxxxxxxx>
Cc: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: RE: [cu-dev] : RE: Checking in -- progress towards finishing
Concurrency Utilities 3.0?
For
the release review, we will need to provide a PDF and HTML of the specification
document, as indicated in checkboxes 2 and 3 of the checklist/template,
https://github.com/jakartaee/specifications/blob/master/pull_request_template.md
·
Specification
PDF in the form of jakarta-wombat-spec-x.y.pdf
·
Specification
HTML in the form of jakarta-wombat-spec-x.y.html
As far as I can tell, the release build
https://ci.eclipse.org/cu/view/Release/job/concurrency-api-release-build/64/
and its output to sonatype staging
https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/enterprise/concurrent/
does not include the Specification document. Do these need to be
obtained in an official manner (from a release build) ? Or is it
sufficient to produce them by building
concurrency-api/specification with mvn install and supply that? If
they do need to be obtained from a release build, where do I find these
outputs or is further work needed on the Jenkins job or parent pom in order
to produce them?
From: "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: "Nathan
Rauh" <nathan.rauh@xxxxxxxxxx>,
"cu developer discussions" <cu-dev@xxxxxxxxxxx>
Cc: "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>,
"Dmitry Kornilov" <dmitry.kornilov@xxxxxxxxxx>,
"Ed Bratt" <ed.bratt@xxxxxxxxxx>,
"Maxim Nesen" <maxim.nesen@xxxxxxxxxx>,
"Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Date: 01/19/2022
02:00 PM
Subject: [EXTERNAL]
RE: [cu-dev] : RE: Checking in -- progress towards finishing Concurrency
Utilities 3.0?
Hi Nathan, I’ve modified the job so the TCK now shows up. The job was
previously doing a cd into api directory to find the pom. Now it is using
the parent pom. Jakarta Concurrency - Concurrency API master build #75
[Jenkins] (eclipse.org) ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This
message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi
Nathan,
I’ve
modified the job so the TCK now shows up. The job was previously doing
a cd into api directory to find the pom. Now it is using the parent pom.
Jakarta
Concurrency - Concurrency API master build #75 [Jenkins] (eclipse.org)
Steve
From:Nathan
Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 19 January 2022 19:57
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: cu-dev <cu-dev-bounces@xxxxxxxxxxx>;
Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>;
Ed Bratt <ed.bratt@xxxxxxxxxx>;
Maxim Nesen <maxim.nesen@xxxxxxxxxx>;
Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Subject: RE: [cu-dev] : RE: Checking in -- progress towards finishing
Concurrency Utilities 3.0?
Unfortunately,
it still didn't pick up the TCK jar, even with the parent in place
https://ci.eclipse.org/cu/job/concurrency-api-master-build/74/
When I pulled in your latest changes from master and built it locally from
the top level, it does build both api and tck, with the generated tck jar
being properly placed under target,
tck/target/jakarta.enterprise.concurrent-tck-3.0.0-SNAPSHOT.jar
Under the configuration of Concurrency TCK Master Build, I see,
![](jpgq5IOHGeZeY.jpg)
which seems like it ought to equally match the tck jar as well as the api
jars, but only the ones from api show up, making me wonder if it really
built the tck when running in Jenkins.
From: "Nathan
Rauh" <nathan.rauh@xxxxxxxxxx>
To: "cu
developer discussions" <cu-dev@xxxxxxxxxxx>,
"Maxim Nesen" <maxim.nesen@xxxxxxxxxx>,
"Dmitry Kornilov" <dmitry.kornilov@xxxxxxxxxx>,
"Ed Bratt" <ed.bratt@xxxxxxxxxx>,
"Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Date: 01/19/2022
01:31 PM
Subject: [EXTERNAL]
Re: [cu-dev] : RE: Checking in -- progress towards finishing Concurrency
Utilities 3.0?
Sent by: "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>
Steve - thanks for fixing the Jenkins job and figuring out that the parent
pom is needed to get the TCK built. To answer your other question,
after you got the master api build working, I didn't see the tck jar show
up there. I approved and merged your pull to add the parent pom,
so hopefully it will include the tck jar now.
Does specification need to be included in the parent as a module as well?
It won't matter for running with the API and TCK, but just want to
be sure it won't get left out of the final spec.
From: "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: "cu
developer discussions" <cu-dev@xxxxxxxxxxx>
Date: 01/19/2022
12:35 PM
Subject: [EXTERNAL]
Re: [cu-dev] : RE: Checking in -- progress towards finishing Concurrency
Utilities 3.0?
Sent by: "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>
I
think we need a parent pom so we build api, tck and spec in one job. I
cloned the api master build job to build the tck but obviously it depends
on the api jar which it doesn’t have access to so it fails. Alternatively
now that master api build job is working again it would be possible to
push that to staging. However I think a parent pom to run all 3 or two
combine just api and tck would be better. Thoughts?
Steve
From:Nathan
Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 19 January 2022 16:26
To: Maxim Nesen <maxim.nesen@xxxxxxxxxx>;
Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>;
Ed Bratt <ed.bratt@xxxxxxxxxx>;
Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Cc: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: Re: : RE: [cu-dev] Checking in -- progress towards finishing
Concurrency Utilities 3.0?
As far as I'm aware,
there is just one remaining TCK pull expected (hopefully today) and after
that we should immediately get a 3.0.0 final build of both the api jar
and tck jar onto staging so that these can be pulled in to the Open Liberty
beta that will come out in February, which we can then use as the compatible
implementation.
I looked over these Jenkins jobs, and I'm worried that they either won't
pass or won't build the tck jar within the project, and will need more
updates, which will cause a delay that will make us miss the February beta
which is our shot at a compatible implementation. That said, I can
easily build all of these artifacts manually with mvn install and
run with these in Open Liberty where the whole TCK passes. Is there
a manual way to put artifacts built in this manner into staging, and would
that be valid? Or is anyone able to update/fix the Jenkins jobs to
successfully build the api and tck jars in an official form that can be
put onto staging as 3.0.0 final?
For reference, here is the error I currently see on recent Jenkins builds
of concurrency-api-master-build:
https://ci.eclipse.org/cu/job/concurrency-api-master-build/68/console
ERROR: Build step failed with exception
java.lang.IllegalStateException: ID java is already used by another action:
io.jenkins.plugins.analysis.core.model.ResultAction for Java Compiler
at io.jenkins.plugins.analysis.core.steps.IssuesPublisher.ensureThatIdIsUnique(IssuesPublisher.java:146)
at io.jenkins.plugins.analysis.core.steps.IssuesPublisher.attachAction(IssuesPublisher.java:97)
at io.jenkins.plugins.analysis.core.steps.IssuesRecorder.publishResult(IssuesRecorder.java:807)
at io.jenkins.plugins.analysis.core.steps.IssuesRecorder.record(IssuesRecorder.java:734)
at io.jenkins.plugins.analysis.core.steps.IssuesRecorder.perform(IssuesRecorder.java:697)
at io.jenkins.plugins.analysis.core.steps.IssuesRecorder.perform(IssuesRecorder.java:673)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:806)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:755)
at hudson.model.Build$BuildExecution.post2(Build.java:178)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:699)
at hudson.model.Run.execute(Run.java:1913)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:99)
at hudson.model.Executor.run(Executor.java:431)
Build step 'Record compiler warnings and static analysis results' marked
build as failure
Finished: FAILURE
Do we also need a concurrency-tck-master-build to build and package the
jakarta.enterprise.concurrent-tck-3.0.0.jar jar from the main concurrency-api
repo, or will concurrency-api-master-build do that for us once it is working
again?
From: Nathan
Rauh/Rochester/IBM
To: "Maxim
Nesen" <maxim.nesen@xxxxxxxxxx>
Cc: "cu
developer discussions" <cu-dev@xxxxxxxxxxx>,
"Dmitry Kornilov" <dmitry.kornilov@xxxxxxxxxx>,
"Ed Bratt" <ed.bratt@xxxxxxxxxx>,
"Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Date: 01/18/2022
09:29 AM
Subject: Re:
[External] : RE: [cu-dev] Checking in -- progress towards finishing Concurrency
Utilities 3.0?
To clarify, the TCK artifact in jakartaee-tck should not be used for EE
10 because the TCK has been ported over to the Concurrency project and
the new tests for EE 10 have only been added to the TCK within the Concurrency
project itself. The old copy in jakartaee-tck would likely be removed
after we have this all working.
From: "Maxim
Nesen" <maxim.nesen@xxxxxxxxxx>
To: "Dmitry
Kornilov" <dmitry.kornilov@xxxxxxxxxx>,
"Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>,
"Ed Bratt" <ed.bratt@xxxxxxxxxx>,
"Nathan Rauh" <nathan.rauh@xxxxxxxxxx>
Cc: "cu
developer discussions" <cu-dev@xxxxxxxxxxx>
Date: 01/18/2022
07:51 AM
Subject: Re:
[External] : RE: [cu-dev] Checking in -- progress towards finishing Concurrency
Utilities 3.0?
Hello everyone, regarding the state of infrastructure at https://ci.eclipse.org/cu/,
there is a bunch of jobs for Concurrency API/RI for Jakarta EE8/EE9 available.
It is possible to build SNAPSHOTs for Jakarta EE8/EE9, publish artifacts
to ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hello everyone,
regarding the state of infrastructure at https://ci.eclipse.org/cu/,
there is a bunch of jobs for Concurrency API/RI for Jakarta EE8/EE9 available.
It is possible to build SNAPSHOTs for Jakarta EE8/EE9, publish artifacts
to staging, and promote them to central afterward.
Also, there is a set of jobs to run TCK tests for Jakarta EE8/EE9 compatibility.
Presumably, it is possible to adapt jobs that manage builds and publishing/promoting
of artifacts to the staging/central without major changes.
However, TCK jobs shall be implemented from scratch. There is already a
staged TCK bundle for CU at https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/staged/eftl/jakarta-concurrency-tck-3.0.0.zipand
milestone for GF 7 at https://repo1.maven.org/maven2/org/glassfish/main/distributions/glassfish/7.0.0-M1/glassfish-7.0.0-M1.zip.
Those bundles (or newer if they are published before TCK jobs are implemented)
shall be used while implementing jobs for TCK tests.
In my opinion, it would be enough from 1 to 2 weeks to adapt and implement
the whole set of jobs for concurrency-ri 3.0.0 including jobs for TCK tests,
builds, and staging/central manipulations.
Regards,
Maxim
Od: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>
Odesláno: pondělí 17. ledna 2022 18:00
Komu: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>;
Ed Bratt <ed.bratt@xxxxxxxxxx>;
Nathan Rauh <nathan.rauh@xxxxxxxxxx>;
Maxim Nesen <maxim.nesen@xxxxxxxxxx>
Kopie: cu developer discussions <cu-dev@xxxxxxxxxxx>
Předmět: RE: [External] : RE: [cu-dev] Checking in -- progress towards
finishing Concurrency Utilities 3.0?
Adding Maxim.
Maxim, can you please analyse a state of concurrency-ri?
-- Dmitry
From:Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Sent: 14 января 2022 г. 10:54
To: Ed Bratt <ed.bratt@xxxxxxxxxx>;
Nathan Rauh <nathan.rauh@xxxxxxxxxx>;
Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Cc: cu developer discussions <cu-dev@xxxxxxxxxxx>;
Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>
Subject: RE: [External] : RE: [cu-dev] Checking in -- progress towards
finishing Concurrency Utilities 3.0?
I’m not aware that any work has been done on concurrency-ri to bring it
up to speed with the new capabilities in Concurrency 3.0 so I don’t think
that is an option for this release.
From:Ed Bratt <ed.bratt@xxxxxxxxxx>
Sent: 13 January 2022 23:43
To: Nathan Rauh <nathan.rauh@xxxxxxxxxx>;
Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Cc: cu developer discussions <cu-dev@xxxxxxxxxxx>;
DMITRY.KORNILOV <dmitry.kornilov@xxxxxxxxxx>
Subject: Re: [External] : RE: [cu-dev] Checking in -- progress towards
finishing Concurrency Utilities 3.0?
Nathan,
There is some CI infrastructure in place for the CU project (https://ci.eclipse.org/cu/).
It might be useful for completing this specification version.
The CU project consists of some bits of compatible implementation (stuff
in concurrency-ri)
which I believe constitute a CI. As I understand it, concurrency utilities
is of the class of components that requires some additional infrastructure
to host and validate the TCK. (for example, Enterprise Security has a Compatible
Implementation that only work when integrated with something more substantial,
like an EE Platform -- the same, I believe is true of CU). That said, I
see that the previous compatibility requests were made for Eclipse GlassFish
-- I think you can decide if you want to repeat that, or just request a
CCR for the (unfortunately named concurrency-ri project).
Based on previous releases it might be possible to either perform a local
build of Eclipse GlassFish that includes the CU compatible implementation
jar and API -- or, work with the GlassFish team to integrate your proposed
final CI and API JAR into GlassFish -- using that build, run the current
TCK and you have what you need (the archived CI would be the the concurrency
utilities implementation, not the GlassFish version that it was integrated
into).
It looks like Dmitry Kornilov ran these tests last time they were run.
He might recall these details more clearly.
Thanks,
-- Ed
PS, after this API is finalized, we should consider splitting it into an
implementation and Spec. project. The Spec. project could then be moved
into jakartaee GHO.
On 1/13/2022 6:45 AM, Nathan Rauh wrote:
I just noticed that Ed was somehow left off of the cc list when I replied
yesterday. Sorry about that. I have just added him back on.
As far as I'm aware, every 3.0 enhancement for which a pull was submitted
has been fully added to the specification and TCK, with nothing in a partial
state except for the pending work to add TCK coverage for the new resource
definition annotations in EJB container and possibly JSPs, which are being
worked on. We should create a 3.1 milestone in github to collect
up a list of enhancements/issues that didn't make 3.0 (such as the one
you mentioned) that could go into Jakarta EE 11. If everyone is happy
with this outcome, the main help that will be needed is the timely creation
and publish to maven of the 3.0 RC1 image next week after those final TCK
update(s) go in. Starting/continuing on your implementation is probably
the best way to help at this point so that there is a contingency plan
if this doesn't make the Open Liberty beta in time. The odds became
a bit more favorable because I just noticed that Kyle has successfully
finished addressing all of the review comments on the TCK port issue, and
so I've merged it in. Thist just leaves the pending TCK scenario(s)
for resource definition annotations to get in next week.
From: "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: "Nathan
Rauh" <nathan.rauh@xxxxxxxxxx>,
"cu developer discussions" <cu-dev@xxxxxxxxxxx>
Cc: "DMITRY.KORNILOV"
<dmitry.kornilov@xxxxxxxxxx>
Date: 01/13/2022
06:38 AM
Subject: [EXTERNAL]
RE: [cu-dev] Checking in -- progress towards finishing Concurrency
Utilities 3.0?
Hi Nathan, Dmitry
I should remember how to push artifacts to maven central assuming the old
Jenkins jobs haven’t got “bit rot”. I was hoping to get an api change
for this issue MaxConcurrency
annotation · Issue #136 · eclipse-ee4j/concurrency-api · GitHubbut
tbh I’m not going to get the time.
I haven’t been following this as closely as I should due to many and varied
things. Are we OK with spec doc or do I need to pull some of my team in
to drive this forward more?
Our team is starting to look at the implementation of this on Payara 6
alpha 3 but not sure we can meet the Feb deadline with a Compatible Implementation.
We likely have more flexibility in pushing out alphas than perhaps OpenLiberty.
Is Feb 28th really a drop dead deadline for have a CI
ready if the API is finalised?
Steve
From:Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 12 January 2022 19:26
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: DMITRY.KORNILOV <dmitry.kornilov@xxxxxxxxxx>;
Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Subject: Re: [cu-dev] Checking in -- progress towards finishing Concurrency
Utilities 3.0?
I can help provide some of the estimated timeline assuming that we will
need to use Open Liberty as the compatible implementation upon which to
certify. Toward the end of last year I sent an email out querying
if there were any other implementations that could be used as the compatible
implementation that would meet the Feb 28 deadline, and thus far haven't
heard back from any others.
Here's how the schedule would line up:
The pull to port over the old TCK bucket to the Concurrency project and
merge it with the new TCK tests that have already been written for Concurrency
3.0 is currently in review state. It appears that all of the review
comments thus far have been very minor and so I expect it to be merged
relatively soon, probably within the next few days.
After this, one of the participants is working on a remaining new TCK test
to include the new resource definition annotations on an EJB. That
will need to be submitted, reviewed and merged, hopefully early next week.
After that, an official RC1 build will need to be performed, and the spec
API jar and TCK jar published to maven. I have no idea how to do
either of these things, but hopefully Steve knows or either of you who
are helping to mentor will know and can help with it.
If that can all be done by January 19, then we should be able to get it
into the next beta release of Open Liberty.
Every day beyond that point over the next week will have an increasingly
lesser chance of making the February beta. I don't expect Open Liberty
will hold up or change its release schedule for just this spec.
When the February beta comes out around the beginning of February, then
we would be able to collect official results of the TCK running with the
3.0 RC1 release on the Open Liberty beta as the compatible implementation.
It will take several days further to get those results published
to a publically accessible location, but it would be well before the Feb
28 deadline.
The main risk here is getting the 3.0 RC1 image created and published to
Maven in time.
If another implementation with a more flexible schedule or more lenient
approach to certification comes along, that would certainly help add some
time. But absent that, we do at least have a path to meeting Feb
28, albeit a narrow one.
From: "Ed
Bratt" <ed.bratt@xxxxxxxxxx>
To: "cu
developer discussions" <cu-dev@xxxxxxxxxxx>,
"Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Cc: "DMITRY.KORNILOV"
<dmitry.kornilov@xxxxxxxxxx>
Date: 01/12/2022
11:55 AM
Subject: [EXTERNAL]
[cu-dev] Checking in -- progress towards finishing Concurrency Utilities
3.0?
Sent by: "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>
Hi,
Dmitry Kornilov and I have been assigned by the Specification Committee
to mentor you through the process of finalizing the Release PR for the
upcoming release review of Jakarta Concurrency 3.0 for inclusion in EE10.
As a part of wave 1 in the Jakarta
EE 10 Release Plan,
the release review PR could be made at any time. You may create the PR
even if you don't have all the information required. Just mark it as DRAFT
and work on it together with your mentor (me).
Are you on track with finishing up this specification version and creating
a PR for this specification in the specificationsrepository?
Are you able to estimate when the team anticipates starting this final
step?
Is there anything blocking/delaying the release?
Is there anything Dmitry or I can help you or the project team with?
Thank you,
-- Ed_______________________________________________
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