Hi Jingsong, I think your propose is "--classpath can occur behind the jar file".
Generally speaking I agree on that it is a painful required format that users tend to just ignore that order how an option occurs. So it is +1 from my side to loose the constraint. However, for the migration and implementation part, things go into a bit tricky. For user interface, let's say we only enable --classpath to occur behind the jar file, at least the semantic changes if there is a user pass --classpath intended to be a main argument. Besides, said we fix on the library commons-cli to implement the CLI, it would be a bit tricky we implement such special taken logic. Accidentally I encounter similar CLI problem recently so here are some of my thoughts about the problem, 1. I agree that for options, users tend to treat <jar-file> the same as [OPTIONS] and mix up the order. It would be an improvement we loss the constraint. 2. Then, we still have to introduce something that users specify their args for the main method. 3. In order to achieve 2, there is a mature solution in shell scripting that use double-dash(--) to to signify the end of command options. 4. Now, if we keep <jar-file> as position argument, to support mix-ordered position argument & named argument, we might switch to other library such as argparse4j since commons-cli doesn't support position argument. An alternative is we change <jar-file> as named argument but then we double break user interface. Though, it will break user interface so we firstly **MUST** start a discussion and see whether the community think of it and if so, how to integrate it. For me, read the doc is an easy solution to save us from breaking user interface. I don't stick to loose the constraint. Best, tison. Jingsong Li <jingsongl...@gmail.com> 于2020年3月6日周五 下午10:27写道： > Hi tison and Aljoscha, > > Do you think "--classpath can not be in front of jar file" is an > improvement? Or need documentation? Because I used to be confused. > > Best, > Jingsong Lee > > On Fri, Mar 6, 2020 at 10:22 PM tison <wander4...@gmail.com> wrote: > >> I think the problem is that --classpath should be before the user jar, >> i.e., /opt/flink/job/kafkaDemo19-1.0-SNAPSHOT.jar >> >> Best, >> tison. >> >> >> Aljoscha Krettek <aljos...@apache.org> 于2020年3月6日周五 下午10:03写道： >> >>> Hi, >>> >>> first a preliminary question: does the jar file contain >>> com.alibaba.fastjson.JSON? Could you maybe list the contents of the jar >>> here? >>> >>> Best, >>> Aljoscha >>> >>> On 06.03.20 13:25, ouywl wrote: >>> > Hi all >>> > When I start a flinkcluster in session mode, It include jm/tm. >>> And then I >>> > submit a job like ‘bin/flink run —jobmanager “ip:8081” —class path >>> a.jar’. Even >>> > the a.jar in all jm/tm and ‘bin/flink’ mechine . It will throw >>> exception “ >>> > /opt/flink/bin/flink run --jobmanager ip:8081 --class >>> > com.netease.java.TopSpeedWindowing --parallelism 1 --detached >>> > /opt/flink/job/kafkaDemo19-1.0-SNAPSHOT.jar --classpath >>> > file:///opt/flink/job/fastjson-1.2.66.jar >>> > Starting execution of program >>> > Executing TopSpeedWindowing example with default input data set. >>> > Use --input to specify file input. >>> > java.lang.NoClassDefFoundError: com/alibaba/fastjson/JSON >>> > at com.netease.java.TopSpeedWindowing.main(TopSpeedWindowing.java:98) >>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> > at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> > at >>> > >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> > at java.lang.reflect.Method.invoke(Method.java:498) >>> > at >>> > >>> org.apache.flink.client.program.PackagedProgram.callMainMethod(PackagedProgram.java:576) >>> > at >>> > >>> org.apache.flink.client.program.PackagedProgram.invokeInteractiveModeForExecution(PackagedProgram.java:438) >>> > at >>> org.apache.flink.client.program.ClusterClient.run(ClusterClient.java:274) >>> > at >>> org.apache.flink.client.cli.CliFrontend.executeProgram(CliFrontend.java:746)” >>> > As I read the code , flink cli have not load the —classspath jar, >>> So It seems >>> > a bug about the flink cli. Are you agree with me? >>> > Best, >>> > Ouywl >>> > >>> >> > > -- > Best, Jingsong Lee >
