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]