I’ve been working on a new application with it’s own new widgets but when I pulled a widget namespace (condition) over from a previous application the compiler started giving me an error:
RegistryItemLoader.doPreLoadChecks(RegistryItemLoader.java:154): RegistryItemLoader.LoaderException: ResourceDirectory does not contain a definition.xml file
In the old application the widgets worked fine.
In the new application the directory structure of the widgets directory looks like this:
widgets/add-dependency/widget files
widgets/au.com.aviarc.widget.condition/1.0.0/widgets/is-enabled/widget files
Legacy artifacts didn’t have namespacing, and were in the style:
Namespaceable artifacts came in in Aviarc 3, and they are in the style:
Aviarc 3 still supports legacy artifacts, but it’s in an all-or-none manner. If Aviarc 3 detects any legacy artifacts in an artifact directory, as done by seeing if there are any definition.xml files within any of the immediate child directories, it attempts to take the whole artifact directory in legacy mode.
In the directory structure you’ve provided, the add-dependency widget is a legacy widget, so Aviarc attempts to take all widgets as legacy widgets. The error is caused because it tries to read the definition.xml file in the directory au.com.aviarc.widget.condition, and there isn’t one because it isn’t a legacy widget.
The solutions to the problem are either to:
The former solution is the recommended one. The latter may be impossible if you have multiple versions of particular artifacts within the namespace, and would normally require more changes to the application.
For the former, to start off with it’s best to move the legacy artifacts into the application 1.0.0 namespace, as this is the namespace which they are implicitly granted by the engine, so anything namespace-specific surrounding them will already be pointing at it. The application 1.0.0 namespace also retains the behaviour of legacy artifacts in that artifacts in it will automatically override built-in artifacts unless the built-in versions are explicitly specified.
So you’re looking at wanting to change the directory structure to:
If the path feels like it’s getting a bit long, there are some legacy artifact subdirectories which can be moved out of the individual widgets and set alongside the namespace’s widgets directory. Some examples are src and lib directories – I’m not personally sure what the complete list is, if there even is a limit on them (it’s always possible that some artifacts will expect to find directories beneath themselves, of course, in which case they shouldn’t be moved).