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
