This class is currently a melting pot of

Generic path-related methods - which can be useful both in a filesystem- and jcr- context:

• isAbsolute()
• getAbsolutePath()

Filesystem-related, Magnolia-specific methods

• Unused methods (or methods that should not be used) - getCacheDirectoryPath()
  • These should just go
• Methods that provide a java.io.File for some of the default properties (getTempDirectory(), getCacheDirectory(), and getHistoryFile().
  • of these 3, only the first is relevant to all modules. The other 2 are actually module specific.
  • none of these actually makes sure the directory is actually created. They attempt to create the directory structure on every call, but never check for results.
• getRepositoriesConfigFile() which is also not used. (the corresponding property is used directly)
• getAppRootDir() which is used 3 times, in 3 different ways:
  • once to generate an "appName" in MBeanUtil (which is a very flawed way of uniquely identifying a Magnolia instance)
  • once to get to the web.xml file - which will way if the app is deployed as an unexpanded .war file
  • once to load config files (will probably also fail if the app is deployed as an unexpanded .war file, but info.magnolia.cms.util.ConfigUtil#getConfigFile already works around that, I think)
• getAbsoluteFileSystemPath, which is used in the combination with the above - but not always (ConfigUtil.getConfigFile for example replicates this logic to find configuration files)

JCR, generic utility methods:

• getUniqueLabel()
  • should be named getUniqueNodeName()
• getValidatedLabel() which transforms an arbitrary String into a valid jcr name.
  • should be named validateNodeName()
  • isCharValid(), which should be private

Proposals:

• For all filesystem-only methods - move whatever is module-specific to the module in question. Keep the minimum in core, make magnolia.home a first-class citizen property and provide:
  • a clear way of making sure the required paths are valid, exist and can be read from/written to.
  • MagnoliaDirectories could provide "home" (where all files reside) "app root dir" (renamed to webappDir), although usages of the latter should be kept to a minimum and one should probably prefer using javax.servlet.ServletContext#getResource
  • I would consider using a Virtual FS - if all client code is moved to using this new interface, it'd become possible to remove all FS usage, should that be desired. (Jackrabbit has one, and I was hoping to find it in jcr-commons, but that doesn't seem to be the case. Apache commons has a VFS library too, but it seems a little outdated.) - would also help with tests. It looks like Java 7 has something along these lines, so perhaps we could wait until we switch to Java 7 (unless there is a way to get this in a non-intrusive way)

• For all JCR-related methods - move to NodeUtil ?

• For the 3 methods that aren't specific to fs or JCR, meh. They're simple enough, I wouldn't mind the duplication - but they probably don't need to be public either.