Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[YAML] [Structure] Alternative String form for dependencies #253

Open
dragetd opened this issue Dec 14, 2022 · 1 comment
Open

[YAML] [Structure] Alternative String form for dependencies #253

dragetd opened this issue Dec 14, 2022 · 1 comment

Comments

@dragetd
Copy link

dragetd commented Dec 14, 2022

When defining dependencies, they are a dictionary with the different fields expected by maven. So far, so good. The examples use the flow-style of YAML to reduce the number of lines:

https://github.com/takari/polyglot-maven/blob/master/poms/pom.yml#L37

The flow-style is not that common in YAML. Even tho officially specified (https://yaml.org/spec/1.2.2/#chapter-7-flow-style-productions), people sometimes get confused about it. An example would be #175 . It also resembles somewhat JSON without being JSON, which is even more confusing with the relation of YAML<->JSON.

This is also the reasoning why the library 'strictyaml' forbids the usage of the flow-style. (Note: Flow-style is only curly braces, the squared braces of arrays are fine). See https://hitchdev.com/strictyaml/why/flow-style-removed/

My suggestions would be:

  • Allow the node 'dependencies' to be either an array of dictionaries with the different fields as is, or with a string-field 'id' that represents the coordinates of the dependency.
  • This field is parsed by splitting it on every colon, expecting two or three elements representing the coordinates (group and artifactID, optional version)

This would allow allow specifying dependencies like this

dependencies:
  - id: "org.springframework.boot:spring-boot-starter-web"
  - id: "org.mapstruct:mapstruct:1.4.2.Final"

which is not only cleaner and without the flow-style, but also has some resemblance to Gradle.
Things like scope would still need an extra line.

Some open questions are what happens if 'id' and the original fields are defined, but I think we could just choose one default behavior and document it.

Alternative ideas:

  • encode possible extra settings completely in the string. The 'depencencies' array would then be an array of strings. But with optional fields, this is not very intuitive to add them to the coordinates. Also, with things like excludes, there is no canonical mapping. And when the array just has strings, then all elements would have to be strings. I do not think this is doable cleanly.

Would you be open for such a feature? I might even give it a shot to implement it myself if you believe it could be of interest but have no time yourself. :)

@dragetd
Copy link
Author

dragetd commented Oct 19, 2024

We might copy how ampere does it: https://github.com/JetBrains/amper/blob/release/0.4/docs/Documentation.md#dependencies

For example:

dependencies:
  - org.jetbrains.kotlin:kotlin-serialization:1.8.0
  - io.ktor:ktor-client-core:2.2.0

or

dependencies:
  - io.ktor:ktor-client-core:2.2.0:
      scope: compile-only 
  - ../ui/utils:
      scope: runtime-only 

We should also not use the existing fields (e.g. artifactId) - this way we could always distinguish and allow both syntax, not breaking the previous versions and just printing a warning to gradually sunset/deprecate the old syntax. Of curse, mixing the new and old fields should throw an error.

If I implemented this, would this be something worth considering merging?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant