I see, okay then, I'll mark it as CLOSED. Thank you for the explanation!

No, the Properties class is something sort of special. It exists as part of Java, and it's somewhat separate from its file format (even though they built serialization into the class, which wasn't a good idea—it's an old class).

Put another way, we agree that config-file-format-properties should be a separate module for the format. But for the configuration that uses Properties, I integrated it into the main configuration class because Properties is such an integral part of the Java standard library. It comes built into Java.

And what about config-properties? It seems the same thing as the XML stuff.

Ah, I see. But in this case I don't think you need to do that. The only thing using XmlConfiguration is the XML file format, and we can always refactor it in the future if we need it—but I don't think we'll need it.

The reason I created a separate config-urf submodule with UrfConfiguration is that there will be several formats (TURF, CURF, 3URF, etc) that all use an UrfConfiguration because they will parse to an URF graph. But I don't think that applies to the XML situation.

I'm saying that instead of creating three submodules:

I created only two: