On 11/15/2010 04:45 AM, nicolas de loof wrote:
AFAIK most code (including some
plugins) related to POM parsing use Xpp3Reader, as we don't provide an
abstraction API for POM parsing.
Along the same lines, http://jira.codehaus.org/browse/MNG-4862 shows that org.apache.maven.model.ConfigurationContainer assumes that unspecified XML trees are represented
as Xpp3Dom, so any code which e.g. reads/writes a plugin's <configuration> must cast to Xpp3Dom and use this interface. I doubt it would be straightforward to introduce a
compatibility layer now, other than a supertype in the Maven namespace with a similar signature as Xpp3Dom, which would not really simplify usage.
On a tangent, I agree with Lennart's complaints about the quality of the interfaces generated by Modello, but at least I can refer back to the schema for explanation; the
hand-written interfaces in Maven are just as bad as regards null safety, bean "pattern" abuse, and Javadoc, but in a less predictable way. My experiences embedding Maven
3 in an IDE go something like this:
1. Look around the class index for something that sounds vaguely like what you need. If there is a ProjectLifecycleArtifactDependencyResolver interface and a
DependencyArtifactProjectScopeResolver and a LifecycleScopeArtifactDependencyClassifier etc. etc. then just pick one. Any Javadoc would anyway be of the form "This is an
artifact dependency resolver for the project lifecycle", which doesn't tell you anything about who uses it, when, or why. If it's @Deprecated, perhaps it came from Maven
2; pick another one randomly, since the Javadoc never says what the intended replacement is.
2. Check source code backreferences to see if the interface you picked is ever
actually called. If not, return to step 1.
3. Hope that there is an instance of the interface somewhere in the Plexus container. (And that no special role hint is needed, since these are unlikely to be documented
anyway.) Check class index for DefaultEtcEtc, and read source code to see if it sounds like it is doing something you wanted.
4. Grab an instance and try calling some method on it. Usually there will be
five overloads so just pick the one with the shortest argument list.
5. Take the first NullPointerException you encounter and inspect the code mentioned in the stack frames. Use a process of logical inference to determine what field of
what class was expected to be non-null. This is sometimes complicated by the presence of several different SomethingRequest interfaces being passed around and
interconverted, each of which has its own (undocumented) assumptions about nullity of certain parameters - and conversion is always of the form
newRequest.setFrobnitz(oldRequest.getFrobnitz()) with no intermediate sanity check.
6. Call the setter corresponding to the null field in #5 and return to step 4
until something happens.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
