Validator ergonomics for consumer repos: validate CLI exits 0 on stub, validate.py takes one file, default schema path assumes repo layout #266

Summary

Three small friction points that show up when you consume the spec from your own repository — vendoring core-spec/osi-schema.json and validation/validate.py into a repo that holds domain models — rather than working inside apache/ossie itself.

All three are on main as of today.

1. ossie validate exits 0 while printing not yet implemented

cli/cmd/validate.go:

var validateCmd = &cobra.Command{
	Use:   "validate [flags] <path> [<path>...]",
	Short: "Validate one or more OSSIE YAML or JSON files",
	Args:  cobra.MinimumNArgs(1),
	RunE:  runValidate,
}

func runValidate(cmd *cobra.Command, args []string) error {
	fmt.Fprintln(cmd.OutOrStdout(), "not yet implemented")
	return nil
}

ossie validate broken-model.yaml prints one line and exits 0. Dropped into a CI step, that is indistinguishable from a pass — the one failure mode worth avoiding in a validation command. The help text also advertises [<path>...], --strict and --output, none of which do anything yet.

Suggestion: return a non-zero error (or mark the command hidden / Deprecated) until it is wired up.

2. validation/validate.py accepts exactly one file

if len(args) > 1:
    if len(args) == 3 and args[1] == "--schema":
        schema_path = Path(args[2])
    else:
        print("Usage: python validation/validate.py <yaml_file> [--schema <schema_file>]")
        sys.exit(1)

So validate.py models/**/*.yaml fails with a usage error rather than validating the set. Any repo with more than one model ends up wrapping it in a shell loop, which loses the aggregate summary and makes "did everything pass?" a matter of collecting exit codes by hand.

Suggestion: accept N paths, validate each, print a per-file PASS/FAIL, and exit non-zero if any file failed.

3. The default schema path assumes the upstream repo layout

schema_path = Path(__file__).parent.parent / "core-spec" / "osi-schema.json"

Vendored as scripts/validate.py in a consumer repo, that resolves to <repo>/core-spec/osi-schema.json — a directory the user never created. --schema solves it, but the first-run error (Error: Schema not found: …/core-spec/osi-schema.json) points at a path nobody chose, which is a confusing place to start.

Suggestion: keep the current default, then fall back to ./schema/osi-schema.json and/or an OSSIE_SCHEMA environment variable before erroring — and mention --schema in the error message.

Context

I hit these while putting together a scaffold for consumer repositories. The workaround is a Makefile that loops per file and always passes --schema, which works fine but is the sort of thing every consumer will end up reinventing.

Happy to send a PR for any or all of these if the direction sounds right — please say which of the three you'd take, and whether the Go CLI is expected to absorb the Python validator's job eventually (that would change what's worth fixing in validate.py).