Add `YAMLGenerator.Feature.INDENT_ARRAYS_WITH_INDICATOR` to indent by 2 spaces

[jn-asseco]

Using a simple piece of code like below - the indentation of the array is only 1 space..

g.writeArrayFieldStart( "schemes" );
g.writeString( url.getProtocol().toLowerCase() );
g.writeEndArray();

Output is as such (bad formatting here - but only 1 space before the dash!):
schemes:
- http

Using 2.10.2 versions in my pom.xml

<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-yaml</artifactId>
<version>2.10.2</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.10.2</version>
</dependency>

YAMLGenerator created as such (tried different combos):

YAMLGenerator g =
new YAMLFactoryBuilder( new YAMLFactory() ).
configure( Feature.LITERAL_BLOCK_STYLE, true ).
configure( Feature.WRITE_DOC_START_MARKER, true ).
configure( Feature.INDENT_ARRAYS, true ).
build().createGenerator( new PrintWriter( bo ) );
g.disable(Feature.MINIMIZE_QUOTES);

[cowtowncoder]

Ok so what is the specific problem? Is there functional problem (can not read resulting data back), or visual preference (would prefer output to look different)?
And in latter case, what would be the preferred style?

[jawshooah]

Hi @cowtowncoder, I also found this behavior surprising and undesirable. I don't believe this causes any problems with correctness, it's just a style preference.

For example, say we have the following yaml:

foo:
  bar:
  - 1
  baz:
  - blargh:
      a: 1

With the current behavior of INDENT_ARRAYS, this would be reformatted as:

foo:
  bar:
   - 1
  baz:
   -
    blargh:
      a: 1

The desired behavior would be:

foo:
  bar:
    - 1
  baz:
    - blargh:
        a: 1

[cowtowncoder]

Ok that makes sense; I just want to make sure I understand the request: nothing wrong in preferences for output per se.
At this point I am open to contributions that allow defining different defaults, using SnakeYAML configuration.

[dswiecki]

@cowtowncoder please check if #227 suits you

[cowtowncoder]

@dswiecki Thanks! Added one note on PR. One other thing: have I already asked for a CLA? If not, I'd need it (but just once, for the first contribution):

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

and the easiest way is usually to print the doc, fill & sign, scan/photo, email to info at fasterxml dot com.
After that we can accept any and all code contributions to all Jackson repositories.
Apologies for the hassle but this is the only piece of process we need.

[cowtowncoder]

Hoping to get this still in 2.12, just waiting for CLA. There is still time, earliest possible release date would be early November.

[IsmailMarmoush]

@cowtowncoder just bumped into this issue on my code too, 👍

But saw the CLA blocker :( what if the contributor doesn't want to (how can we unblock this) ?

Plus, the CLA also requires personal information that many people might feel intrusive, especially when they are the ones "contributing".

Maybe if there's some sort of automated disclaimer (first comment/description) for any new PRs submitted saying something like "By submitting your PR you hereby grant us bla bla bla"

This was just my common sense, and I might be wrong, I just saw this as an unnecessary formality we all could benefit from dropping if that was possible.

[dswiecki]

Sory for my delay, I'll try provide CLA and update PR today

[cowtowncoder]

@IsmailMarmoush I do not ask for CLA because I find it personally useful but because it makes my life as maintainer easier -- it is something that has saved me from having to interact much with corporate lawyers. Bigger corporations are wary of OSS projects that do not require contribution attributions; I get contacts about this couple of times per year.
So while it may seem tempting to just do something kind of EULA equivalent, I don't have time or interest to argue that it would be just as good as CLAs, when next paralegal from IBM contacts me. :-)

But fortunately, so far getting CLA has rarely been even temporary blocker.

@dswiecki Thank you!