On Wed, Mar 2, 2022 at 10:50 AM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > As of last week there were no milestone releases for the EE 10 specs > listed at [1] available in maven central. It's not clear when public > releases of some of these specs might be possible. I've directly addressed > the WFLY component leads for the JIRA components that integrate those > because I'd like to get answers to 3 questions: > > 1) Would near term (say next couple weeks) production of a -jbossorg > variant of a milestone of a spec be useful to you? E.g. unblock other > work. Probably this could be done by forking the official spec branch into > our existing JBoss fork repos and publishing a -jbossorg variant of > an existing tag. >

> 2) If not useful near term, an info on when the lack of a public API > milestone would be a problem for you EE 10 work would be useful. > > 3) If useful, could you help? > > I'll create a google sheet to record input. > https://docs.google.com/spreadsheets/d/1ql5hpsqs5ZjawErhyVQX8idigFfm0uZZx... Anyone can read that; if you want to write to it please send me your google account privately. Or you can give input via this thread and I'll add it. > > Note that I'm not talking about using these releases for the long term; > it's just about avoiding needing to use staging repos for WF 27 development > while we wait for releases in maven central. Obviously there is a > cost/benefit tradeoff here, hence the request for input. > > [1] > > 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 > > Best regards, > Brian > -- 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

On Wed, Mar 2, 2022 at 12:05 PM Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > On Wed, Mar 2, 2022 at 5:08 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> >> >> On Wed, Mar 2, 2022 at 10:50 AM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> As of last week there were no milestone releases for the EE 10 specs >>> listed at [1] available in maven central. It's not clear when public >>> releases of some of these specs might be possible. I've directly addressed >>> the WFLY component leads for the JIRA components that integrate those >>> because I'd like to get answers to 3 questions: >>> >>> 1) Would near term (say next couple weeks) production of a -jbossorg >>> variant of a milestone of a spec be useful to you? E.g. unblock other >>> work. Probably this could be done by forking the official spec branch into >>> our existing JBoss fork repos and publishing a -jbossorg variant of >>> an existing tag. >>> >> > It might be worth thinking about how this will look and the flows in git > for this. > > We probably need to keep the option open that the module we are forking > is not final so subject to change so we may need subsequent jbossorg > releases. > > Where we fork a maven project it sounds like it will be two steps to tag, > the first being the migration to add jboss-parent as the parent so we > inherit the configuration to publish to nexus. Secondly would be the > version change to add the jbossorg suffix. > > Where we need to sync from upstream maybe it would be sufficient to use > "git merge" to pull in the upstream changes, add another commit for our > next jbossorg version and tag again? > > Or we could create a new branch each time we need to tag, fork from > upstream, apply the two changes, tag. > Sounds right, although my belief is that we're largely talking about specs that won't be changing much. I *believe* this is mostly about specs where the API is done and available in staging repos, but won't be published in maven central until the spec TCK is finished and the vote happens. If specs are still actively developing their API hopefully they would publish a public milestone.

> >> >>> 2) If not useful near term, an info on when the lack of a public API >>> milestone would be a problem for you EE 10 work would be useful. >>> >>> 3) If useful, could you help? >>> >>> I'll create a google sheet to record input. >>> >> >> >> https://docs.google.com/spreadsheets/d/1ql5hpsqs5ZjawErhyVQX8idigFfm0uZZx... >> >> Anyone can read that; if you want to write to it please send me your >> google account privately. Or you can give input via this thread and I'll >> add it. >> >>> >>> Note that I'm not talking about using these releases for the long term; >>> it's just about avoiding needing to use staging repos for WF 27 development >>> while we wait for releases in maven central. Obviously there is a >>> cost/benefit tradeoff here, hence the request for input. >>> >>> [1] >>> >>> 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 >>> >>> Best regards, >>> Brian >>> >> >> >> -- >> 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 > > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His

