[ 
http://jira.codehaus.org/browse/MNG-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason van Zyl closed MNG-2602.
------------------------------

    Resolution: Won't Fix

This is not one of our plugins. Request to move it, as it looks more like an 
NMaven issue to me.

> 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
>             Fix For: Reviewed Pending Version Assignment
>
>
> 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

        

Reply via email to