[ http://jira.codehaus.org/browse/MNG-2602?page=comments#action_77335 ] James Carpenter commented on MNG-2602: --------------------------------------
This bug is most annoying if you have a report registered which requires the outputDirectory not to be messed up. For example my newer NDOC plugin gets mad because of this bug. In projects which don't use the ndoc report plugin, the problem goes unnoticed. This is not to say it doesn't always exist, it just doesn't always show its ugly head. > maven-csharp-source-plugin:process-classes messes up outputDirectory and > thereby indirectly messes up release plugin > -------------------------------------------------------------------------------------------------------------------- > > Key: MNG-2602 > URL: http://jira.codehaus.org/browse/MNG-2602 > Project: Maven 2 > Issue Type: Bug > Components: Sandbox > Environment: Windows XP > Reporter: James Carpenter > Priority: Critical > > Within the csharp plugins > org.apache.maven.plugins:maven-csharp-source-plugin:process-classes is > registered at the process-classes phase. Within this plugin the execute > method resets the output directory to be that of the actual artifact > (target/dotnet-assembly/somelib.dll) rather than the directory which it was > set to (target/dotnet-assembly). > The short javadoc within > org.apache.maven.plugin.csharp.source.ProcessClassesMojo says: > ----------- > This Mojo adds the result of the compile to the classpath elements > This is required by the NUnitMojo. > ------------ > As it turns out this has very negative side affects. If one tries to run > multiple goals at once (mvn deploy site-deploy), the first goal is very > likely to mess up the effective pom for the following goal. This is what > happens to the release plugin. During release:perform the release plugin > uses the plexus command line tools to run "mvn --no-plugin-updates > --variousOtherFlags deploy site-deploy" within target/checkout. As you might > imagine this really messes things up, such that the site-deploy fails as it > tries to find target/checkout/target/dotnet-assembly/somelib.dll/somelib.dll. > In summary a better way to keep the NUnit plugin happy must be found, as the > current solution is very problematic. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
