andi12 / msbuild-maven-plugin Goto Github PK

The version-info.rc file generated by the VerionInfoMojo is not removed during a clean. It should remove the file. Need to check that the current output location makes sense or whether the file should be written to the target or other output directory.

If the project is a solution we attached the artifacts as a ZIP file of the output directory. This is done in the MSBuildMojo in the 'compile' phase. We should move this to the 'package' phase in a new Mojo.

CxxTestRunnerMojo currently throws an exception if some tests fails. On a CI system such as Jenkins, this causes the build to be marked as broken, even if the compilation succeeded.

There is a Maven property 'maven.test.failure.ignore' which when set to true should prompt the runner to ignore test failures and not fail the build.

There should be an optional configuration setting to allow projects to be excluded from the sonar properties file.

This should we done using a regex setting similar to CppCheck.

Some errors generated by various tools (e.g. CxxTest) are still not captured at the appropriate in the log, as they are reported in different formats. For example:

... : Error: ... (note the camelcase)
... : ERROR: ... (uppercase)

The same goes with warnings.

It may be desirable to check the CppCheck configuration (cppcheck --check-config) and log the result for each CppCheck invocation.

Add appropriate configuration to Sonar property files in order to pick up MSBuild compiler warnings, so they can be reported into Sonar. The Sonar configuration supports sonar.cxx.compiler.reportPath to specify the compiler report path. This seems to be compatible with the MSBuild logger output.

Ideally this can be achieved by:

1. Adding appropriate command line parameters to MSBuildMojo to have MSBuild output the compilation logs into <project_root>/compiler_reports/<report_name>.log
2. Adding sonar.cxx.compiler.reportPath=compiler_reports/<report_name_pattern>.log into the Sonar configuration file

At the moment, CxxTestGenMojo generates test runners that output a test result file with the same name (cxxtest-report) regardless of the test target's name. We therefore rely on the assumption that the test are run in different directories, so that tests for a particular target do not overwrite reports generated by tests for a different target. Clearly this does not work is tests for multiple targets are run from the same folder.

We need to change CxxTestGenMojo so that it encodes the test target name into the test report file name to prevent accidental overwrites.

Some files cause issues for CppCheck and Vera and/or the project may want to exclude them from analysis because e.g. they are generated by a tool.

For projects which output a dll or lib the plugin should create a zip file containing the API headers to allow others to access functionality in the library.

At the moment we support several tools in our plugin:

• Vera++
• CppCheck
• Sonar

Each tool handles source files differently, for example, Sonar only accepts file extensions to decide which source files to analyse, CppCheck scans whole directories and Vera++ expects a list of files on the standard input.
We should have a single list of accepted extensions for source files and header files.

We can then proceed as follows:

• Use these extensions to configure Sonar.
• Use these extensions to build a common list of source and header files to be fed into CppCheck (which supports it, via standard input) and Vera++. This list could also be provided to other tools, wither via standard input or via an external file.

When VCProjectParser parses a project files for include and output folders, it ignore environment variables (for example, CXXTEST_HOME). These should instead be replaced with appropriate values retrieved from the current environment.

This will also help the Sonar configuration generation. At the moment, if some project include directories are specified by environment variables, they will not appear in the Sonar configuration, hence Sonar will erroneously report some included files as missing.

The SonarConfigGeneratorMojo does not set any project links (e.g. CI site, code repository, etc.) in the sonar-project.properties files. There are several properties to do this since Sonar 3.3, see https://jira.codehaus.org/browse/SONAR-3676. These links will be displayed on the Dashboard in the Sonar Web UI.

We should at least aim to output:
-- sonar.links.homepage
-- sonar.links.ci
-- sonar.links.issue
-- sonar.links.scm

These properties can all be read in from the POM, if they are present (note mvn sonar:sonar does this automatically, but it only works for Java projects).

Hi!

I'm trying to use this plugin, pretty neat!

It builds fine with VS.Net 2022 tools, but it fails the "install" with this error: "this project did not assign a main file to the project but it has attachments."

[INFO] <<< msbuild-maven-plugin:1.3.1:solution-package (default-solution-package) < package composantes-materielles-involve <<<