None of the specs is under development, so at most what I would expect to see is there might need to be a respin of the staged content to update the javadocs. That has happened, but no one with a staged final API artifact has made a change to it. It might happen for example with JSTL or faces where significant restructuring of the project and building of the tlds has changed and might show a problem as the TCK is finalized. On Wed, Mar 2, 2022 at 12:26 PM Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > On Wed, Mar 2, 2022 at 6:22 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> >> >> On Wed, Mar 2, 2022 at 12:05 PM Darran Lofthouse < >> darran.lofthouse(a)jboss.com&gt; wrote: >> >>> On Wed, Mar 2, 2022 at 5:08 PM Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> >>>> >>>> On Wed, Mar 2, 2022 at 10:50 AM Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> As of last week there were no milestone releases for the EE 10 specs >>>>> listed at [1] available in maven central. It's not clear when public >>>>> releases of some of these specs might be possible. I've directly addressed >>>>> the WFLY component leads for the JIRA components that integrate those >>>>> because I'd like to get answers to 3 questions: >>>>> >>>>> 1) Would near term (say next couple weeks) production of a -jbossorg >>>>> variant of a milestone of a spec be useful to you? E.g. unblock other >>>>> work. Probably this could be done by forking the official spec branch into >>>>> our existing JBoss fork repos and publishing a -jbossorg variant of >>>>> an existing tag. >>>>> >>>> >>> It might be worth thinking about how this will look and the flows in >>> git for this. >>> >>> We probably need to keep the option open that the module we are forking >>> is not final so subject to change so we may need subsequent jbossorg >>> releases. >>> >>> Where we fork a maven project it sounds like it will be two steps to >>> tag, the first being the migration to add jboss-parent as the parent so we >>> inherit the configuration to publish to nexus. Secondly would be the >>> version change to add the jbossorg suffix. >>> >>> Where we need to sync from upstream maybe it would be sufficient to use >>> "git merge" to pull in the upstream changes, add another commit for our >>> next jbossorg version and tag again? >>> >>> Or we could create a new branch each time we need to tag, fork from >>> upstream, apply the two changes, tag. >>> >> >> Sounds right, although my belief is that we're largely talking about >> specs that won't be changing much. I *believe* this is mostly about specs >> where the API is done and available in staging repos, but won't be >> published in maven central until the spec TCK is finished and the vote >> happens. If specs are still actively developing their API hopefully they >> would publish a public milestone. >> > > +1 it sounds like assume we will do it once, but just be prepared in case > a subsequent release is needed. Early naming conventions may be influenced > by the preferred approach. > > >> >>> >>>> >>>>> 2) If not useful near term, an info on when the lack of a public API >>>>> milestone would be a problem for you EE 10 work would be useful. >>>>> >>>>> 3) If useful, could you help? >>>>> >>>>> I'll create a google sheet to record input. >>>>> >>>> >>>> >>>> https://docs.google.com/spreadsheets/d/1ql5hpsqs5ZjawErhyVQX8idigFfm0uZZx... >>>> >>>> Anyone can read that; if you want to write to it please send me your >>>> google account privately. Or you can give input via this thread and I'll >>>> add it. >>>> >>>>> >>>>> Note that I'm not talking about using these releases for the long >>>>> term; it's just about avoiding needing to use staging repos for WF 27 >>>>> development while we wait for releases in maven central. Obviously there is >>>>> a cost/benefit tradeoff here, hence the request for input. >>>>> >>>>> [1] >>>>> >>>>> 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 >>>>> >>>>> Best regards, >>>>> Brian >>>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> >> >> -- >> 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 _______________________________________________ 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

