Issue: It's hard to tell what namespaces are used in Matterhorn and its hard to tell when they change.
For example, the namespace "http://org.opencastproject.security" is defined 18 times in 9 classes across 2 bundles.
In this case, when that namespace changed from "org.opencastproject.security" to "http://org.opencastproject.security" between 1.4rc2 and 1.4rc7, the series REST API changed.
A possible solution for more namespace visibility is move the namespace definitions out of java and into configuration files.
Karen, I'm not sure how much work this would be, but can you bring this up on list please? CFRs tend to get missed in the general hubbub around JIRA and this strikes me as a really good suggestion to bring up to the committer body.
Generally namespaces are well-known identifiers or literal entities that are not subject to configuration. Hence I think this is more of a documentation issue. I strongly agree that the used namespaces should be documented more prominently but not in the form of config file. I'd rather propose to add a "mh-namespaces.txt" documentation file to docs/.
Another point is that namespaces are not only used inside Matterhorn but also in communication with the outside world. A client of one of MH's XML structures cannot rely on a config. It just has to know. As namespaces are part of MH's communication protocols they have to be as stable as possible. Putting them in a config evokes that they can be configured which is not quite true.
I agree on the hazard of putting namespace identifiers into a configuration file. I should have called it a Properties file surrounded with big warnings not to touch the values. The benefit of the code using values from a single accessible source is that it's more truthful than a disconnected text document. It is easier to see if there is a disconnect between a namespace used in Matterhorn and one used by the outside world. A less dangerous alternative is to put common namespace constants into a single configuration class, referenced by the code, that can be exported as javadoc and viewed on one page.
+1 for the constants class. Defining constants for well-known identifiers is a good practice and it does not look like a configuration. We can place it in matterhorn-commons and name it MatterhornNamespaces.