|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Henning Schmiedehausen - 07/Jan/07 07:17 AM
That patch is better. Also contains the new classes.
I tried your latest patch and actual tests failed. Could you provide us test cases or review these? Tx.
Another way, as you know, we change license headers. I forgot to say that I tried with maven 2.0.4 and 2.0.5
Yep, same here. Maven 2.0.4 and 2.0.5-SNAPSHOT (do we have a release yet?).
Which platform did you use? I ran my tests on Linux, I don't have a built HEAD on Windows and the process of getting the jumble of maven, plexus, doxia and everything else to get built took my fastest machines two hours. I don't want to think how long my old windows notebook would take for this... If you are on Windows, I will try to run the tests for you this weekend. Can you attach the failed test report? That would help me tremendously. Here is the surefire report.
I am on windows with 2.0.4 and 2.0.6-snapshot (trunk) I tried with your latest patch: http://jira.codehaus.org/secure/attachment/25052/doxia-decoration.patch 
HTH Hm, that is a forward-slash / backward-slash issue. Will look into that.
This version of the path passes all tests for me on Linux and Windows.
I got a NPE in a multi project case without any documentation.
java.lang.NullPointerException
at java.io.File.<init>(File.java:194)
at org.apache.maven.doxia.site.decoration.inheritance.PathUtils.getRelativeFilePath(PathUtils.java:130)
at org.apache.maven.doxia.site.decoration.inheritance.PathUtils.getRelativePath(PathUtils.java:103)
at org.apache.maven.doxia.site.decoration.inheritance.PathUtils.convertPath(PathUtils.java:40)
at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.convertPath(DefaultDecorationModelInheritanceAssembler.java:338)
at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.resolveBannerPaths(DefaultDecorationModelInheritanceAssembler.java:150)
at org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.resolvePaths(DefaultDecorationModelInheritanceAssembler.java:97)
at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:555)
...
Unschedule until the patch works without error, I tried it too and it breaks.
Ok, you got me confused. This is only possible when a PathDescriptor contains null for both the PathUrl and the relativePath. Which can only happen when the PathDescriptor has been constructed using a 'null' path. And the only place where this is possible is in PathUtils line 47 and there is an explicit null test in front of it.
Can you give some pointers on what project exactly you tried to build the sites for? Or is that some non-public site? If possible, could you put a breakpoint at PathUtils::getRelativePath(String, String) and tell me what exactly goes in there. I'd guess that oldPath is null. I'll add another patch shortly which has another minor fix and I will add some explicit testing on that. Also some unit tests. Updated version for the doxia decoration patch. This should now avoid all possible NPE problems even with complex builds. Also adds some unit tests for the code.
This patch also adds a number of unit tests. Unfortunately as I can not modify the issue, I can not change the "contains unit tests" field.
the unit tests in the last patch actually depended on the existence of a "/tmp/foo" directory (they might report a trailing slash). This is an updated version where the unit tests pass in all cases. Still need to test on Windows, though.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
Update Doxia Decoration model to actually work in reactor build.