[INFO] --- msbuild-maven-plugin:1.3.1:test (default-test) composantes-materielles-involve --. Skipping test runner execution, path to CxxTest not set

[INFO] msbuild-maven-plugin:1.3.1:solution-package (default-solution-package) composantes-materielles-involve

[INFO] Parsing solution CC.Composantes with platform-x86, configuration=Release

[INFO] Solution parsing complete

[INFO] Project parsing complete [INFO] Building zip: C:\dev\workspace\composantes-materielles-involve\target\composantes-materielles-involve-5.2.0-SNAPSHOT-x86-Release.zip

[INFO] Attached artifact C:\dev\workspace\composantes-materielles-involve\target\composantes-materielles-involve-5.2.0-SNAPSHOT-x86-Release.zip

[INFO] --- msbuild-maven-plugin:1.3.1:cppcheck (default-cppcheck) @composantes-materielles-involve --- 

[INFO] Skipping static code analysis, path to CppCheck not set

[INFO] - msbuild-maven-plugin:1.3.1: vera (default-vera) composantes-materielles-involve Skipping coding style analysis, path to Vera++ home directory not set

[INFO] msbuild-maven-plugin:1.3.1:sonar (default-sonar) composantes-materielles-involve

[INFO] Skipping Sonar analysis, 'skip' set to true in the Sonar configuration.

 [INFO] maven-install-plugin:3.1.0: install (default-install) composantes-materielles-involve ---

[INFO] BUILD FAILURE

Total time: 16.668 s

[INFO] Finished at: 2022-12-30T13:15:37-05:00

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:3.1.0: install (default-install) on project composantes-materielles-involve: The packaging plugin for this project did not assign a main file to the project but it has attachments. Change packaging to 'pom. -> [Help 1]

This is my config:

<plugin> 
<groupId>uk.org.raje.maven.plugins</groupId>
<artifactId>msbuild-maven-plugin</artifactId>
<version>1.3.1</version>
<extensions>true</extensions> <configuration>
<msbuildPath>${msBuild.path}</msbuildPath>
<projectFile>cc.Composantes.sln</projectFile> 
<platforms>
<platform>
<name>x86</name>
 <configurations>
<configuration>
<name>Release</name>
 </configuration>
</configurations>
</platform>
</platforms>
 </configuration>
</plugin>

Any suggestion?

It would be better to have the Mojo read an existing file and replace version information strings.

The path to external tools used by the plugin, such as CxxTest and CppCheck, can be defined via environment variables, such as CXXTEST_HOME and CPPCHECK_PATH.
Unfortunately, these environment variables are not picked up, hence the plug-in will fail to find the tools even if they are set.

AbstractMSBuildPluginMojo.java validates the tool paths correctly, however it always assume that the paths are set via the appropriate plug-in configuration property (such as CppCheckConfiguration.cppCheckPath). If they are set via an environment variable, the code fails to copy the path into the plug-in configuration property.

Add or modify the CppCheck Mojo so that it outputs the sonar configuration file to allow sonar runner to read the analysis results.

I would like to pass additional pre-processor variables. If I am not mistaken, msbuild.exe supports this (e.g. http://stackoverflow.com/questions/479979/msbuild-defining-conditional-compilation-symbols). I can't find a way to do it in the plugin as is...

At the moment we're capturing standard error markers in the MSBuild output via a regex. We're logging these markers as errors, so that CI tools (e.g. Jenkins) can perform appropriate error highlighting when displaying the build log.
MSBuild, however, also outputs fatal errors in this format (between ellipsis):

... : fatal error Cxywz: ...

which are not captured by our regex.
We'd need to capture this pattern to get the right highlighting in CI systems.

[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal uk.org.raje.maven.plugins:msbuild-maven-plugin:1.2.1:solution-package (default-solution-package) on project jenkins-builder: Syntax error while parsing solution file
ABC.sln: Required configuration|platform Release|Any CPU was not found in the solution -> [Help 1]
[ERROR]

Just create a new Solution with Visual Studio 2015/2017 and try to build it
<platforms> <platform> <name>Any CPU</name> <configurations> <configuration> <name>Release</name> </configuration> </configurations> </platform> </platforms>

When generating the sonar properties file we currently output the following:
Skipping test sonar, 'skip' set to true in the CxxTest configuration.

This is confusing, the error message should be removed (quiet mode in CxxTest enabled check?) or the text 'sonar' that is inserted clarified.

At the moment, when we're building a solution, we can specify what targets (i.e. projects) to build by using

<targets>
  <target>Target1</target>
</targets>

The target names do not actually represent project names. Instead MSBuild consider a target to be the folder, relative to the solution file folder, where the project to be compiled resides. So the target to build project.vcxproj below:

solution.sln
|
-- ProjectFolder
   |
   -- project.vcxproj

is actually ProjectFolder. This is not very intuitive and can be improved. The same issue also prevents us from running standalone projects (projects that are not part of a solution) as test project.

I propose to:

• ditch the MSBuild definition of target and use project names as targets
• introduce a new tag

<testTargets>
  <target>Target1</target>
</testTargets>

to explicitly specify projects that should be run as tests. This will also require removing the equivalent tags from the CxxTestMojo configuration.

Pros:

• The new naming scheme will be more intuitive to use for the final user.
• Tthe testTarget tag will allows us to decouple testing from CxxTest. It may be that in the future we may want to support other testing frameworks, so test targets should not be a CxxTest prerogative.
• We will be able to handle standalone projects as test. This requires checking whether either the target tag or the testTarget tag are present; if the former is present, we build the target using the standard MSBuild pipeline, if the latter is present and CxxTest is enabled, we build and run the project as a test project.

Cons:

• If we have two projects with the same name residing in two different folders we won't be able to decide which project to build. Probably this is a very rare occurrence.

I'm considering using this plugin in a new Maven project, and I am wondering about how much this is being maintained. I do see some releases (well, tagged versions at least) in the past couple of years, but I also see that the open issues are all more than five years old, and some are nine years old.
I'm also noticing that the documentation is very scant. The README mentions that the plugin supports building a version resource from the POM, but that functionality is not documented.
So I guess the question is whether this is being maintained and enhanced, or is it mostly dormant? If I were to invest in making a fork and submitting pull requests, would those be reviewed?

The plugin allows configuration of an outputDirectory for each platform-configuration pair, it would be useful to be able to selectively include outputs using FileSet configuration.
e.g.

<configuration>
  <name>foo</name>
  <output>
    <directory>/foo/bar</directory>
    <includes>
      <include>*.exe</include>
    </includes>
  </output>
</configuration>

The cxxtestgen script supports a --template flag which allows you to provide a custom template for generating the test runner. We are currently using this to set different world names in the runner for different platforms. It would be great if the Mojo supported this functionality allowing us to specify an optional runner template in the POM (if this value is missing from the xml, then do existing behavior and omit the --template flag so cxxtestgen will use its internal template instead).

Current pom configuration inputs insist on specifying at least 1 Platforms and allow for 0 or more Configurations, both are provided via /p property override

/property:name=value | /p:name=value | Set or override the specified project-level properties, where name is the property name and value is the property value. Specify each property separately, or use a semicolon or comma to separate multiple properties, as the following example shows: /property:WarningLevel=2;OutDir=bin\Debug

It would be great if it could be more flexible and allow for platform not being given at all, and for other properties to be provided also.

As an example for potential usage, when building UWP app for webstore, need additional options such as

MSBuild mysolution.sln /p:Configuration=Release;AppxBundle=Always;AppxBundlePlatforms="x86|x64|ARM"

or

MSBuild mysolution.sln /p:Configuration=Release /p:AppxBundle=Always /p:AppxBundlePlatforms="x86|x64|ARM"

At the moment the test reports end up in

target/surefire-reports

target/test-reports

It should be possible to configure the output file that should be created with the version information.

Would be nice to be able to configure an execution for say <version>15.0</version>

Reading current environment for MSBuild can be troublesome, similarly there are limitations with providing full path in configuration.

• may not be in developer shell
• may need multiple versions of msbuild within a single project
• may require additional configuration on per developer host, could build changes if misconfigured

Available MSBuild are listed in registry by installer

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VS7
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7

Configuring to read registry can be done with antrun plugin or others, but it's messy

  <plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <dependencies>
      <dependency>
        <groupId>ant-contrib</groupId>
        <artifactId>ant-contrib</artifactId>
        <version>1.0b2</version>
        <exclusions>
          <exclusion>
            <groupId>ant</groupId>
            <artifactId>ant</artifactId>
          </exclusion>
        </exclusions>
      </dependency>
    </dependencies>
    <executions>
      <execution>
        <id>SetPaths</id>
        <phase>validate</phase>
        <goals>
          <goal>run</goal>
        </goals>
        <configuration>
          <exportAntProperties>true</exportAntProperties>
          <target>
            <!-- taskdef for propertyregex -->
            <taskdef resource="net/sf/antcontrib/antlib.xml" classpathref="maven.plugin.classpath" />
            <exec dir="${basedir}" executable="REG" failonerror="true" outputproperty="MSBuild.Registry">
              <arg line="QUERY &quot;HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7&quot; /v &quot;15.0&quot;" />
            </exec>
            <propertyregex property="msbuild.path" input="${MSBuild.Registry}" regexp=".*REG_SZ\s*(.*)\\\s*" select="\1/MSBuild/15.0/bin/msbuild.exe" />
            <echo>MSBuild.Path = ${msbuild.path}</echo>
          </target>
        </configuration>
      </execution>
      <execution>
        <!--This is a duplicate of above that runs during clean lifecycle because the msbuild plugin includes clean-->
        <id>SetPaths for clean</id>
        <phase>pre-clean</phase>
        <goals>
          <goal>run</goal>
        </goals>
        <configuration>
          <exportAntProperties>true</exportAntProperties>
          <target>
            <!-- taskdef for propertyregex -->
            <taskdef resource="net/sf/antcontrib/antlib.xml" classpathref="maven.plugin.classpath" />
            <exec dir="${basedir}" executable="REG" failonerror="true" outputproperty="MSBuild.Registry">
              <arg line="QUERY &quot;HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7&quot; /v &quot;15.0&quot;" />
            </exec>
            <propertyregex property="msbuild.path" input="${MSBuild.Registry}" regexp=".*REG_SZ\s*(.*)\\\s*" select="\1/MSBuild/15.0/bin/msbuild.exe" />
            <echo>MSBuild.Path = ${msbuild.path}</echo>
          </target>
        </configuration>
      </execution>
    </executions>
  </plugin>

I've set up a project in VS 2012, sp3.
When I use msbuild-maven-plugin 1.2.1, I get the following error, although the mentioned configuration is actually there and the build Are there any hints? I can provide the pom and complete log via email if wanted.
regards
Carsten

[INFO] --- msbuild-maven-plugin:1.2.1:cxxtestgen (default-cxxtestgen) @ MxxxServiceSolution ---
[INFO] Skipping test runner generation, path to CxxTest not set
[INFO]
[INFO] --- msbuild-maven-plugin:1.2.1:testbuild (default-testbuild) @ MxxxServiceSolution ---
[INFO] Skipping test runner build, path to CxxTest not set
[INFO]
[INFO] --- msbuild-maven-plugin:1.2.1:test (default-test) @ MxxxServiceSolution ---
[INFO] Skipping test runner execution, path to CxxTest not set
[INFO]
[INFO] <<< msbuild-maven-plugin:1.2.1:solution-package (default-solution-package) @ MxxxServiceSolution <<<
[INFO]
[INFO] --- msbuild-maven-plugin:1.2.1:solution-package (default-solution-package) @ MxxxServiceSolution ---
[INFO] Parsing solution xxxMSS with platform=Any CPU, configuration=Release
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 57.353s
[INFO] Finished at: Wed Dec 04 10:41:33 CET 2013
[INFO] Final Memory: 8M/306M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal uk.org.raje.maven.plugins:msbuild-maven-plugin:1.2.1:solution-package (default-solution-package) on project xxxServiceSolution: Syntax error while parsing solution file C:\home\cahi\VisualStudio\xxxx\xxxMSS\xxxMSS.sln: Required configuration|
platform Release|Any CPU was not found in the solution -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

The Mojo currently always re-creates the output file, we should check the header files that are being used to generated the cpp file and only generate the cpp if 1 or more headers are newer.