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 > >>>>> > >> > > > >
