# Generated Model metadata for discovery and authoring

Applications can now opt into the separate `designer-model-processor` annotation processor. It emits versioned Model property descriptions during compilation, without loading or executing application classes. Both hosts consume those descriptions through the same isolated target discovery worker. The shared browser identifies **Generated Model metadata 1.0** or **Compiled Model signatures** in its provenance. Direct bindings, nested paths, Repeat collections and Table discovery use the same resulting Attribute description.

## Application setup

Configure the application module's Maven compiler plugin (3.14.1 in the qualified fixtures):

```xml
<configuration>
  <annotationProcessorPaths>
    <path>
      <groupId>de.neitzel.fxdesigner</groupId>
      <artifactId>designer-model-processor</artifactId>
      <version>0.1.0-SNAPSHOT</version>
    </path>
  </annotationProcessorPaths>
  <compilerArgs>
    <arg>-Adesigner.models=com.example.Person,com.example.Address</arg>
  </compilerArgs>
</configuration>
```

Keep the selection in the checked-in POM. Merge this configuration with any existing annotation processor paths and compiler arguments. No Model annotation, runtime dependency, FXML rewrite, or host-specific configuration is needed. The explicit FXML `neitzel-model` processing instruction remains authoritative for each View. A missing selected type fails compilation. An empty selection generates nothing. Only Models belonging to the current compilation source set are emitted; test compilations and dependent modules do not duplicate resources for already compiled Models.

The processor emits public read/write JavaBean signatures for selected types and nested bean types, with inherited members, boolean `is` precedence and declared collection element types. Read-only properties and the runtime's reserved `latestMessage` are excluded from the generated property list. Target discovery supplies built-in properties and applies the existing simple/complex/collection rules, path depth/cycle limits, ViewModel selection and direction-aware compatibility. Metadata does not initialize Models, call accessors, construct Controllers, or run custom BeanInfo.

## Format and integrity

Each Model has one UTF-8 resource at `META-INF/neitzel-fx-designer/models/<binary-class-name>.properties` in the class output and packaged application JAR. Schema `1.0` contains the Model identity and an ordered list of names, binary value types, declared collection element types, readers and writers. Output is deterministic and contains no timestamp or machine paths. The shared `ModelMetadata` contract bounds input size to 256 KiB and property count to 256; unknown versions and invalid structures are rejected.

Target discovery prefers generated descriptions and verifies the complete eligible property inventory and signatures against the captured compiled type. This integrity check uses non-initializing reflection, not application execution. No claim of reflection-free discovery or improved performance is made. Absent metadata uses the existing compiled-signature fallback. Present but malformed, duplicate, incompatible or stale metadata is an error, with no silent fallback; normal invalid-draft saving remains available and existing validation gates block new previews. Custom BeanInfo semantics remain unverified and are not silently replaced by generated ordinary-bean signatures. Unsupported generic signatures remain subject to conservative validation rather than guessed types.

Build and Refresh already performs `clean package` in an isolated reactor copy. It captures generated resources with the same immutable outputs and dependency identities used for preview. Changed Models or selection settings invalidate the build input identity. Clean rebuilds remove obsolete properties and deselected metadata; callers building outside the designer must also use a clean build after removals or selection changes. Arbitrary incremental javac output cleanup is not implemented. A failed build cannot activate partial metadata, and explicit last-successful-build use keeps its earlier metadata and outdated label.

## Boundaries and validation

This is build-time Model metadata for existing discovery and binding authoring. The subsequent [ViewModel generation slice](generated-viewmodels.md) now generates Java subclasses and registry defaults. Editable FXML forms, labels/control defaults, arbitrary BeanInfo metadata, Java source origins and a project-wide Model selection UI remain later work. Those retain their later roadmap gates. The processor is a Java 21 build artifact depending only on the contracts; it is not packaged in either host or required on the application runtime path. Wire DTOs and protocol versions do not change.

Automated tests compile real source with the processor, verify deterministic inherited/collection signatures and non-execution, clean-build removal, missing selections, schema bounds, generated/fallback equivalence, stale signatures and duplicate resources. Real classpath and module-path fixture processes require generated Person and nested Address metadata and retain their non-initialization assertions. The live shared-host scenario requires generated metadata provenance before handing discovery to the binding inspector, then runs existing source-preserving binding authoring and Undo/Redo tests in standalone and registered IntelliJ. No manual testing is requested; earlier skipped manual checks remain skipped.

Run the bootstrap and registered IntelliJ qualification commands in the [README](../README.md).

### Qualification — 2026-11-13

The clean shared build passes 135 Maven tests and ten IntelliJ adapter tests. The real Java 21 fixtures pass 36 target processes with 518 checks, including generated Person/Address resource use in both launch modes and non-initialization assertions. Native standalone classpath and module-path scenarios pass generated discovery, existing Direct/Computed/Repeat/Table authoring, source-preserving edits and Undo/Redo. The lifecycle suite retains its 48-cycle and abrupt-owner-death checks.

The first fixture integration exposed duplicate resources from Maven test compilation inheriting the processor configuration. Restricting emission to the current compilation's source types fixed this; a dependent-compilation regression now verifies that compiled Models are not emitted twice. Generated output remains part of the normal immutable snapshot and packaged module resources.

The full bootstrap passed, including Java 21 bytecode/linkage, plugin packaging exclusions and documentation checks. Registered IntelliJ classpath qualification also passed generated discovery, source-preserving authoring, native diagnostics/Undo/Redo, exclusive JavaFX 26 natives and worker shutdown. The first registered module-path attempt passed generated discovery but timed out at the existing Table preview-gating assertion; it is retained as reliability evidence. An unchanged module-path-only rerun of the registered qualification harness passed all assertions, exclusive JavaFX 26 native checks and worker shutdown (`/tmp/model-metadata-ide-modulepath-retry.log`). The startup/persistence/preview-gate reliability follow-up remains open; no assertion was weakened. No manual testing was used.

Local evidence: `/tmp/model-metadata-bootstrap2.log`, `/tmp/model-metadata-registered-ide.log`, `designer-target-tools/target/preview-fixtures/`, `target/connected-workflow/` and `target/ide-workflow/`. Earlier development evidence is retained in `/tmp/model-metadata-build.log`, `/tmp/model-metadata-build2.log` and `/tmp/model-metadata-bootstrap.log`. Generated qualification artifacts are not repository inputs.