Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 3.0
-
Fix Version/s: None
-
Component/s: Embedding
-
Labels:None
-
Complexity:Intermediate
-
Number of attachments :
Description
All references to ConfigurationContainer.configuration, including the get/setConfiguration methods, treat it as a org.codehaus.plexus.util.xml.Xpp3Dom instance. Yet the signature is Object, and the Javadoc does not even mention the actual type. This is confusing and error-prone.
Suggest changing the signature throughout to Xpp3Dom. If this cannot be done for reasons of binary compatibility, I would suggest: change the signature of the field; introduce a new setConfiguration(Xpp3Dom); @Deprecate setConfiguration(Object) and make it just call setConfiguration(Xpp3Dom) after casting; and update the Javadoc of getConfiguration to specify that it will always return an Xpp3Dom instance (or maybe null). (While the JVM is happy to have two no-arg methods with the same name but different return types, javac will not allow it; possible only by postprocessing bytecode.) Could also introduce new method names, e.g. get/setConfigurationDom.
It seems that the bug may ultimately be in modello-plugin-java for handling <type>DOM</type> poorly. (JavaModelloGenerator, introduced by brett, commented on by demers.)
Yes, while ultimately a stronger typed signature is desired, this shouldn't be based on Xpp3Dom but something from the Maven domain. Xpp3Dom is an implementation detail, that ideally gets properly abstracted by means of an interface.