hansva opened a new pull request, #8554:
URL: https://github.com/apache/hop/pull/8554

   
   ## Consistent kebab-case metadata folder names, fixes #5597
   
   Some metadata types used PascalCase or run-together keys 
(`MailServerConnection`, `S3ConnectionDefinition`, `restconnection`, …). The 
key is also the name of the folder the objects are stored in, so project 
`metadata/` folders were inconsistent. The key is also the plugin ID, the key 
in serialized metadata exports and the ID used in `disabledGuiElements`, so 
renaming it alone would make existing objects disappear.
   
   ### What changed
   
   **New: `@HopMetadata(legacyKeys = {...})`**
   - Objects in a folder named after a legacy key are still listed and loaded. 
If an object exists in both folders, the one in the current folder wins.
   - Saving an object always writes it to the current folder and removes the 
legacy copy, so projects move over one object at a time as they are edited.
   - Deleting removes every copy.
   - Legacy keys are also accepted by `getMetadataClassForKey` (metadata 
exports from older clients), by `disabledGuiElements` and by the Metadata Input 
type filter.
   
   **Renamed keys** (each keeps the old key in `legacyKeys`)
   
   | Old | New |
   |---|---|
   | `MailServerConnection` | `mail-server-connection` |
   | `S3ConnectionDefinition` | `s3-connection` |
   | `AzureConnectionDefinition` | `azure-connection` |
   | `GoogleStorageConnectionDefinition` | `google-storage-connection` |
   | `MinioConnectionDefinition` | `minio-connection` |
   | `HdfsConnectionDefinition` | `hdfs-connection` |
   | `WebDavConnectionDefinition` | `webdav-connection` |
   | `DatabricksVfsConnectionDefinition` | `databricks-vfs-connection` |
   | `DatabricksConnection` | `databricks-connection` |
   | `SparkCatalog` | `spark-catalog` |
   | `restconnection` | `rest-connection` |
   | `gitconnection` | `git-connection` |
   | `salesforceconnection` | `salesforce-connection` |
   
   `rdbms` is unchanged.
   
   **Core**
   - `JsonMetadataSerializer` reads from the current folder and the legacy 
folders and saves to the current folder. New `findFilename()` returns where an 
object actually lives.
   - New helpers `HopMetadataUtil.getAllKeys()` and `matchesKey()`.
   - If a key only changed case, it is the same folder on a case-insensitive 
file system, so saving skips removing the "legacy" copy there.
   
   **UI and plugins**
   - Metadata perspective: legacy folders no longer show up as unknown types, 
"open file" finds objects in legacy folders, and saved virtual folders are 
rewritten to the new key.
   - Search results, the lint plugin and the Metadata Input filter are 
legacy-aware.
   - The REST and Git sample folders moved to the new names, and the user 
manual links to them were updated.
   - The integration-test projects deliberately keep the old folder names, so 
they check that old projects still load.
   
   **Docs**
   - `AGENTS.md`: new "Metadata type keys" rule. Keys are kebab-case, a rename 
requires `legacyKeys`, and code that works with type keys or metadata files 
must use the helpers.
   - Developer manual (`metadata-plugins.adoc`): new "Choosing a key" and 
"Renaming a key" sections.
   
   ### Testing
   - New unit tests cover mixed folders, parent and child projects, rename, 
duplicate, delete, types renamed twice or only in case, metadata export round 
trips and the lint loader.
   - The core, engine and UI suites are green.
   - End-to-end run on a client build, for all 13 types: the real plugin 
registry, real old JSON files from the integration tests, and a `hop-run` 
Metadata Input pipeline on a half-migrated parent and child project.
   - Not automated: the metadata perspective's GUI-only paths. A quick manual 
check is recommended.
   
   ### Release note
   Metadata objects of the renamed types move to the new folder when they are 
saved. Older Hop versions don't see objects once they have moved. An older Hop 
server that receives metadata from a newer client silently skips the renamed 
types.
   
   ------------------------
   
   Thank you for your contribution! Follow this checklist to help us 
incorporate your contribution quickly and easily:
   - [ ] Run `mvn clean install apache-rat:check` to make sure basic checks 
pass. A more thorough check will be performed on your pull request 
automatically.
   - [ ] If you have a group of commits related to the same change, please 
squash your commits into one and force push your branch using `git rebase -i`.
   - [ ] Mention the appropriate issue in your description (for example: 
`addresses #123`), if applicable.
   
   To make clear that you license your contribution under the [Apache License 
Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
   - [ ] I hereby declare this contribution to be licensed under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   - [ ] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to