Re: [DISCUSS][2.0] FLIP-337: Remove JarRequestBody#programArgs
+1 @Chesnay ScheplerI'd like to be assigned the task to try to do it ~ Jing Ge 于2023年7月18日周二 17:54写道： > got it thanks! > > For @Deprecated, I meant to force using like: @Deprecated(since = "1.18", > forRemoval = true) > > Best regards, > Jing > > On Tue, Jul 18, 2023 at 11:06 AM Hong Teoh wrote: > > > +1 to this. Nice to simplify the REST API! > > > > > > Regards, > > Hong > > > > > > > On 18 Jul 2023, at 10:00, Chesnay Schepler wrote: > > > > > > Something to note is that the UI is using this parameter, and would > have > > to be changed to the new one. > > > > > > Since we want to avoid having to split arguments ourselves, this may > > imply changes to the UI. > > > > > > On 18/07/2023 10:18, Chesnay Schepler wrote: > > >> We'll log a warn message when it is used and maybe hide it from the > > docs. > > >> > > >> Archunit rule doesn't really work here because it's not annotated with > > stability annotations (as it shouldn't since the classes aren't really > > user-facing). > > >> > > >> On 17/07/2023 21:56, Jing Ge wrote: > > >>> Hi Chesnay, > > >>> > > >>> I am trying to understand what is the right removal process with this > > >>> concrete example. Given all things about the programArgs are private > or > > >>> package private except the constructor. Will you just mark it as > > deprecated > > >>> with constructor overloading in 1.18 and remove it in 2.0? Should we > > >>> describe the deprecation work in the FLIP? > > >>> > > >>> Another more general question, maybe offtrack, I don't know which > > thread is > > >>> the right place to ask, since Java 11 has been recommended, should we > > >>> always include "since" and "forRemoval" while adding @Deprecated, > i.e. > > >>> ArchUnit rule? > > >>> > > >>> Best regards, > > >>> Jing > > >>> > > >>> On Mon, Jul 17, 2023 at 5:33 AM Xintong Song > > wrote: > > >>> > > +1 > > > > Best, > > > > Xintong > > > > > > > > On Thu, Jul 13, 2023 at 9:34 PM Chesnay Schepler < > ches...@apache.org> > > wrote: > > > > > Hello, > > > > > > The request body for the jar run/plan REST endpoints accepts > program > > > arguments as a string (programArgs) or a list of strings > > > (programArgsList). The latter was introduced as kept running into > > issues > > > with splitting the string into individual arguments./ > > > / > > > > > > We ideally force users to use the list argument, and we can > simplify > > the > > > codebase if there'd only be 1 way to pass arguments. > > > > > > As such I propose to remove the programArgs field from the request > > body. > > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263424796 > > > > > > Regards, > > > > > > Chesnay > > > > > >> > > > > > > > > -- Best ConradJam
Re: [DISCUSS][2.0] FLIP-337: Remove JarRequestBody#programArgs
got it thanks! For @Deprecated, I meant to force using like: @Deprecated(since = "1.18", forRemoval = true) Best regards, Jing On Tue, Jul 18, 2023 at 11:06 AM Hong Teoh wrote: > +1 to this. Nice to simplify the REST API! > > > Regards, > Hong > > > > On 18 Jul 2023, at 10:00, Chesnay Schepler wrote: > > > > Something to note is that the UI is using this parameter, and would have > to be changed to the new one. > > > > Since we want to avoid having to split arguments ourselves, this may > imply changes to the UI. > > > > On 18/07/2023 10:18, Chesnay Schepler wrote: > >> We'll log a warn message when it is used and maybe hide it from the > docs. > >> > >> Archunit rule doesn't really work here because it's not annotated with > stability annotations (as it shouldn't since the classes aren't really > user-facing). > >> > >> On 17/07/2023 21:56, Jing Ge wrote: > >>> Hi Chesnay, > >>> > >>> I am trying to understand what is the right removal process with this > >>> concrete example. Given all things about the programArgs are private or > >>> package private except the constructor. Will you just mark it as > deprecated > >>> with constructor overloading in 1.18 and remove it in 2.0? Should we > >>> describe the deprecation work in the FLIP? > >>> > >>> Another more general question, maybe offtrack, I don't know which > thread is > >>> the right place to ask, since Java 11 has been recommended, should we > >>> always include "since" and "forRemoval" while adding @Deprecated, i.e. > >>> ArchUnit rule? > >>> > >>> Best regards, > >>> Jing > >>> > >>> On Mon, Jul 17, 2023 at 5:33 AM Xintong Song > wrote: > >>> > +1 > > Best, > > Xintong > > > > On Thu, Jul 13, 2023 at 9:34 PM Chesnay Schepler > wrote: > > > Hello, > > > > The request body for the jar run/plan REST endpoints accepts program > > arguments as a string (programArgs) or a list of strings > > (programArgsList). The latter was introduced as kept running into > issues > > with splitting the string into individual arguments./ > > / > > > > We ideally force users to use the list argument, and we can simplify > the > > codebase if there'd only be 1 way to pass arguments. > > > > As such I propose to remove the programArgs field from the request > body. > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263424796 > > > > Regards, > > > > Chesnay > > > >> > > > >
Re: [DISCUSS][2.0] FLIP-337: Remove JarRequestBody#programArgs
+1 to this. Nice to simplify the REST API! Regards, Hong > On 18 Jul 2023, at 10:00, Chesnay Schepler wrote: > > Something to note is that the UI is using this parameter, and would have to > be changed to the new one. > > Since we want to avoid having to split arguments ourselves, this may imply > changes to the UI. > > On 18/07/2023 10:18, Chesnay Schepler wrote: >> We'll log a warn message when it is used and maybe hide it from the docs. >> >> Archunit rule doesn't really work here because it's not annotated with >> stability annotations (as it shouldn't since the classes aren't really >> user-facing). >> >> On 17/07/2023 21:56, Jing Ge wrote: >>> Hi Chesnay, >>> >>> I am trying to understand what is the right removal process with this >>> concrete example. Given all things about the programArgs are private or >>> package private except the constructor. Will you just mark it as deprecated >>> with constructor overloading in 1.18 and remove it in 2.0? Should we >>> describe the deprecation work in the FLIP? >>> >>> Another more general question, maybe offtrack, I don't know which thread is >>> the right place to ask, since Java 11 has been recommended, should we >>> always include "since" and "forRemoval" while adding @Deprecated, i.e. >>> ArchUnit rule? >>> >>> Best regards, >>> Jing >>> >>> On Mon, Jul 17, 2023 at 5:33 AM Xintong Song wrote: >>> +1 Best, Xintong On Thu, Jul 13, 2023 at 9:34 PM Chesnay Schepler wrote: > Hello, > > The request body for the jar run/plan REST endpoints accepts program > arguments as a string (programArgs) or a list of strings > (programArgsList). The latter was introduced as kept running into issues > with splitting the string into individual arguments./ > / > > We ideally force users to use the list argument, and we can simplify the > codebase if there'd only be 1 way to pass arguments. > > As such I propose to remove the programArgs field from the request body. > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263424796 > > Regards, > > Chesnay > >> >
Re: [DISCUSS][2.0] FLIP-337: Remove JarRequestBody#programArgs
Something to note is that the UI is using this parameter, and would have to be changed to the new one. Since we want to avoid having to split arguments ourselves, this may imply changes to the UI. On 18/07/2023 10:18, Chesnay Schepler wrote: We'll log a warn message when it is used and maybe hide it from the docs. Archunit rule doesn't really work here because it's not annotated with stability annotations (as it shouldn't since the classes aren't really user-facing). On 17/07/2023 21:56, Jing Ge wrote: Hi Chesnay, I am trying to understand what is the right removal process with this concrete example. Given all things about the programArgs are private or package private except the constructor. Will you just mark it as deprecated with constructor overloading in 1.18 and remove it in 2.0? Should we describe the deprecation work in the FLIP? Another more general question, maybe offtrack, I don't know which thread is the right place to ask, since Java 11 has been recommended, should we always include "since" and "forRemoval" while adding @Deprecated, i.e. ArchUnit rule? Best regards, Jing On Mon, Jul 17, 2023 at 5:33 AM Xintong Song wrote: +1 Best, Xintong On Thu, Jul 13, 2023 at 9:34 PM Chesnay Schepler wrote: Hello, The request body for the jar run/plan REST endpoints accepts program arguments as a string (programArgs) or a list of strings (programArgsList). The latter was introduced as kept running into issues with splitting the string into individual arguments./ / We ideally force users to use the list argument, and we can simplify the codebase if there'd only be 1 way to pass arguments. As such I propose to remove the programArgs field from the request body. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263424796 Regards, Chesnay
Re: [DISCUSS][2.0] FLIP-337: Remove JarRequestBody#programArgs
We'll log a warn message when it is used and maybe hide it from the docs. Archunit rule doesn't really work here because it's not annotated with stability annotations (as it shouldn't since the classes aren't really user-facing). On 17/07/2023 21:56, Jing Ge wrote: Hi Chesnay, I am trying to understand what is the right removal process with this concrete example. Given all things about the programArgs are private or package private except the constructor. Will you just mark it as deprecated with constructor overloading in 1.18 and remove it in 2.0? Should we describe the deprecation work in the FLIP? Another more general question, maybe offtrack, I don't know which thread is the right place to ask, since Java 11 has been recommended, should we always include "since" and "forRemoval" while adding @Deprecated, i.e. ArchUnit rule? Best regards, Jing On Mon, Jul 17, 2023 at 5:33 AM Xintong Song wrote: +1 Best, Xintong On Thu, Jul 13, 2023 at 9:34 PM Chesnay Schepler wrote: Hello, The request body for the jar run/plan REST endpoints accepts program arguments as a string (programArgs) or a list of strings (programArgsList). The latter was introduced as kept running into issues with splitting the string into individual arguments./ / We ideally force users to use the list argument, and we can simplify the codebase if there'd only be 1 way to pass arguments. As such I propose to remove the programArgs field from the request body. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263424796 Regards, Chesnay
Re: [DISCUSS][2.0] FLIP-337: Remove JarRequestBody#programArgs
Hi Chesnay, I am trying to understand what is the right removal process with this concrete example. Given all things about the programArgs are private or package private except the constructor. Will you just mark it as deprecated with constructor overloading in 1.18 and remove it in 2.0? Should we describe the deprecation work in the FLIP? Another more general question, maybe offtrack, I don't know which thread is the right place to ask, since Java 11 has been recommended, should we always include "since" and "forRemoval" while adding @Deprecated, i.e. ArchUnit rule? Best regards, Jing On Mon, Jul 17, 2023 at 5:33 AM Xintong Song wrote: > +1 > > Best, > > Xintong > > > > On Thu, Jul 13, 2023 at 9:34 PM Chesnay Schepler > wrote: > > > Hello, > > > > The request body for the jar run/plan REST endpoints accepts program > > arguments as a string (programArgs) or a list of strings > > (programArgsList). The latter was introduced as kept running into issues > > with splitting the string into individual arguments./ > > / > > > > We ideally force users to use the list argument, and we can simplify the > > codebase if there'd only be 1 way to pass arguments. > > > > As such I propose to remove the programArgs field from the request body. > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263424796 > > > > > > Regards, > > > > Chesnay > > >
Re: [DISCUSS][2.0] FLIP-337: Remove JarRequestBody#programArgs
+1 Best, Xintong On Thu, Jul 13, 2023 at 9:34 PM Chesnay Schepler wrote: > Hello, > > The request body for the jar run/plan REST endpoints accepts program > arguments as a string (programArgs) or a list of strings > (programArgsList). The latter was introduced as kept running into issues > with splitting the string into individual arguments./ > / > > We ideally force users to use the list argument, and we can simplify the > codebase if there'd only be 1 way to pass arguments. > > As such I propose to remove the programArgs field from the request body. > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263424796 > > > Regards, > > Chesnay >
