On 2/10/19, sebb <seb...@gmail.com> wrote:
>
> Unfortunately CLI parsing *is* quite complicated.
>
> For example, how do you handle missing parameters?
> Assume -a, -b, -c all take one parameter.
> How do you parse:
>
> $ sample -a one -b -c two
>
> Is that:
> -a => one
> -b => -c
> rest: two
>
> Or does that cause a parsing error, because -b has no parameter?
>
> What if -b has an optional parameter?
> Does that mean -c is set to two?
IMO, if a command line parser finds a line sequence like:
$ sample -a one -b -c two
it should print a warning to System.err and return;
-a:one
-b:null
-c:two
On 2/11/19, Remko Popma <remko.po...@gmail.com> wrote:
> Picocli's value proposition is that it eliminates boilerplate code from the
> application.
But how, by introducing Picocli's own boilerplate code? Did you look
yourself at the sample Picocli code you posted?
From the little corner from which I see reality:
1) All you need is one line of code in your main start up method
(literally, or if you want to nitpick 3):
HashMap<String, String> HM2SKdCtxt = null;
try{ HM2SKdCtxt = (new
JRIContext00()).getJRIContext(System.currentTimeMillis(), aArgs); }
catch(IOException IOX){ IOX.printStackTrace(System.err); }
2) JRIContext (less than 900 lines of code):
2.1) looks into a global file at the well-known, accessible location:
new File((new File(System.getProperty("user.home"))),
".jricontext.default.properties");
that global property files is read in as a plain java properties file
encoded in ISO 8859-1
2.2) looks into the local directory (System.getProperty("user.dir"))
for all files patterned as:
<java_code_name>_jricontext<_encoding>.properties
2.2.1) sort them by last modified
2.2.2) gives user (2?) seconds (to be implemented using a GUI) to
choose the file to be read with the encoding she means
That local <java_code_name>_jricontext<_encoding>.properties is then
read in using an InputStreamReader with the encoding specified right
in the name.
2.3) all global and local settings are "put" in a hashmap, local
settings take precedence over global ones
2.4) JRIContext then parses the command line as its third and last stage
2.5) all command line parameters, global and local settings are "put"
in a hashmap. command line parameters take precedence over global and
local settings (this is handy when you need to do a quick test)
2.6) There are three baseline parameters which for sanity and
security reasons can't be set as part of the java running instance
either in the properties files or command prompt. They are just
included in JRIContext output for the user to avail herself of such
values if she so decides:
2.6.1) current running's class name which key is: "--jri-klass-name"
2.6.2) start up time in milliseconds (used for log files
redirection): "--jri-startup-time-ms"
2.6.3) the global and local properties file (which are hardcoded):
"--jri-local-props-fl"
2.7) using command objects, JRIContext checks the sanity of all input
data before setting the values
2.8) you can in turn script the properties with any value internally
defined either as System.getProperties() or System.getEnv(). Say if
you are testing some code for which you would like System.out and
System.err to indicated in the suffix the "java.runtime.version" and
"os.version" as returned by System.getProperties(), and
"XDG_CURRENT_DESKTOP" and "XDG_SEAT" by System.getEnv(), you would
just indicated in your properties file:
--jri-log-files-suffix:
("java.runtime.version")_("os.version")_("XDG_CURRENT_DESKTOP")_("XDG_SEAT")
~
Check out JRIContext:
https://sourceforge.net/projects/jricontext/files/JRIX/
I just posted all files there as a proof of concept, I coded the
whole things pretty much in one go. I haven't had the time to take a
second look at it to refine, clean up that code, create javadocs ...
I dropped my initial requirement/ideations to use as metasyntax the
extended Backus Naur form (ISO/IEC
14977) and not a HashMap<String><String[]>, but just a
HashMap<String><String> is returned by jricontext (users should take
care of parsing a, say, pipe delimited String into an array String[]).
Users are not forced to enter command line arguments in a strict way
and order and they are able to chose the character encoding of the
data they will be feeding into a program.
I don't know if apache commons accepts "alternate realities", but I
would clean all that code up, make it play better with apache commons
and maintain it.
I find a bit annoying that java hasn't offered such an utility:
java.util.jricontext?
lbrtchx
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
