2:45 p.m.
I want to get things started re getting more fine-grained issues created
for the various EE 10 spec migration issues linked to
https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
directly linked to WFLY-15679 are too coarse-grained, because there are a
number of distinct tasks that can be done separately for each, and to have
a realistic sense of where we stand we need to have visibility into how
things stand with those finer-grained pieces
A good recommendation I got from Tom Jenkinson is to add a comment on the
various per-spec issues outlining the various types of detailed issues the
assignee should consider filing, along with instructions as to how to do
so. The following is what I propose adding:
"Please consider creating subtasks of this issue for any of the following
or other similar activities that can be accomplished as discrete pieces of
work toward this JIRA's overall goal. Please add the 'EE10' label to any
such issue.
* Ensuring that the standalone TCK for this spec can be run against a
current build of WildFly Preview, and if possible reporting any issues to
spec's working group before it is finalized.[1]
* Creating a branch for the EE 10 variant in the github repo for the JBoss
fork of the spec, based on the appropriate code at Jakarta.[2]
* Integrating a milestone release of the spec API into WildFly's main
branch.
* Integrating a milestone release of the implementation artifacts into
WildFly's main branch.
* Integrating the final release of the spec API into WildFly's main branch.
* Integrating final releases of the implementation artifacts
Reminder: WildFly 27 is feature-boxed, so integrating non-final
dependencies into main is not just ok, it is encouraged. Doing so lets us
identify issues early.
We'll be using these finer-grained issues to better track progress on
https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view...
and elsewhere."
Note that I don't include passing standalone or parts of the platform TCK
here, because it's not clear to me that that kind of thing can be cleanly
decomposed into discrete pieces of work. We know we need to pass the TCKs.
Note also that this message and the related issues are focused on WildFly
Preview. Our ultimate goal is to convert the standard WildFly code to EE
10, ideally as soon as possible. But to do that we'll need to complete the
work of getting native jakarta.* namespace variants of all our components.
That work can proceed in parallel with our work on EE 10 if we continue to
do it in WFP for now.
[1] I'd only add this to issues where a standalone TCK exists.
[2] I'd only add this to issues where we are using a fork of the EE 9.1
spec API code in WildFly Preview.
Best regards,
Brian
3 p.m.
BTW I forgot to say clearly that part of the point of this thread is to vet
that proposed wording before people start going off and creating issues. :)
On Wed, Feb 23, 2022 at 2:45 PM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
I want to get things started re getting more fine-grained issues
created
for the various EE 10 spec migration issues linked to
https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
directly linked to WFLY-15679 are too coarse-grained, because there are a
number of distinct tasks that can be done separately for each, and to have
a realistic sense of where we stand we need to have visibility into how
things stand with those finer-grained pieces
A good recommendation I got from Tom Jenkinson is to add a comment on the
various per-spec issues outlining the various types of detailed issues the
assignee should consider filing, along with instructions as to how to do
so. The following is what I propose adding:
"Please consider creating subtasks of this issue for any of the following
or other similar activities that can be accomplished as discrete pieces of
work toward this JIRA's overall goal. Please add the 'EE10' label to any
such issue.
* Ensuring that the standalone TCK for this spec can be run against a
current build of WildFly Preview, and if possible reporting any issues to
spec's working group before it is finalized.[1]
* Creating a branch for the EE 10 variant in the github repo for the JBoss
fork of the spec, based on the appropriate code at Jakarta.[2]
* Integrating a milestone release of the spec API into WildFly's main
branch.
* Integrating a milestone release of the implementation artifacts into
WildFly's main branch.
* Integrating the final release of the spec API into WildFly's main branch.
* Integrating final releases of the implementation artifacts
Reminder: WildFly 27 is feature-boxed, so integrating non-final
dependencies into main is not just ok, it is encouraged. Doing so lets us
identify issues early.
We'll be using these finer-grained issues to better track progress on
https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view...
and elsewhere."
Note that I don't include passing standalone or parts of the platform TCK
here, because it's not clear to me that that kind of thing can be cleanly
decomposed into discrete pieces of work. We know we need to pass the TCKs.
Note also that this message and the related issues are focused on WildFly
Preview. Our ultimate goal is to convert the standard WildFly code to EE
10, ideally as soon as possible. But to do that we'll need to complete the
work of getting native jakarta.* namespace variants of all our components.
That work can proceed in parallel with our work on EE 10 if we continue to
do it in WFP for now.
[1] I'd only add this to issues where a standalone TCK exists.
[2] I'd only add this to issues where we are using a fork of the EE 9.1
spec API code in WildFly Preview.
Best regards,
Brian
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
3:06 p.m.
I think this makes sense and it's a good thing to get started on. We've
already made the steps to require Java 11 so the next logical step to me is
to start progressing with Jakarta EE 10.
I'm not sure this will happen, but what do we think of integrating say an
Alpha release of a spec implementation that might not be fully implemented
yet? What I'm thinking here is with RESTEasy the main branch is already on
Jakarta REST 3.1 which targets Jakarta EE 10. We could potentially do an
Alpha1 release which does not fully implement the new features, but would
allow the TCK signature tests to pass. We would also have advanced
knowledge of what we might be failing.
One catch is the spec itself is not released to Maven Central so an entry
for the staging repository would be required:
<!-- Temporary repository for staged Jakarta EE 10 dependencies -->
<repository>
<id>jakarta-staging</id>
<name>Jakarta Staging</name>
<url>https://jakarta.oss.sonatype.org/content/repositories/staging/
</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
Does this sound like something reasonable? I don't know if implementations,
including RESTEasy, want to do a release that doesn't at least attempt to
fully implement the spec but it seems worth considering.
Assuming the above seems reasonable, would we want a "pre-integration" JIRA
or do we just want an implementation integration JIRA and component upgrade
JIRA's after that?
On Wed, Feb 23, 2022 at 12:46 PM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
I want to get things started re getting more fine-grained issues
created
for the various EE 10 spec migration issues linked to
https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
directly linked to WFLY-15679 are too coarse-grained, because there are a
number of distinct tasks that can be done separately for each, and to have
a realistic sense of where we stand we need to have visibility into how
things stand with those finer-grained pieces
A good recommendation I got from Tom Jenkinson is to add a comment on the
various per-spec issues outlining the various types of detailed issues the
assignee should consider filing, along with instructions as to how to do
so. The following is what I propose adding:
"Please consider creating subtasks of this issue for any of the following
or other similar activities that can be accomplished as discrete pieces of
work toward this JIRA's overall goal. Please add the 'EE10' label to any
such issue.
* Ensuring that the standalone TCK for this spec can be run against a
current build of WildFly Preview, and if possible reporting any issues to
spec's working group before it is finalized.[1]
* Creating a branch for the EE 10 variant in the github repo for the JBoss
fork of the spec, based on the appropriate code at Jakarta.[2]
* Integrating a milestone release of the spec API into WildFly's main
branch.
* Integrating a milestone release of the implementation artifacts into
WildFly's main branch.
* Integrating the final release of the spec API into WildFly's main branch.
* Integrating final releases of the implementation artifacts
Reminder: WildFly 27 is feature-boxed, so integrating non-final
dependencies into main is not just ok, it is encouraged. Doing so lets us
identify issues early.
We'll be using these finer-grained issues to better track progress on
https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view...
and elsewhere."
Note that I don't include passing standalone or parts of the platform TCK
here, because it's not clear to me that that kind of thing can be cleanly
decomposed into discrete pieces of work. We know we need to pass the TCKs.
Note also that this message and the related issues are focused on WildFly
Preview. Our ultimate goal is to convert the standard WildFly code to EE
10, ideally as soon as possible. But to do that we'll need to complete the
work of getting native jakarta.* namespace variants of all our components.
That work can proceed in parallel with our work on EE 10 if we continue to
do it in WFP for now.
[1] I'd only add this to issues where a standalone TCK exists.
[2] I'd only add this to issues where we are using a fork of the EE 9.1
spec API code in WildFly Preview.
Best regards,
Brian
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
James R. Perkins
JBoss by Red Hat
3:31 p.m.
On Wed, Feb 23, 2022 at 3:06 PM James Perkins <jperkins(a)redhat.com> wrote:
I think this makes sense and it's a good thing to get started on.
We've
already made the steps to require Java 11 so the next logical step to me is
to start progressing with Jakarta EE 10.
I'm not sure this will happen, but what do we think of integrating say an
Alpha release of a spec implementation that might not be fully implemented
yet? What I'm thinking here is with RESTEasy the main branch is already on
Jakarta REST 3.1 which targets Jakarta EE 10. We could potentially do an
Alpha1 release which does not fully implement the new features, but would
allow the TCK signature tests to pass. We would also have advanced
knowledge of what we might be failing.
It's a bit of a tradeoff. It's certainly good to get impls in earlier so we
can identify and sort issues. One way to look at it is for now we don't
need main to always be releasable, but it should be understandable. And an
important part of being understandable is interpreting test results, which
somewhat includes the running and not regressing the TCK.
But part of working on any new EE release is a period where the TCK doesn't
pass, so that's normal.
If bringing in a milestone release actually makes us more understandable,
it seems good to me to do it even if it's not complete. E.g. a RESTEasy
milestone that doesn't implement all new features, and thus fails TCK
tests, is probably better than an older RESTEasy that doesn't implement any
new features!
I'm a bit more picky about WF's own TS, as it presumably doesn't have any
tests of the new features, so they shouldn't fail. :) So we need to be
cautious about / quite reluctant to merge things that leave existing tests
broken. Matej Novotny is doing a nice job of looking at that with
https://github.com/wildfly/wildfly/pull/15254.
One catch is the spec itself is not released to Maven Central so an
entry
for the staging repository would be required:
I'm pretty reluctant to do that, as an artifact in a staging repo is not
stable. If a staging repo is in our pom anyone who builds can be pulling
GAVs into their local repo that may change later. Hopefully specs will
publish interim releases to maven central. A number have.
<!-- Temporary repository for staged Jakarta EE 10 dependencies -->
<repository>
<id>jakarta-staging</id>
<name>Jakarta Staging</name>
<url>https://jakarta.oss.sonatype.org/content/repositories/staging/
</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
Does this sound like something reasonable? I don't know if
implementations, including RESTEasy, want to do a release that doesn't at
least attempt to fully implement the spec but it seems worth considering.
Assuming the above seems reasonable, would we want a "pre-integration"
JIRA or do we just want an implementation integration JIRA and component
upgrade JIRA's after that?
Below I suggest a separate JIRA. for the interim work. Thereafter an
upgrade sounds fine.
On Wed, Feb 23, 2022 at 12:46 PM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> I want to get things started re getting more fine-grained issues created
> for the various EE 10 spec migration issues linked to
> https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
> directly linked to WFLY-15679 are too coarse-grained, because there are a
> number of distinct tasks that can be done separately for each, and to have
> a realistic sense of where we stand we need to have visibility into how
> things stand with those finer-grained pieces
>
> A good recommendation I got from Tom Jenkinson is to add a comment on the
> various per-spec issues outlining the various types of detailed issues the
> assignee should consider filing, along with instructions as to how to do
> so. The following is what I propose adding:
>
> "Please consider creating subtasks of this issue for any of the following
> or other similar activities that can be accomplished as discrete pieces of
> work toward this JIRA's overall goal. Please add the 'EE10' label to any
> such issue.
>
> * Ensuring that the standalone TCK for this spec can be run against a
> current build of WildFly Preview, and if possible reporting any issues to
> spec's working group before it is finalized.[1]
> * Creating a branch for the EE 10 variant in the github repo for the
> JBoss fork of the spec, based on the appropriate code at Jakarta.[2]
> * Integrating a milestone release of the spec API into WildFly's main
> branch.
> * Integrating a milestone release of the implementation artifacts into
> WildFly's main branch.
> * Integrating the final release of the spec API into WildFly's main
> branch.
> * Integrating final releases of the implementation artifacts
>
> Reminder: WildFly 27 is feature-boxed, so integrating non-final
> dependencies into main is not just ok, it is encouraged. Doing so lets us
> identify issues early.
>
> We'll be using these finer-grained issues to better track progress on
>
https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view...
> and elsewhere."
>
> Note that I don't include passing standalone or parts of the platform TCK
> here, because it's not clear to me that that kind of thing can be cleanly
> decomposed into discrete pieces of work. We know we need to pass the TCKs.
>
> Note also that this message and the related issues are focused on WildFly
> Preview. Our ultimate goal is to convert the standard WildFly code to EE
> 10, ideally as soon as possible. But to do that we'll need to complete the
> work of getting native jakarta.* namespace variants of all our components.
> That work can proceed in parallel with our work on EE 10 if we continue to
> do it in WFP for now.
>
>
> [1] I'd only add this to issues where a standalone TCK exists.
> [2] I'd only add this to issues where we are using a fork of the EE 9.1
> spec API code in WildFly Preview.
>
> Best regards,
> Brian
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
4:02 p.m.
Regarding staged releases, I have been pushing for every spec to have some
publicly available milestone in maven central for use by compatible
implementations so that they don't need to validate against the staged
final API artifacts. A ratifying compatible implementation for the
specification is free to use such artifacts as long as they pass the
associated signature tests. Weld is doing this for CDI 4.0.0.
On Feb 23, 2022 at 3:31:18 PM, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
On Wed, Feb 23, 2022 at 3:06 PM James Perkins <jperkins(a)redhat.com> wrote:
> I think this makes sense and it's a good thing to get started on. We've
> already made the steps to require Java 11 so the next logical step to me is
> to start progressing with Jakarta EE 10.
>
> I'm not sure this will happen, but what do we think of integrating say an
> Alpha release of a spec implementation that might not be fully implemented
> yet? What I'm thinking here is with RESTEasy the main branch is already on
> Jakarta REST 3.1 which targets Jakarta EE 10. We could potentially do an
> Alpha1 release which does not fully implement the new features, but would
> allow the TCK signature tests to pass. We would also have advanced
> knowledge of what we might be failing.
>
It's a bit of a tradeoff. It's certainly good to get impls in earlier so
we can identify and sort issues. One way to look at it is for now we don't
need main to always be releasable, but it should be understandable. And an
important part of being understandable is interpreting test results, which
somewhat includes the running and not regressing the TCK.
But part of working on any new EE release is a period where the TCK
doesn't pass, so that's normal.
If bringing in a milestone release actually makes us more understandable,
it seems good to me to do it even if it's not complete. E.g. a RESTEasy
milestone that doesn't implement all new features, and thus fails TCK
tests, is probably better than an older RESTEasy that doesn't implement any
new features!
I'm a bit more picky about WF's own TS, as it presumably doesn't have any
tests of the new features, so they shouldn't fail. :) So we need to be
cautious about / quite reluctant to merge things that leave existing tests
broken. Matej Novotny is doing a nice job of looking at that with
https://github.com/wildfly/wildfly/pull/15254.
> One catch is the spec itself is not released to Maven Central so an entry
> for the staging repository would be required:
>
I'm pretty reluctant to do that, as an artifact in a staging repo is not
stable. If a staging repo is in our pom anyone who builds can be pulling
GAVs into their local repo that may change later. Hopefully specs will
publish interim releases to maven central. A number have.
<!-- Temporary repository for staged Jakarta EE 10 dependencies -->
> <repository>
> <id>jakarta-staging</id>
> <name>Jakarta Staging</name>
> <url>https://jakarta.oss.sonatype.org/content/repositories/staging/
> </url>
> <layout>default</layout>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>daily</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
>
> Does this sound like something reasonable? I don't know if
> implementations, including RESTEasy, want to do a release that doesn't at
> least attempt to fully implement the spec but it seems worth considering.
>
> Assuming the above seems reasonable, would we want a "pre-integration"
> JIRA or do we just want an implementation integration JIRA and component
> upgrade JIRA's after that?
>
Below I suggest a separate JIRA. for the interim work. Thereafter an
upgrade sounds fine.
> On Wed, Feb 23, 2022 at 12:46 PM Brian Stansberry <
> brian.stansberry(a)redhat.com> wrote:
>
>> I want to get things started re getting more fine-grained issues created
>> for the various EE 10 spec migration issues linked to
>> https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
>> directly linked to WFLY-15679 are too coarse-grained, because there are a
>> number of distinct tasks that can be done separately for each, and to have
>> a realistic sense of where we stand we need to have visibility into how
>> things stand with those finer-grained pieces
>>
>> A good recommendation I got from Tom Jenkinson is to add a comment on
>> the various per-spec issues outlining the various types of detailed issues
>> the assignee should consider filing, along with instructions as to how to
>> do so. The following is what I propose adding:
>>
>> "Please consider creating subtasks of this issue for any of the
>> following or other similar activities that can be accomplished as discrete
>> pieces of work toward this JIRA's overall goal. Please add the 'EE10'
label
>> to any such issue.
>>
>> * Ensuring that the standalone TCK for this spec can be run against a
>> current build of WildFly Preview, and if possible reporting any issues to
>> spec's working group before it is finalized.[1]
>> * Creating a branch for the EE 10 variant in the github repo for the
>> JBoss fork of the spec, based on the appropriate code at Jakarta.[2]
>> * Integrating a milestone release of the spec API into WildFly's main
>> branch.
>> * Integrating a milestone release of the implementation artifacts into
>> WildFly's main branch.
>> * Integrating the final release of the spec API into WildFly's main
>> branch.
>> * Integrating final releases of the implementation artifacts
>>
>> Reminder: WildFly 27 is feature-boxed, so integrating non-final
>> dependencies into main is not just ok, it is encouraged. Doing so lets us
>> identify issues early.
>>
>> We'll be using these finer-grained issues to better track progress on
>>
https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view...
>> and elsewhere."
>>
>> Note that I don't include passing standalone or parts of the platform
>> TCK here, because it's not clear to me that that kind of thing can be
>> cleanly decomposed into discrete pieces of work. We know we need to pass
>> the TCKs.
>>
>> Note also that this message and the related issues are focused on
>> WildFly Preview. Our ultimate goal is to convert the standard WildFly code
>> to EE 10, ideally as soon as possible. But to do that we'll need to
>> complete the work of getting native jakarta.* namespace variants of all our
>> components. That work can proceed in parallel with our work on EE 10 if we
>> continue to do it in WFP for now.
>>
>>
>> [1] I'd only add this to issues where a standalone TCK exists.
>> [2] I'd only add this to issues where we are using a fork of the EE 9.1
>> spec API code in WildFly Preview.
>>
>> Best regards,
>> Brian
>> _______________________________________________
>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
4:11 p.m.
Excellent. Thanks Scott! It will be helpful when they arrive :)
On Wed, Feb 23, 2022 at 2:02 PM Scott Stark <sstark(a)redhat.com> wrote:
Regarding staged releases, I have been pushing for every spec to have
some
publicly available milestone in maven central for use by compatible
implementations so that they don't need to validate against the staged
final API artifacts. A ratifying compatible implementation for the
specification is free to use such artifacts as long as they pass the
associated signature tests. Weld is doing this for CDI 4.0.0.
On Feb 23, 2022 at 3:31:18 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
>
>
> On Wed, Feb 23, 2022 at 3:06 PM James Perkins <jperkins(a)redhat.com>
> wrote:
>
>> I think this makes sense and it's a good thing to get started on. We've
>> already made the steps to require Java 11 so the next logical step to me is
>> to start progressing with Jakarta EE 10.
>>
>> I'm not sure this will happen, but what do we think of integrating say
>> an Alpha release of a spec implementation that might not be fully
>> implemented yet? What I'm thinking here is with RESTEasy the main branch is
>> already on Jakarta REST 3.1 which targets Jakarta EE 10. We could
>> potentially do an Alpha1 release which does not fully implement the new
>> features, but would allow the TCK signature tests to pass. We would also
>> have advanced knowledge of what we might be failing.
>>
>
> It's a bit of a tradeoff. It's certainly good to get impls in earlier so
> we can identify and sort issues. One way to look at it is for now we don't
> need main to always be releasable, but it should be understandable. And an
> important part of being understandable is interpreting test results, which
> somewhat includes the running and not regressing the TCK.
>
> But part of working on any new EE release is a period where the TCK
> doesn't pass, so that's normal.
>
> If bringing in a milestone release actually makes us more understandable,
> it seems good to me to do it even if it's not complete. E.g. a RESTEasy
> milestone that doesn't implement all new features, and thus fails TCK
> tests, is probably better than an older RESTEasy that doesn't implement any
> new features!
>
> I'm a bit more picky about WF's own TS, as it presumably doesn't have
any
> tests of the new features, so they shouldn't fail. :) So we need to be
> cautious about / quite reluctant to merge things that leave existing tests
> broken. Matej Novotny is doing a nice job of looking at that with
> https://github.com/wildfly/wildfly/pull/15254.
>
>
>> One catch is the spec itself is not released to Maven Central so an
>> entry for the staging repository would be required:
>>
>
> I'm pretty reluctant to do that, as an artifact in a staging repo is not
> stable. If a staging repo is in our pom anyone who builds can be pulling
> GAVs into their local repo that may change later. Hopefully specs will
> publish interim releases to maven central. A number have.
>
> <!-- Temporary repository for staged Jakarta EE 10 dependencies -->
>> <repository>
>> <id>jakarta-staging</id>
>> <name>Jakarta Staging</name>
>> <url>https://jakarta.oss.sonatype.org/content/repositories/staging/
>> </url>
>> <layout>default</layout>
>> <releases>
>> <enabled>true</enabled>
>> <updatePolicy>daily</updatePolicy>
>> </releases>
>> <snapshots>
>> <enabled>false</enabled>
>> </snapshots>
>> </repository>
>>
>> Does this sound like something reasonable? I don't know if
>> implementations, including RESTEasy, want to do a release that doesn't at
>> least attempt to fully implement the spec but it seems worth considering.
>>
>> Assuming the above seems reasonable, would we want a "pre-integration"
>> JIRA or do we just want an implementation integration JIRA and component
>> upgrade JIRA's after that?
>>
>
> Below I suggest a separate JIRA. for the interim work. Thereafter an
> upgrade sounds fine.
>
>
>> On Wed, Feb 23, 2022 at 12:46 PM Brian Stansberry <
>> brian.stansberry(a)redhat.com> wrote:
>>
>>> I want to get things started re getting more fine-grained issues
>>> created for the various EE 10 spec migration issues linked to
>>> https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
>>> directly linked to WFLY-15679 are too coarse-grained, because there are a
>>> number of distinct tasks that can be done separately for each, and to have
>>> a realistic sense of where we stand we need to have visibility into how
>>> things stand with those finer-grained pieces
>>>
>>> A good recommendation I got from Tom Jenkinson is to add a comment on
>>> the various per-spec issues outlining the various types of detailed issues
>>> the assignee should consider filing, along with instructions as to how to
>>> do so. The following is what I propose adding:
>>>
>>> "Please consider creating subtasks of this issue for any of the
>>> following or other similar activities that can be accomplished as discrete
>>> pieces of work toward this JIRA's overall goal. Please add the
'EE10' label
>>> to any such issue.
>>>
>>> * Ensuring that the standalone TCK for this spec can be run against a
>>> current build of WildFly Preview, and if possible reporting any issues to
>>> spec's working group before it is finalized.[1]
>>> * Creating a branch for the EE 10 variant in the github repo for the
>>> JBoss fork of the spec, based on the appropriate code at Jakarta.[2]
>>> * Integrating a milestone release of the spec API into WildFly's main
>>> branch.
>>> * Integrating a milestone release of the implementation artifacts into
>>> WildFly's main branch.
>>> * Integrating the final release of the spec API into WildFly's main
>>> branch.
>>> * Integrating final releases of the implementation artifacts
>>>
>>> Reminder: WildFly 27 is feature-boxed, so integrating non-final
>>> dependencies into main is not just ok, it is encouraged. Doing so lets us
>>> identify issues early.
>>>
>>> We'll be using these finer-grained issues to better track progress on
>>>
https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view...
>>> and elsewhere."
>>>
>>> Note that I don't include passing standalone or parts of the platform
>>> TCK here, because it's not clear to me that that kind of thing can be
>>> cleanly decomposed into discrete pieces of work. We know we need to pass
>>> the TCKs.
>>>
>>> Note also that this message and the related issues are focused on
>>> WildFly Preview. Our ultimate goal is to convert the standard WildFly code
>>> to EE 10, ideally as soon as possible. But to do that we'll need to
>>> complete the work of getting native jakarta.* namespace variants of all our
>>> components. That work can proceed in parallel with our work on EE 10 if we
>>> continue to do it in WFP for now.
>>>
>>>
>>> [1] I'd only add this to issues where a standalone TCK exists.
>>> [2] I'd only add this to issues where we are using a fork of the EE 9.1
>>> spec API code in WildFly Preview.
>>>
>>> Best regards,
>>> Brian
>>> _______________________________________________
>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
>
> --
> Brian Stansberry
> Principal Architect, Red Hat JBoss EAP
> He/Him/His
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
--
James R. Perkins
JBoss by Red Hat
4:15 p.m.
There are currently only about 6 specs that have not created a candidate
final. I'm not aware of any that don't have a milestone of some sort at
this point. Are you running into some?
On Feb 23, 2022 at 4:11:18 PM, James Perkins <jperkins(a)redhat.com> wrote:
Excellent. Thanks Scott! It will be helpful when they arrive :)
On Wed, Feb 23, 2022 at 2:02 PM Scott Stark <sstark(a)redhat.com> wrote:
> Regarding staged releases, I have been pushing for every spec to have
> some publicly available milestone in maven central for use by compatible
> implementations so that they don't need to validate against the staged
> final API artifacts. A ratifying compatible implementation for the
> specification is free to use such artifacts as long as they pass the
> associated signature tests. Weld is doing this for CDI 4.0.0.
>
5:55 p.m.
I've been using the jakarta.ws.rs:jakarta.ws.rs-api one from the
staging repo as I don't see one in Maven Central.
On Wed, Feb 23, 2022 at 2:15 PM Scott Stark <sstark(a)redhat.com> wrote:
There are currently only about 6 specs that have not created a
candidate
final. I'm not aware of any that don't have a milestone of some sort at
this point. Are you running into some?
On Feb 23, 2022 at 4:11:18 PM, James Perkins <jperkins(a)redhat.com> wrote:
> Excellent. Thanks Scott! It will be helpful when they arrive :)
>
> On Wed, Feb 23, 2022 at 2:02 PM Scott Stark <sstark(a)redhat.com> wrote:
>
>> Regarding staged releases, I have been pushing for every spec to have
>> some publicly available milestone in maven central for use by compatible
>> implementations so that they don't need to validate against the staged
>> final API artifacts. A ratifying compatible implementation for the
>> specification is free to use such artifacts as long as they pass the
>> associated signature tests. Weld is doing this for CDI 4.0.0.
>>
>
>
--
James R. Perkins
JBoss by Red Hat
6:45 p.m.
Looking on https://mvnrepository.com/ I don't see any sort of milestone for
these:
Authentication
Concurrency
Connectors
Enterprise Java Beans (no biggie; just a micro)
JSON Binding
JSON Processing
Messaging
RESTFul Webservices
Server Pages
Servlet
Standard Tag Library
Websocket
There are for these:
Activation
Annotations
Authorization
Batch
Bean Validation
Contexts and Dependency Injection
Dependency Injection
Expression Language
Interceptors
Mail
Persistence
SOAP with Attachments
Transactions
XML Binding
XML Web Services
On Wed, Feb 23, 2022 at 5:55 PM James Perkins <jperkins(a)redhat.com> wrote:
I've been using the jakarta.ws.rs:jakarta.ws.rs-api one from the
staging repo as I don't see one in Maven Central.
On Wed, Feb 23, 2022 at 2:15 PM Scott Stark <sstark(a)redhat.com> wrote:
> There are currently only about 6 specs that have not created a candidate
> final. I'm not aware of any that don't have a milestone of some sort at
> this point. Are you running into some?
>
> On Feb 23, 2022 at 4:11:18 PM, James Perkins <jperkins(a)redhat.com> wrote:
>
>> Excellent. Thanks Scott! It will be helpful when they arrive :)
>>
>> On Wed, Feb 23, 2022 at 2:02 PM Scott Stark <sstark(a)redhat.com> wrote:
>>
>>> Regarding staged releases, I have been pushing for every spec to have
>>> some publicly available milestone in maven central for use by compatible
>>> implementations so that they don't need to validate against the staged
>>> final API artifacts. A ratifying compatible implementation for the
>>> specification is free to use such artifacts as long as they pass the
>>> associated signature tests. Weld is doing this for CDI 4.0.0.
>>>
>>
>>
--
James R. Perkins
JBoss by Red Hat
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
12:52 a.m.
Ok, damn. They have only ever produced snapshots, and they have produced
their final candidate api. They should be done with a ballot within a
couple of weeks I expect.
On Feb 23, 2022 at 5:55:40 PM, James Perkins <jperkins(a)redhat.com> wrote:
I've been using the jakarta.ws.rs:jakarta.ws.rs-api one from the
staging repo as I don't see one in Maven Central.
On Wed, Feb 23, 2022 at 2:15 PM Scott Stark <sstark(a)redhat.com> wrote:
> There are currently only about 6 specs that have not created a candidate
> final. I'm not aware of any that don't have a milestone of some sort at
> this point. Are you running into some?
>
> On Feb 23, 2022 at 4:11:18 PM, James Perkins <jperkins(a)redhat.com> wrote:
>
>> Excellent. Thanks Scott! It will be helpful when they arrive :)
>>
>> On Wed, Feb 23, 2022 at 2:02 PM Scott Stark <sstark(a)redhat.com> wrote:
>>
>>> Regarding staged releases, I have been pushing for every spec to have
>>> some publicly available milestone in maven central for use by compatible
>>> implementations so that they don't need to validate against the staged
>>> final API artifacts. A ratifying compatible implementation for the
>>> specification is free to use such artifacts as long as they pass the
>>> associated signature tests. Weld is doing this for CDI 4.0.0.
>>>
>>
>>
--
James R. Perkins
JBoss by Red Hat
4:10 p.m.
On Wed, Feb 23, 2022 at 1:32 PM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
On Wed, Feb 23, 2022 at 3:06 PM James Perkins <jperkins(a)redhat.com> wrote:
> I think this makes sense and it's a good thing to get started on. We've
> already made the steps to require Java 11 so the next logical step to me is
> to start progressing with Jakarta EE 10.
>
> I'm not sure this will happen, but what do we think of integrating say an
> Alpha release of a spec implementation that might not be fully implemented
> yet? What I'm thinking here is with RESTEasy the main branch is already on
> Jakarta REST 3.1 which targets Jakarta EE 10. We could potentially do an
> Alpha1 release which does not fully implement the new features, but would
> allow the TCK signature tests to pass. We would also have advanced
> knowledge of what we might be failing.
>
It's a bit of a tradeoff. It's certainly good to get impls in earlier so
we can identify and sort issues. One way to look at it is for now we don't
need main to always be releasable, but it should be understandable. And an
important part of being understandable is interpreting test results, which
somewhat includes the running and not regressing the TCK.
But part of working on any new EE release is a period where the TCK
doesn't pass, so that's normal.
If bringing in a milestone release actually makes us more understandable,
it seems good to me to do it even if it's not complete. E.g. a RESTEasy
milestone that doesn't implement all new features, and thus fails TCK
tests, is probably better than an older RESTEasy that doesn't implement any
new features!
I'm a bit more picky about WF's own TS, as it presumably doesn't have any
tests of the new features, so they shouldn't fail. :) So we need to be
cautious about / quite reluctant to merge things that leave existing tests
broken. Matej Novotny is doing a nice job of looking at that with
https://github.com/wildfly/wildfly/pull/15254.
This makes sense to me and that is a very good example. It sounds like once
a release candidate of the spec is in Maven Central we could do a RESTEasy
Alpha release and integrate it.
> One catch is the spec itself is not released to Maven Central so an entry
> for the staging repository would be required:
>
I'm pretty reluctant to do that, as an artifact in a staging repo is not
stable. If a staging repo is in our pom anyone who builds can be pulling
GAVs into their local repo that may change later. Hopefully specs will
publish interim releases to maven central. A number have.
That makes sense to me. Having a polluted local repository is not ideal for
sure. It's happening in RESTEasy now, but it was really the only path
forward until it's in Maven Central.
<!-- Temporary repository for staged Jakarta EE 10 dependencies -->
> <repository>
> <id>jakarta-staging</id>
> <name>Jakarta Staging</name>
> <url>https://jakarta.oss.sonatype.org/content/repositories/staging/
> </url>
> <layout>default</layout>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>daily</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
>
> Does this sound like something reasonable? I don't know if
> implementations, including RESTEasy, want to do a release that doesn't at
> least attempt to fully implement the spec but it seems worth considering.
>
> Assuming the above seems reasonable, would we want a "pre-integration"
> JIRA or do we just want an implementation integration JIRA and component
> upgrade JIRA's after that?
>
Below I suggest a separate JIRA. for the interim work. Thereafter an
upgrade sounds fine.
Perfect thanks!
> On Wed, Feb 23, 2022 at 12:46 PM Brian Stansberry <
> brian.stansberry(a)redhat.com> wrote:
>
>> I want to get things started re getting more fine-grained issues created
>> for the various EE 10 spec migration issues linked to
>> https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
>> directly linked to WFLY-15679 are too coarse-grained, because there are a
>> number of distinct tasks that can be done separately for each, and to have
>> a realistic sense of where we stand we need to have visibility into how
>> things stand with those finer-grained pieces
>>
>> A good recommendation I got from Tom Jenkinson is to add a comment on
>> the various per-spec issues outlining the various types of detailed issues
>> the assignee should consider filing, along with instructions as to how to
>> do so. The following is what I propose adding:
>>
>> "Please consider creating subtasks of this issue for any of the
>> following or other similar activities that can be accomplished as discrete
>> pieces of work toward this JIRA's overall goal. Please add the 'EE10'
label
>> to any such issue.
>>
>> * Ensuring that the standalone TCK for this spec can be run against a
>> current build of WildFly Preview, and if possible reporting any issues to
>> spec's working group before it is finalized.[1]
>> * Creating a branch for the EE 10 variant in the github repo for the
>> JBoss fork of the spec, based on the appropriate code at Jakarta.[2]
>> * Integrating a milestone release of the spec API into WildFly's main
>> branch.
>> * Integrating a milestone release of the implementation artifacts into
>> WildFly's main branch.
>> * Integrating the final release of the spec API into WildFly's main
>> branch.
>> * Integrating final releases of the implementation artifacts
>>
>> Reminder: WildFly 27 is feature-boxed, so integrating non-final
>> dependencies into main is not just ok, it is encouraged. Doing so lets us
>> identify issues early.
>>
>> We'll be using these finer-grained issues to better track progress on
>>
https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view...
>> and elsewhere."
>>
>> Note that I don't include passing standalone or parts of the platform
>> TCK here, because it's not clear to me that that kind of thing can be
>> cleanly decomposed into discrete pieces of work. We know we need to pass
>> the TCKs.
>>
>> Note also that this message and the related issues are focused on
>> WildFly Preview. Our ultimate goal is to convert the standard WildFly code
>> to EE 10, ideally as soon as possible. But to do that we'll need to
>> complete the work of getting native jakarta.* namespace variants of all our
>> components. That work can proceed in parallel with our work on EE 10 if we
>> continue to do it in WFP for now.
>>
>>
>> [1] I'd only add this to issues where a standalone TCK exists.
>> [2] I'd only add this to issues where we are using a fork of the EE 9.1
>> spec API code in WildFly Preview.
>>
>> Best regards,
>> Brian
>> _______________________________________________
>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
--
James R. Perkins
JBoss by Red Hat
2:46 p.m.
I've added comments as described below to the issues linked to
https://issues.redhat.com/browse/WFLY-15679. Your help with this is much
appreciated. If it's going to take a long time to bring a spec to
completion but most of that is waiting for one tiny piece, like a .Final
version instead of an RC, it will help a *lot* if we can track that the
bulk of the work is done.
Note that I changed the proposed wording to request that JIRA "Subtask"
issues not be used. Please use top level issues (Component Upgrade, Task,
etc) as Subtasks don't show up in JIRA Rapid Boards.
I also discovered that top level JIRAs can be linked with an 'is subtask
of' relationship, which is nice. The main benefit of a Subtask issue is it
establishes that kind of relationship.
Note that I pasted the comment into 27 different issues so I didn't much
try to tailor it to what I know about particular issues. So don't be
confused thinking "Why is Brian saying this when we chatted last week
about...".
On Wed, Feb 23, 2022 at 2:45 PM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
I want to get things started re getting more fine-grained issues
created
for the various EE 10 spec migration issues linked to
https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
directly linked to WFLY-15679 are too coarse-grained, because there are a
number of distinct tasks that can be done separately for each, and to have
a realistic sense of where we stand we need to have visibility into how
things stand with those finer-grained pieces
A good recommendation I got from Tom Jenkinson is to add a comment on the
various per-spec issues outlining the various types of detailed issues the
assignee should consider filing, along with instructions as to how to do
so. The following is what I propose adding:
"Please consider creating subtasks of this issue for any of the following
or other similar activities that can be accomplished as discrete pieces of
work toward this JIRA's overall goal. Please add the 'EE10' label to any
such issue.
* Ensuring that the standalone TCK for this spec can be run against a
current build of WildFly Preview, and if possible reporting any issues to
spec's working group before it is finalized.[1]
* Creating a branch for the EE 10 variant in the github repo for the JBoss
fork of the spec, based on the appropriate code at Jakarta.[2]
* Integrating a milestone release of the spec API into WildFly's main
branch.
* Integrating a milestone release of the implementation artifacts into
WildFly's main branch.
* Integrating the final release of the spec API into WildFly's main branch.
* Integrating final releases of the implementation artifacts
Reminder: WildFly 27 is feature-boxed, so integrating non-final
dependencies into main is not just ok, it is encouraged. Doing so lets us
identify issues early.
We'll be using these finer-grained issues to better track progress on
https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view...
and elsewhere."
Note that I don't include passing standalone or parts of the platform TCK
here, because it's not clear to me that that kind of thing can be cleanly
decomposed into discrete pieces of work. We know we need to pass the TCKs.
Note also that this message and the related issues are focused on WildFly
Preview. Our ultimate goal is to convert the standard WildFly code to EE
10, ideally as soon as possible. But to do that we'll need to complete the
work of getting native jakarta.* namespace variants of all our components.
That work can proceed in parallel with our work on EE 10 if we continue to
do it in WFP for now.
[1] I'd only add this to issues where a standalone TCK exists.
[2] I'd only add this to issues where we are using a fork of the EE 9.1
spec API code in WildFly Preview.
Best regards,
Brian
1007
days inactive
1014
days old
11 comments
3 participants
participants (3)
-
Brian Stansberry -
James Perkins -
Scott Stark