You are viewing a plain text version of this content. The canonical link for it is here.
Posted to npanday-commits@incubator.apache.org by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org> on 2011/11/21 16:30:52 UTC

[jira] [Updated] (NPANDAY-486) Implement integrated XBuild/MSBuild lifecycle (superseeds current MSBuild integration)

     [ https://issues.apache.org/jira/browse/NPANDAY-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lars Corneliussen updated NPANDAY-486:
--------------------------------------

    Description: 
The current MSBuild integration is a hack. It was initially implemented as a dotnet-maven-plugin, but now also the Java binding has been forked from the originally generated source.

h2. How it works now
In order to "activate" MSBuild, the plugin {{{NPanday.Plugin.Msbuild.JavaBinding}}} must be configured:

{code}
<plugin>
<groupId>org.apache.npanday.plugins</groupId>
<artifactId>NPanday.Plugin.Msbuild.JavaBinding</artifactId>
  <executions>
    <execution>
      <goals>
        <goal>compile</goal>
      </goals>
    </execution>
  </executions>
</plugin>
{code}

Also currently, code generated by MSBuild seems to have to be included manually!
{code:title=from NPANDAY_328_VS2010WpfProjectSupportTest}
...
<includeSource>obj\x86\Debug\App.g.cs</includeSource>
...
{code}


It registers MsbuildMojo.java to the validate-phase, which performs these steps: 

* preExecute: If {{{copyDependencies}}} is {{{true}}} (is true by default), it will copy all dependencies of the current project to (!) {{{basedir/bin/Debug}}}
* preExecute: Then it adds all *.resource-files from (!) {{{obj/Debug}}} to project resources (using {{{project.addResource}}}
** (?) How can it even know theese, before having executed msbuild? Looks like this won't have any effect, before the second build runs.
* Execute: Calls into {{{MsbuildMojo.cs}}}
** Searches for {{{projectName.csproj/vbproj}}}
** Runs with: {{{/v:q /p:BuildProjectReferences=false /p:BuildingInsideVisualStudio=true}}}

h2. How it should work

This is still to be figured out. Let's collect some requirements:

h3. Functional Requirements (high-level)
* It must be possible to compile WPF-projects (with Xaml-files)
* any more?

h3. Conditions / Design Decisions
* The Maven principle of reproducible builds must be met.
* Dependencies from pom must override those specified in the build file
* Correct versions of dependencies must be ensured
* Project-references must be resolved inside the reactor, if possible.
* Generated code or resource must automatically be added to the POM (in-memory?)
* Msbuild targets should run in appropriate maven phase (not in validate!)
* Msbuild error-handling must

  was:
The current MSBuild integration is a hack. It was initially implemented as a dotnet-maven-plugin, but now also the Java binding has been forked from the originally generated source.

h2. How it works now
In order to "activate" MSBuild, the plugin {{{NPanday.Plugin.Msbuild.JavaBinding}}} must be configured:

{code}
<plugin>
<groupId>org.apache.npanday.plugins</groupId>
<artifactId>NPanday.Plugin.Msbuild.JavaBinding</artifactId>
  <executions>
    <execution>
      <goals>
        <goal>compile</goal>
      </goals>
    </execution>
  </executions>
</plugin>
{code}

Also currently, code generated by MSBuild seems to have to be included manually!
{code:title=from NPANDAY_328_VS2010WpfProjectSupportTest}
...
<includeSource>obj\x86\Debug\App.g.cs</includeSource>
...
{code}


It registers MsbuildMojo.java to the validate-phase, which performs these steps: 

* preExecute: If {{{copyDependencies}}} is {{{true}}} (is true by default), it will copy all dependencies of the current project to (!) {{{basedir/bin/Debug}}}
* preExecute: Then it adds all *.resource-files from (!) {{{obj/Debug}}} to project resources (using {{{project.addResource}}}
** (?) How can it even know theese, before having executed msbuild? Looks like this won't have any effect, before the second build runs.
* Execute: Calls into {{{MsbuildMojo.cs}}}
** Searches for {{{projectName.csproj/vbproj}}}
** Runs with: {{{/v:q /p:BuildProjectReferences=false /p:BuildingInsideVisualStudio=true}}}

h2. How it should work

This is still to be figured out. Let's collect some requirements:

Functional
* It must be possible to compile WPF-projects (with Xaml-files)
* any more?

Conditions
* The Maven principle of reproducible builds must be met.
* Dependencies from pom must override those specified in the build file
* Correct versions of dependencies must be ensured
* Project-references must be resolved inside the reactor, if possible.
* Generated code or resource must automatically be added to the POM (in-memory?)
* Msbuild targets should run in appropriate maven phase (not in validate!)
* Msbuild error-handling must

    
> Implement integrated XBuild/MSBuild lifecycle (superseeds current MSBuild integration)
> --------------------------------------------------------------------------------------
>
>                 Key: NPANDAY-486
>                 URL: https://issues.apache.org/jira/browse/NPANDAY-486
>             Project: NPanday
>          Issue Type: New Feature
>          Components: Maven Plugins
>    Affects Versions: 1.4-incubating
>         Environment: Windows/.NET: MSBuild; Mono: Xbuild
>            Reporter: Lars Corneliussen
>            Assignee: Lars Corneliussen
>
> The current MSBuild integration is a hack. It was initially implemented as a dotnet-maven-plugin, but now also the Java binding has been forked from the originally generated source.
> h2. How it works now
> In order to "activate" MSBuild, the plugin {{{NPanday.Plugin.Msbuild.JavaBinding}}} must be configured:
> {code}
> <plugin>
> <groupId>org.apache.npanday.plugins</groupId>
> <artifactId>NPanday.Plugin.Msbuild.JavaBinding</artifactId>
>   <executions>
>     <execution>
>       <goals>
>         <goal>compile</goal>
>       </goals>
>     </execution>
>   </executions>
> </plugin>
> {code}
> Also currently, code generated by MSBuild seems to have to be included manually!
> {code:title=from NPANDAY_328_VS2010WpfProjectSupportTest}
> ...
> <includeSource>obj\x86\Debug\App.g.cs</includeSource>
> ...
> {code}
> It registers MsbuildMojo.java to the validate-phase, which performs these steps: 
> * preExecute: If {{{copyDependencies}}} is {{{true}}} (is true by default), it will copy all dependencies of the current project to (!) {{{basedir/bin/Debug}}}
> * preExecute: Then it adds all *.resource-files from (!) {{{obj/Debug}}} to project resources (using {{{project.addResource}}}
> ** (?) How can it even know theese, before having executed msbuild? Looks like this won't have any effect, before the second build runs.
> * Execute: Calls into {{{MsbuildMojo.cs}}}
> ** Searches for {{{projectName.csproj/vbproj}}}
> ** Runs with: {{{/v:q /p:BuildProjectReferences=false /p:BuildingInsideVisualStudio=true}}}
> h2. How it should work
> This is still to be figured out. Let's collect some requirements:
> h3. Functional Requirements (high-level)
> * It must be possible to compile WPF-projects (with Xaml-files)
> * any more?
> h3. Conditions / Design Decisions
> * The Maven principle of reproducible builds must be met.
> * Dependencies from pom must override those specified in the build file
> * Correct versions of dependencies must be ensured
> * Project-references must be resolved inside the reactor, if possible.
> * Generated code or resource must automatically be added to the POM (in-memory?)
> * Msbuild targets should run in appropriate maven phase (not in validate!)
> * Msbuild error-handling must

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira