Is this function for linting? If so, a few questions (again mostly for me to learn):

1. Is there no go linting tool that adds a newline automatically, if that's what we're trying to account for?
2. Is there a go library that adds a newline?

1. No, this function is used to append new entries to versions.txt file. versions.txt exists in google-cloud-java, and although not encouraged, can be edited by human and I believe does not have a check for trailing empty line.
2. I am not aware of. I think we need to read in the file and write.

what about simplifying this function to this:

  func AppendLines(path string, lines []string) error {
        if len(lines) == 0 {
                return nil
        }
        existing, err := os.ReadFile(path)
        if err != nil {
                return err
        }

        var buf bytes.Buffer
        buf.Write(existing)
        if len(existing) > 0 && existing[len(existing)-1] != '\n' {
                buf.WriteByte('\n')
        }
        for _, line := range lines {
                buf.WriteString(line)
                buf.WriteByte('\n')
        }
        return os.WriteFile(path, buf.Bytes(), 0644)
  }

This will rewrite the whole file each time, but for a small file like versions.txt it seems cleaner

What I don't quite understand is what we need to append the newline at all though?

why we need to append the newline at all though?

It's more of a safety check. Although not encouraged, this versions.txt can be edited by human and I believe there is no check for trailing empty line in google-cloud-java. Alternatively, we can add a dedicated workflow in google-cloud-java to check for it. But I think it's easier to check when attempting to update.

what if a library has no versions to parse?

A Java library should always have version. librarian add sets a default version

we should try to keep the same API interface across languages for Generate. what about moving the post generate logic inside java.Generate?

I see we will stop adding multiple lines into version txt for proto- and grpc- artifacts #4650.

Nope. #4650 is to unify the versions. No changes to versions.txt structure. We can potentially do that, but it does not change that we still need append to versions.txt when new library onboards.

Can you define the canonical way within Java to detect a library is new or not?

(I believe that the responsibility of detecting the condition is not in Generate function.)

@julieqiu your comment https://github.com/googleapis/librarian/pull/5660/changes#r3156502889 is related, I'll bring this discussion together:

• Currently, Generate does post processing steps that generates pom.xml files when it is a new library (that is where new library/module is detected and bubbled up).
• I choose to change Generate to return these version entries and let java.PostGenerate write to versions.txt, because versions.txt is located at repo root, and it's natural to update it once for the whole generation. It should be technically possible to move inside java.Generate and workout the parent dir of outdir, but it feels a bit wrong as a per library function updates a repo level file, and may be problematic if we seek to do parallel in the future.
• By the time it gets to java.PostGenerate, pom.xml are already added, I don't see a way to identify which library is new. @suztomo any ideas you have in mind?