-
Notifications
You must be signed in to change notification settings - Fork 103
Description
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. :)