CLI

[m0mus]

Command line utility with functionality discussed here:
https://gist.github.com/barchetta/908b7d5f9a2c63344a86146809b07283

• One pager
• POC to evaluate critical choices (e.g. dependencies on external libraries)
• Setup the CLI harness
  • Evaluate existing CLI framework like arg4j
  • Evaluate in-house CLI tool
  • Compile to native binary with native-image
  • Support a project configuration (e.g. .helidon.yaml) (???)
• Project Initialization (helidon init) (2.0)
  • Interactive mode (command prompt based on user flow) (2.0)
    • User flow model (2.0)
  • Batch mode (command line arguments mapped to user flow) (2.0)
  • Templating
    • Setup engine with common infra (2.0)
    • Maven templates (2.0)
    • Gradle templates (2.x)
    • Common templates (2.0)
    • Support add/update/delete features (for MP)
    • Support add/update/delete features (for SE)
  • Test harness (generate test combination from user flow)
• Incremental Build, Restart, Redeploy (helidon dev)
  • Evaluate Gradle's incremental support
  • Implement a watcher service
  • Implement a generic way to resume Maven life-cycle
  • Incremental restart
  • Incremental re-deploy
• Application Building (helidon build)
  • Simplified packaging
    • Support "modes" (native, java-image, docker)
    • Unified configuration
    • Maven support
    • Gradle support
  • Docker daemon less image build/push
    • Evaluate the use of jib-core
    • Evaluate an in-house image tool
• Application Deployment (helidon deploy)
  • Evaluate a library to interact with k8s
  • Evaluate an in-house k8s client library
  • Evaluate support for advanced CD scenarios
• Documentation
  • CLI guide
  • Update existing guides to use CLI instead of maven archetypes
• Release
  • Host download
  • Evaluate use of SDKMAN

[romain-grecourt]

@m0mus I've tried to decouple this in multiple items. However I think this deserves a one pager and maybe a few POCs.

[m0mus]

@romain-grecourt It's fine. Add sub-tasks for a one pager and the first PoC.

[tomas-langer]

Configuration approach I think we should use:
Configuration files are combined in meta-config.yaml
Each feature that requires configuration can have its own configuration file, e.g. tracing.yaml, jpa.yaml. When such a feature is added to Helidon, the config file would be added to meta-config.yaml

meta-config.yaml is automatically picked-up by Helidon Config.

Example of meta-config.yaml:

sources:
  - type: "environment-variables"
  - type: "system-properties"
  - type: "file"
      properties:
        # when using k8s
        path: "/conf/config.yaml"
        optional: true
  - type: "classpath"
      properties:
        resource: "conf/application.yaml"
  - type: "classpath"
      properties:
        resource: "conf/jpa.yaml"