You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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. :)
The text was updated successfully, but these errors were encountered:
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?
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:
This would allow allow specifying dependencies like this
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:
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. :)
The text was updated successfully, but these errors were encountered: