Enable platform to contribute default config to project and provide global metadata usable in tooling

[maxandersen]

Description
It would be interesting to enable the platform descriptor to provide input to the initial setup of a project.

Known items:

• base image for docker native builds
• add maven repositories

Implementation ideas
have metadata in platform to seed project generation.

[maxandersen]

advantages:

• no need for different semantics/diffs of quarkus core
• its clearly documented and explicit to user what is "different"

disadvantages:

• will (currently) only work for new projects
• if platform changes its default user won't get updated; but maybe we can print a warning or add a "lint"-check to detect such.

caveat:

• if diff relevant for extensions we don't have a way to handle it. Would need codestarts that can execute during new addition.

[maxandersen]

From chat:

Figure out A) how the container image will be configurable B) how to represent that somewhere in the platform artifact (platform.json or somewhere else) C) how codestarts hook that into its data D) if/how legacy codegen handles this E) make this wokr in both command line and code.quarkus F) Adjust A - E if one affects the other 😉

[ia3andy]

It seems this issue is also related: #11096

[maxandersen]

Suggestion:

• we add "metadata" to platform.json.
• add keys for:
  • application-properties
  • maven-repos
  • etc.
• for 1.7.x only add these metadata in redhat universe/platform.
  consequence:
• 1.7.0 will fail on platform.json with metadata, but not a big concern if we only do it for red hat universe.

Codegeneration:

• choice between doing this in codestarts or good old gen:
  • old gen:
    • requires changes to pom/gradle/properties generation
• codestart:
  • suggestion is to use codestart for good old codegen and have flag to enable the more advanced codestarts features.

Best if we can change default platform fetch #11259 to just fetch latest minor (1.7.x instead of 1.x)

[aloubyansky]

i'd say

metadata
- project-configuration
-- application-properties
-- maven
--- properties
--- repositories
--- plugin-repositories
-- gradle
--- properties
--- repositories
--- plugin-repositories

[maxandersen]

example:

- metadata:
  - application-properties:
    - quarkus.native.builder-image: yadydada:234324
  - maven:
    - repositories:
      - id:  redhat
      - url: https://maven.repository.redhat.com
    - plugin-repositories:
      - id:  redhat
      - url  https://maven.repository.redhat.com
   - gradle:
     - repositories:
       - id:  redhat
       - url: https://maven.repository.redhat.com

[ia3andy]

@aloubyansky @maxandersen minor detail, will the application-properties be received as Properties or Map<String, String>?

[maxandersen]

There are no properties here. Just maps.

[aloubyansky]

application-properties are supposed to be <String,String> though. So, imo, it depends what you prefer @ia3andy

[gastaldi]

Outcome from the Zulip conversation:

Implement a config source that is assembled at build time and puts stuff into a special namespace platform.xxxx and then we can change the image config property default to be platform.image.url

[ia3andy]

This is done