I can take it on since this impacts our getting WildFly certified for EE10. What GitHub org would I use for these forked repos? On Mar 3, 2022 at 10:25:39 AM, James Perkins <jperkins(a)redhat.com&gt; wrote: > I do think this would be nice if someone is willing to manage it. I can > say with RESTEasy for the Jakarta REST dependencies only I'm using the > Jakarta EE staging repository which is not ideal. It essentially pollutes > anyones local maven repository that who builds RESTEasy on it's main > branch. I also have to do some ugly hacks to get the TCK to download to use > it as a dependency. > > As for changes, I can say there is likely at least one TCK change coming > to the Jakarta REST TCK, but it's just a test change. > > On Wed, Mar 2, 2022 at 4:21 PM Scott Stark <sstark(a)redhat.com&gt; wrote: > >> None of the specs is under development, so at most what I would expect >> to see is there might need to be a respin of the staged content to update >> the javadocs. That has happened, but no one with a staged final API >> artifact has made a change to it. It might happen for example with JSTL or >> faces where significant restructuring of the project and building of the >> tlds has changed and might show a problem as the TCK is finalized. >> >> On Wed, Mar 2, 2022 at 12:26 PM Darran Lofthouse < >> darran.lofthouse(a)jboss.com&gt; wrote: >> >>> On Wed, Mar 2, 2022 at 6:22 PM Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> >>>> >>>> On Wed, Mar 2, 2022 at 12:05 PM Darran Lofthouse < >>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>> >>>>> On Wed, Mar 2, 2022 at 5:08 PM Brian Stansberry < >>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 2, 2022 at 10:50 AM Brian Stansberry < >>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>> >>>>>>> As of last week there were no milestone releases for the EE 10 >>>>>>> specs listed at [1] available in maven central. It's not clear when public >>>>>>> releases of some of these specs might be possible. I've directly addressed >>>>>>> the WFLY component leads for the JIRA components that integrate those >>>>>>> because I'd like to get answers to 3 questions: >>>>>>> >>>>>>> 1) Would near term (say next couple weeks) production of a >>>>>>> -jbossorg variant of a milestone of a spec be useful to you? E.g. unblock >>>>>>> other work. Probably this could be done by forking the official spec >>>>>>> branch into our existing JBoss fork repos and publishing a -jbossorg >>>>>>> variant of an existing tag. >>>>>>> >>>>>> >>>>> It might be worth thinking about how this will look and the flows in >>>>> git for this. >>>>> >>>>> We probably need to keep the option open that the module we are >>>>> forking is not final so subject to change so we may need subsequent >>>>> jbossorg releases. >>>>> >>>>> Where we fork a maven project it sounds like it will be two steps to >>>>> tag, the first being the migration to add jboss-parent as the parent so we >>>>> inherit the configuration to publish to nexus. Secondly would be the >>>>> version change to add the jbossorg suffix. >>>>> >>>>> Where we need to sync from upstream maybe it would be sufficient to >>>>> use "git merge" to pull in the upstream changes, add another commit for our >>>>> next jbossorg version and tag again? >>>>> >>>>> Or we could create a new branch each time we need to tag, fork from >>>>> upstream, apply the two changes, tag. >>>>> >>>> >>>> Sounds right, although my belief is that we're largely talking about >>>> specs that won't be changing much. I *believe* this is mostly about specs >>>> where the API is done and available in staging repos, but won't be >>>> published in maven central until the spec TCK is finished and the vote >>>> happens. If specs are still actively developing their API hopefully they >>>> would publish a public milestone. >>>> >>> >>> +1 it sounds like assume we will do it once, but just be prepared in >>> case a subsequent release is needed. Early naming conventions may be >>> influenced by the preferred approach. >>> >>> >>>> >>>>> >>>>>> >>>>>>> 2) If not useful near term, an info on when the lack of a public >>>>>>> API milestone would be a problem for you EE 10 work would be useful. >>>>>>> >>>>>>> 3) If useful, could you help? >>>>>>> >>>>>>> I'll create a google sheet to record input. >>>>>>> >>>>>> >>>>>> >>>>>> https://docs.google.com/spreadsheets/d/1ql5hpsqs5ZjawErhyVQX8idigFfm0uZZx... >>>>>> >>>>>> Anyone can read that; if you want to write to it please send me your >>>>>> google account privately. Or you can give input via this thread and I'll >>>>>> add it. >>>>>> >>>>>>> >>>>>>> Note that I'm not talking about using these releases for the long >>>>>>> term; it's just about avoiding needing to use staging repos for WF 27 >>>>>>> development while we wait for releases in maven central. Obviously there is >>>>>>> a cost/benefit tradeoff here, hence the request for input. >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> Best regards, >>>>>>> Brian >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>>> >>>> >>>> -- >>>> 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 >> >> _______________________________________________ >> 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 >

Into which JBoss org are we forking these jakartaee and eclipse-ee4j repos is the question? On Mar 3, 2022 at 10:58:03 AM, James Perkins <jperkins(a)redhat.com&gt; wrote: > For Jakarta REST it's https://github.com/jakartaee/rest. If everyone > else agrees with doing this I'm happy to get a full list together for the > ones in question. If we want to just test with one first though I'm happy > to have RESTEasy be the tester. > > On Thu, Mar 3, 2022 at 8:54 AM Scott Stark <sstark(a)redhat.com&gt; wrote: > >> I can take it on since this impacts our getting WildFly certified for >> EE10. What GitHub org would I use for these forked repos? >> > > _______________________________________________ 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

Oh sorry, my mistake :) I would guess https://github.com/jboss/jboss-jakarta-jaxrs-api_spec and each other spec likely has one there with a few exceptions. If you need access to the repository just let me know. On Thu, Mar 3, 2022 at 9:12 AM Scott Stark <sstark(a)redhat.com&gt; wrote: > Into which JBoss org are we forking these jakartaee and eclipse-ee4j > repos is the question? > > On Mar 3, 2022 at 10:58:03 AM, James Perkins <jperkins(a)redhat.com&gt; wrote: > >> For Jakarta REST it's https://github.com/jakartaee/rest. If everyone >> else agrees with doing this I'm happy to get a full list together for the >> ones in question. If we want to just test with one first though I'm happy >> to have RESTEasy be the tester. >> >

>> On Thu, Mar 3, 2022 at 8:54 AM Scott Stark <sstark(a)redhat.com&gt; wrote: >> >>> I can take it on since this impacts our getting WildFly certified for >>> EE10. What GitHub org would I use for these forked repos? >>> >> >> -- 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

On Thu, Mar 3, 2022 at 9:39 AM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Thu, Mar 3, 2022 at 11:18 AM James Perkins <jperkins(a)redhat.com&gt; > wrote: > >> Oh sorry, my mistake :) I would guess >> https://github.com/jboss/jboss-jakarta-jaxrs-api_spec and each other >> spec likely has one there with a few exceptions. If you need access to the >> repository just let me know. >> >> On Thu, Mar 3, 2022 at 9:12 AM Scott Stark <sstark(a)redhat.com&gt; wrote: >> >>> Into which JBoss org are we forking these jakartaee and eclipse-ee4j >>> repos is the question? >>> >>> On Mar 3, 2022 at 10:58:03 AM, James Perkins <jperkins(a)redhat.com&gt; >>> wrote: >>> >>>> For Jakarta REST it's https://github.com/jakartaee/rest. If everyone >>>> else agrees with doing this I'm happy to get a full list together for the >>>> ones in question. If we want to just test with one first though I'm happy >>>> to have RESTEasy be the tester. >>>> >>> > I added a column to > https://docs.google.com/spreadsheets/d/1ql5hpsqs5ZjawErhyVQX8idigFfm0uZZx.... > Let's track data there. If people want write access please ping me with the > google account to use. > > I don't think we should do these unless the people driving our > integration of a spec ask. We shouldn't spend time producing forks/releases > if there won't be much benefit. > I guess "benefit" is somewhat relative. There is definitely a cost to using the forked version. It requires the time to handle it and brings the question of "how often do we rebase?". What RESTEasy is doing does work. However, as I said it's polluting the local repository of anyone that builds RESTEasy's main branch. One option I've thought of, but haven't tested, was to see if there is a way with the maven-scm-plugin and the org.codehaus.mojo plugin to create a fork during the build. I can have a look at this as it seems easier at least than fully forking a repository. We wouldn't deploy these artifacts into Nexus, but they could at least be used for local testing without polluting the local repository. > > >>>> On Thu, Mar 3, 2022 at 8:54 AM Scott Stark <sstark(a)redhat.com&gt; wrote: >>>> >>>>> I can take it on since this impacts our getting WildFly certified for >>>>> EE10. What GitHub org would I use for these forked repos? >>>>> >>>> >>>> >> >> -- >> 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

