Draft CLI test

[buchen]

For experimenting. I haven't looked at the code in detail. It is using the existing JSON and CSV formats.

./PortfolioPerformance.app/Contents/MacOS/PortfolioPerformance \
    -nosplash \
    -application name.abuchen.portfolio.cli.app \
    --file ~/Downloads/kommer.xml \
    --export transactions \
    --format json

Not sure if one can reduce the command line (splash, application). There are also log entries I cannot suppress (or do not know how to suppress yet).

[georgemac-labs]

@buchen LGTM!

Codex claims there is no straightforward way to detect CLI vs GUI invocation, nor to get rid of the SPI Fly INFO logging. It only has a good solution for the incubator modules line...

1. To remove incubator warning

   • In name.abuchen.portfolio.product:10 and name.abuchen.portfolio.distro.product:11, replace:
     • --add-modules=ALL-SYSTEM
     • with --add-modules=java.se (or remove entirely if not needed).
   • Result: removes Using incubator modules: jdk.incubator.vector

2. Add a dedicated pp-cli launcher script

   • Script always adds:
     • -application name.abuchen.portfolio.cli.app
     • -nosplash
     • -Djava.util.logging.config.file=
   • Result: short syntax for users and no SPI Fly INFO noise.

3. Optional later (more invasive): true auto-detect UI vs CLI by args

   • Implement a router application and make it the default application=....

[buchen]

I would say with the "garbage" on the output stream, the CLI is of limited use.

get rid of the SPI Fly INFO logging

We could try two ways:

• Understand what logging framework this component is using and configure a "no op" logger that writes nothing. This is the repository https://github.com/apache/aries/tree/trunk/spi-fly
• Deactivate the SPI Fly component when using the command line. It is used to expose to OSGi the ImageIO libraries. Those are needed to read the logo images. But in the CLI use case, we could live without.

with --add-modules=java.se

That seems to work.

Add a dedicated pp-cli launcher script

As the CLI is not the primary use case for PP, I think it is okay to have a couple additional parameters on the command line. I wouldn't want to spend time there now.

[georgemac-labs]

I would say with the "garbage" on the output stream, the CLI is of limited use.

I think it's fine as a first step. The noisy output is a little ugly, but it's still totally usable. And above all: the junk is getting printed to stderr, not stdout. So it's easy to control what you get, and a basic pipe or redirect will already give you only the data, not the junk.

And if an AI model is "reading" the output, they are very capable of ignoring noise and finding what they're looking for.

For most users, they will never know this functionality is there, so it doesn't need to be polished IMO. It's usable for those who want it. If you want, you could also add a warning that it's developmental and the syntax might change.

As the CLI is not the primary use case for PP, I think it is okay to have a couple additional parameters on the command line. I wouldn't want to spend time there now.

Fair enough.

For me, this is viable as it is. Only small thing I might consider is setting exit code > 0, at least for common error cases. Because it's part of the core CLI contract and hopefully just a couple of lines. E.g. input file not found exit(1). Bad syntax exit(2).

This doesn't yet do everything I want, as I'd want derived data as well (trades, metrics), but for me it's a sensible MVP.