fskorgen opened a new issue, #8225:
URL: https://github.com/apache/hop/issues/8225
### Apache Hop version?
2.19
### Java version?
21
### Operating system
Windows
### What happened?
New in 2.19: the Unknown category, `MetadataCategories` and
`collectOrphanMetadataFolders` do not
exist in 2.18, so no earlier version shows this.
---
The metadata perspective scans the project's metadata folder for type
folders no installed plugin
claims, and lists each one under the **Unknown** category so its elements
can be inspected and
deleted. The type node is created before the folder is read, so a folder
that holds no elements at
all still gets a node — a warning icon and a type name with `(0)` next to
it, for something that
carries nothing to inspect and nothing to delete.
Any Hop install that once had a plugin and no longer does collects these:
the folder is created when
the type is first used, and stays behind when the plugin goes. A
distribution that ships a subset of
the plugins shows one per dropped type in **every** project.
### Where
`collectOrphanMetadataFolders`, 2.19.0:
```java
String reason =
BaseMessages.getString(PKG,
"MetadataPerspective.Unknown.NoPluginForType", key);
UnknownTypeModel unknownType =
unknownByKey.computeIfAbsent(key, k -> new UnknownTypeModel(k, k));
for (FileObject jsonFile : HopVfs.findFiles(typeFolder, "json", false)) {
```
`computeIfAbsent` runs unconditionally; the loop that would give the node
its content runs after. An
empty folder therefore yields an `UnknownTypeModel` with an empty `items`
list, and the tree renders
it.
### Why this is an oversight rather than a choice
The same class already treats an empty orphan folder as something to get rid
of rather than
something to show. `deleteEmptyOrphanFolder`, a few hundred lines up:
```java
/**
* Removes the metadata folder of a type no plugin provides once its last
element is deleted, so
* cleaning up after a missing plugin doesn't leave an empty folder behind.
...
*/
```
So deleting the last element of an unknown type removes the folder and the
node disappears — but a
folder that was already empty when the perspective opened is rendered
instead. The two paths
disagree about the same state.
### Steps to reproduce
1. In a project, create a metadata element of any type — say a Neo4j
connection — so
`metadata/neo4j-connection/` exists.
2. Delete the `.json` file from that folder outside Hop (or start a Hop
build that does not ship the
plugin), leaving the folder in place and empty.
3. Open the metadata perspective.
**Expected:** nothing under Unknown — there is no unloadable element.
**Actual:** `neo4j-connection (0)` under Unknown, with the warning icon.
An unknown type that *does* hold an element is unaffected either way, and
must stay: that is the
case the category exists for.
### Suggested fix
Read the folder first and skip it when it holds no elements, which also
avoids listing the folder
twice:
```java
List<FileObject> jsonFiles = HopVfs.findFiles(typeFolder, "json", false);
if (jsonFiles.isEmpty()) {
continue;
}
String reason = ...
UnknownTypeModel unknownType = ...
for (FileObject jsonFile : jsonFiles) {
```
An alternative is to let the scan build the model and drop empty ones before
`unknownTypeModels.addAll(unknownByKey.values())`, which would also cover an
unknown type whose only
element failed to load. The check above is the smaller change and matches
`deleteEmptyOrphanFolder`'s existing rule.
### Issue Priority
Priority: 3
### Issue Component
Component: Hop Gui
--
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]
