+1 @Chesnay Schepler <ches...@apache.org> I'd like to be assigned the task to try to do it ~
Jing Ge <j...@ververica.com.invalid> 于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 <hlteo...@gmail.com> wrote: > > > +1 to this. Nice to simplify the REST API! > > > > > > Regards, > > Hong > > > > > > > On 18 Jul 2023, at 10:00, Chesnay Schepler <ches...@apache.org> 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 <tonysong...@gmail.com> > > 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