Closed ritzow closed 1 month ago
Can you please add for which systemd path you try to create the classes for? I would like to investigate and fix this, but with about 200 possible pathes it is pointless to start.
This should be fixed now. The issue was, that the package name was removed by
.filter(l -> !l.replaceFirst("(.+)\\..+", "$1").equals(getPackageName()))
So just the classname was remaining. Because this class and the class using it are in the same package, the whole import can be skipped. Therefore removing imports without any packages should fix it.
Thank you!
Discovered when generating code for systemd dbus interfaces
The other generated class, for reference
In method
org.freedesktop.dbus.utils.generator.ClassBuilderInfo#createClassFileContent(boolean, java.util.Set<java.lang.String>)
, the call toorg.freedesktop.dbus.utils.generator.ClassBuilderInfo#getImports
returns a set that containsPresetUnitFilesWithModeChangesStruct
. Notice that it does not have it's package name. The import should beorg.freedesktop.systemd1.PresetUnitFilesWithModeChangesStruct
, which would cause the code atorg/freedesktop/dbus/utils/generator/ClassBuilderInfo.java:298
... to not filter out
PresetUnitFilesWithModeChangesStruct
despite it's actual generated class being in the same package.So it seems like the root issue is that
getImports().add(...)
(oraddAll()
) is called at some point with a class name that has it's package name removed.