Interesting. Why couldn't that be deployed? Doing so from the RESTEasy build probably isn't good, but a branch in https://github.com/jboss/jboss-jakarta-jaxrs-api_spec with just pom like you have seems reasonable. It's just a different way of getting the source, and is analogous to what WildFly is doing with all our ee-9/source-transform modules.

On Thu, Mar 3, 2022 at 3:26 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > I'm not sure if this is technically allowed, but this does seem to work > https://github.com/resteasy/resteasy/pull/3039. A pseudo fork so to > speak. > > On Thu, Mar 3, 2022 at 11:44 AM James Perkins <jperkins(a)redhat.com&gt; > wrote: > >> >> >> On Thu, Mar 3, 2022 at 9:39 AM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Thu, Mar 3, 2022 at 11:18 AM James Perkins <jperkins(a)redhat.com&gt; >>> wrote: >>> >>>> Oh sorry, my mistake :) I would guess >>>> https://github.com/jboss/jboss-jakarta-jaxrs-api_spec and each other >>>> spec likely has one there with a few exceptions. If you need access to the >>>> repository just let me know. >>>> >>>> On Thu, Mar 3, 2022 at 9:12 AM Scott Stark <sstark(a)redhat.com&gt; wrote: >>>> >>>>> Into which JBoss org are we forking these jakartaee and eclipse-ee4j >>>>> repos is the question? >>>>> >>>>> On Mar 3, 2022 at 10:58:03 AM, James Perkins <jperkins(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> For Jakarta REST it's https://github.com/jakartaee/rest. If >>>>>> everyone else agrees with doing this I'm happy to get a full list together >>>>>> for the ones in question. If we want to just test with one first though I'm >>>>>> happy to have RESTEasy be the tester. >>>>>> >>>>> >>> I added a column to >>> https://docs.google.com/spreadsheets/d/1ql5hpsqs5ZjawErhyVQX8idigFfm0uZZx.... >>> Let's track data there. If people want write access please ping me with the >>> google account to use. >>> >>> I don't think we should do these unless the people driving our >>> integration of a spec ask. We shouldn't spend time producing forks/releases >>> if there won't be much benefit. >>> >> >> I guess "benefit" is somewhat relative. There is definitely a cost to >> using the forked version. It requires the time to handle it and brings the >> question of "how often do we rebase?". What RESTEasy is doing does work. >> However, as I said it's polluting the local repository of anyone that >> builds RESTEasy's main branch. >> >> One option I've thought of, but haven't tested, was to see if there is a >> way with the maven-scm-plugin and the org.codehaus.mojo plugin to create a >> fork during the build. I can have a look at this as it seems easier at >> least than fully forking a repository. We wouldn't deploy these artifacts >> into Nexus, but they could at least be used for local testing without >> polluting the local repository. >> >> >>> >>> >>>>>> On Thu, Mar 3, 2022 at 8:54 AM Scott Stark <sstark(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> I can take it on since this impacts our getting WildFly certified >>>>>>> for EE10. What GitHub org would I use for these forked repos? >>>>>>> >>>>>> >>>>>> >>>> >>>> -- >>>> 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 >> > > > -- > James R. Perkins > JBoss by Red Hat > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His