Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
None
-
None
-
None
-
Maven 2.0.7, JDK 1.5.0_12, WinXP, maven-testing-harness:1.1
-
Patch
Description
For example, calling MavenProjectStub.addCompileSourceRoot() twice causes the following stack trace
java.lang.UnsupportedOperationException at java.util.AbstractList.add(AbstractList.java:151) at java.util.AbstractList.add(AbstractList.java:89) at org.apache.maven.plugin.testing.stubs.MavenProjectStub.addCompileSourceRoot(MavenProjectStub.java:328)
This is caused by the usage of Collections.singletonList() in various methods to initialize modifiable collection members. However, singletonList() returns an immutable collection as stated in its javadoc.
The attached patch should fix this. Besides, the patch uses eager initialization for the collections such that getters like getCompileSourceRoots() return non-null data right from the beginning. This makes the stub more consistent with the behavior of MavenProject.
Apropos MavenProject: I wonder why many (if not all) methods inherited from MavenProject are overriden by MavenProjectStub. For instance, MavenProject.addCompileSourceRoot() already provides (non-trivial) management of the source root collection. The stub in turn badly overwrites this, making the tests behave differently than during a real build while apparently not providing any more features to the unit tests. Likewise I cannot quite understand why methods like getDependencies() are overwritten with noops while the MavenProject's implementation nicely delegates to the model.