[jira] [Commented] (NPANDAY-542) Support for multiple source dirs
[ https://issues.apache.org/jira/browse/NPANDAY-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13991596#comment-13991596 ] Greg Domjan commented on NPANDAY-542: - Will this include support for using the build-helper to add additional sources? Might relate to NPANDAY-609 plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId executions execution phasegenerate-sources/phase goals goaladd-source/goal /goals configuration sources source${project.build.directory}/generated-sources/XSDObjectGen/source /sources /configuration /execution /executions /plugin Support for multiple source dirs Key: NPANDAY-542 URL: https://issues.apache.org/jira/browse/NPANDAY-542 Project: NPanday Issue Type: Improvement Components: Maven Plugins Affects Versions: 1.4-incubating Reporter: Urs Keller Assignee: Lars Corneliussen Fix For: 1.5.0-incubating If another maven plugin generates sources for other plugins to process this is not picked up by NPanday. Typically we have a plugin adding to the sources with the following code: /** * The source directories containing the sources to be compiled. * * @parameter expression=${project.compileSourceRoots} * @required * @readonly */ private ListString compileSourceRoots; ... compileSourceRoots.add(getTargetDir().getAbsolutePath()); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NPANDAY-617) compile:generate-assembly-info Allow for filtering/customization of properties
Greg Domjan created NPANDAY-617: --- Summary: compile:generate-assembly-info Allow for filtering/customization of properties Key: NPANDAY-617 URL: https://issues.apache.org/jira/browse/NPANDAY-617 Project: NPanday Issue Type: Improvement Components: Maven Plugins Affects Versions: 1.4-incubating Reporter: Greg Domjan The generation of assembly info from the maven pom is desirable, especially in reguard to filling in version and copyright year, so having a static AssemblyInfo.cs to customize the value doesn't seem to be a good work around (unless I've missed an alternate way to apply filtering?) It is unclear where these might be sourced from [assembly: AssemblyCopyright()] [assembly: AssemblyTrademark()] [assembly: AssemblyCulture()] The [assembly: AssemblyProduct()] appears to be a combination of Company-Title and it would be good to be able to customize it. In regard to version, it appears maven2 version format isn't supported? If an alternate source for version could be provided so that the version formatted to .net/npanday standard could be used it would be helpful. For example Using the maven 2 standard format version of major.minor.revision-build reports issues due to generation requiring the 'string' version of major.minor.revision.build which can cause issues with version comparison. ie. version8.1.0-0-SNAPSHOT/version generates [assembly: AssemblyVersion(8.1.0)] [assembly: AssemblyInformationalVersion(8.1.0-0-SNAPSHOT)] warning CS1607: Assembly generation -- The version '8.1.0-0-SNAPSHOT' specified for the 'product version' is not in the normal 'major.minor. build.revision' format Best ref I found is http://mojo.codehaus.org/versions-maven-plugin/version-rules.html For example, Maven arranges the version list in the following manner: 1.0.1.0 1.0.10.1 1.0.10.2 1.0.9.3 Version 1.0.9.3 should come before 1.0.10.1 and 1.0.10.2, but the unexpected fourth field (.3) forced Maven to evaluate the version as a string. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NPANDAY-618) Plugin for execution of tlbimp.exe from windows platform sdk
Greg Domjan created NPANDAY-618: --- Summary: Plugin for execution of tlbimp.exe from windows platform sdk Key: NPANDAY-618 URL: https://issues.apache.org/jira/browse/NPANDAY-618 Project: NPanday Issue Type: Improvement Components: Maven Plugins Affects Versions: 1.4-incubating Environment: Windows Reporter: Greg Domjan Fix For: 1.5.0-incubating It would be nice to have a maven plugin that used the tlbimp.exe tool to generate an interop dll and do what is appropriate to archive it. This doesn't fit well within the compile lifecycle, but might work as a plugin used with the custom-lifecycle-maven-plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NPANDAY-620) Add Maven Artifact window doesn't resize/layout content to match change of window dialog size
Greg Domjan created NPANDAY-620: --- Summary: Add Maven Artifact window doesn't resize/layout content to match change of window dialog size Key: NPANDAY-620 URL: https://issues.apache.org/jira/browse/NPANDAY-620 Project: NPanday Issue Type: Improvement Components: Visual Studio Add-in Affects Versions: 1.5.0-incubating Environment: VS 2013 Reporter: Greg Domjan Priority: Minor Lists of artifacts can be quite long, being able to see a larger portion of the list at once would be helpful. The Add Maven Artifact window allows resizing but the content doesn't resize to match. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NPANDAY-619) Comments in pom.xml are removed when document is updated
Greg Domjan created NPANDAY-619: --- Summary: Comments in pom.xml are removed when document is updated Key: NPANDAY-619 URL: https://issues.apache.org/jira/browse/NPANDAY-619 Project: NPanday Issue Type: Bug Components: Visual Studio Add-in Affects Versions: 1.5.0-incubating Environment: VS 2013 Reporter: Greg Domjan Adding a Maven Artifact reference the pom.xml is updated and may be re arranged heavily which is annoying, but losing !-- -- comments is not acceptable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NPANDAY-572) When settings.xml already has a profiles section, configuring the remote repository from the AddIn creates an invalid settings file
[ https://issues.apache.org/jira/browse/NPANDAY-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999733#comment-13999733 ] Greg Domjan commented on NPANDAY-572: - I just built trunk and made the initial setting and found that a second profiles section was still being created. If the profile xmlns=http://maven.apache.org/SETTINGS/1.0.0; exists then modifying the Repo location will update the profile. There was no change to the mirror section. Since the status was resolved I thought to find this fixed, wondering did this get checked in yet? In a related issue, we already have a profile in settings to use this repo location, with the additional profile it also causes additional checks to the same repo. INFO] INFO] snapshot org.apache.npanday.plugins:maven-ilmerge-plugin:1.5.0-incubating-SNAPSHOT: checking for updates from nsl.nexus INFO] snapshot org.apache.npanday.plugins:maven-ilmerge-plugin:1.5.0-incubating-SNAPSHOT: checking for updates from public INFO] snapshot org.apache.npanday.plugins:maven-ilmerge-plugin:1.5.0-incubating-SNAPSHOT: checking for updates from npanday.repo INFO] snapshot org.apache.npanday.plugins:maven-dotnet-plugins:1.5.0-incubating-SNAPSHOT: checking for updates from npanday.repo When settings.xml already has a profiles section, configuring the remote repository from the AddIn creates an invalid settings file --- Key: NPANDAY-572 URL: https://issues.apache.org/jira/browse/NPANDAY-572 Project: NPanday Issue Type: Bug Components: Visual Studio Add-in Reporter: Brett Porter Assignee: Brett Porter Fix For: 1.5.0-incubating # Create a {{settings.xml}} file with a {{profiles}} section # Open an NPanday project in VS # Select Add Maven Artifact... from the context menu on the project # Go to the Configure Repository tab # Type in {{http://repo.maven.apache.org/maven2/}} and press Update The resulting {{settings.xml}} file has two {{profiles}} sections, one before {{activeProfiles}} and one after. A better alternative may be to use this field to set the mirror instead. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NPANDAY-621) Add Maven Artifact window, provide options to filter and reduce local/remote list size
Greg Domjan created NPANDAY-621: --- Summary: Add Maven Artifact window, provide options to filter and reduce local/remote list size Key: NPANDAY-621 URL: https://issues.apache.org/jira/browse/NPANDAY-621 Project: NPanday Issue Type: Improvement Components: Visual Studio Add-in Affects Versions: 1.5.0-incubating Environment: VS 2013 Reporter: Greg Domjan It would be helpful for both local list and remote tree to be able to provide a groupId or artifactId to filter the possible options listed. It might also be helpful to be able to provide a version. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NPANDAY-622) NPE - compile:testCompile
Greg Domjan created NPANDAY-622: --- Summary: NPE - compile:testCompile Key: NPANDAY-622 URL: https://issues.apache.org/jira/browse/NPANDAY-622 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.5.0-incubating Environment: VS 2013 Reporter: Greg Domjan As compile:compile cannot be skipped, needed to use custom-lifecycle-maven-plugin as the lifecycle extension to use tlbimp in createing the library. plugin groupIdorg.apache.npanday.plugins/groupId artifactIdcustom-lifecycle-maven-plugin/artifactId extensionstrue/extensions /plugin Following that, to add a test process tying to add plugin groupIdorg.apache.npanday.plugins/groupId artifactIdmaven-compile-plugin/artifactId configuration frameworkVersion3.0/frameworkVersion /configuration executions execution idtesting/id goals goalprocess-test-sources/goal goaltestCompile/goal /goals configuration /configuration /execution /executions /plugin [INFO] [compile:testCompile {execution: testing}] [INFO] NPANDAY-148-009: Took 11ms to resolve dependencies for group:art:library:8.1.0-0-SNAPSHOT with filter org .apache.maven.artifact.resolver.filter.AndArtifactFilter@4f14e777 [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at npanday.assembler.impl.AssemblerContextImpl.getClassExtensionFor(AssemblerContextImpl.java:190) at npanday.plugin.compile.AbstractCompilerMojo.getLanguageFileExtension(AbstractCompilerMojo.java:1471) at npanday.plugin.compile.TestCompilerMojo.getCompilerConfig(TestCompilerMojo.java:104) at npanday.plugin.compile.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1186) at npanday.plugin.compile.TestCompilerMojo.execute(TestCompilerMojo.java:59) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] It appears there is some dependency in testCompile that requires running the goal within the Compile as extension? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NPANDAY-623) Support reactor reference to other modules at compile phase
Greg Domjan created NPANDAY-623: --- Summary: Support reactor reference to other modules at compile phase Key: NPANDAY-623 URL: https://issues.apache.org/jira/browse/NPANDAY-623 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.4-incubating Reporter: Greg Domjan When building multiple artifacts with dependencies in the reactor it appears to be currently required that you build to the install phase. This can actually be a bug - see http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html Even if not a bug, this goes against some common practices such as used in the release-plugin which attempts to test the build by running all projects to compile stage only. In comparison the maven reactor allows for dependency resolution in Java JAR dependencies as soon as the compile phase is run. It does this by pointing the artifact file to the local class folder. NPanday could take similar action and point the file to the local target file as soon as compile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NPANDAY-624) NPE in ilMerge
Greg Domjan created NPANDAY-624: --- Summary: NPE in ilMerge Key: NPANDAY-624 URL: https://issues.apache.org/jira/browse/NPANDAY-624 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.5.0-incubating Environment: Windows, VS2005, VS2012, Platform SDK 6,7,7.1,8.0,8.1 Using npanday.settings to select mininmal framework version 3.0 Reporter: Greg Domjan ilMerge appears to be looking for the compiler details to select the appropriate ilMerge app. The compiler list is returning multiple options, but then ilMerge gets NPE on following call to ```File assemblyPath = compilerExecutable.getAssemblyPath();``` [DEBUG] NPANDAY-102-003: Apply rule:npanday.vendor.impl.VendorInfoTransitionRuleFactory$8@38c9aa93 [DEBUG] NPANDAY-103-017: Entering State = FFF [DEBUG] NPANDAY-103-052: Set defaults: 3.0 [DEBUG] NPANDAY-102-004: Vendor info requirement after rule:[VendorRequirement for vendor MICROSOFT version 3.0, Framework Version = 3.0] [DEBUG] NPANDAY-065-008: Found vendor [Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0] for requirement [VendorRequirement for vendor MICROSOFT version 3.0, Framework Version = 3.0] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[profile: 'FULL'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[language: 'C_SHARP'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='VB'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[language: 'C_SHARP'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='ASP'] [WARNING] NPANDAY-065-010: Found multiple matching capabilities; will choose the first one: [CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP']] [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:dotnet-library [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:dotnet-library [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil [DEBUG] NPANDAY-061-007: Artifact Type:false [WARNING] NPANDAY-231: previously netDependencyId was used to resolve some private bin path... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [DEBUG] Trace java.lang.NullPointerException at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:187) at com.google.common.base.Objects.firstNonNull(Objects.java:174) at npanday.executable.impl.CompilerContextImpl.getAssemblyPath(CompilerContextImpl.java:139) at npanday.executable.compiler.impl.BaseCompiler.getAssemblyPath(BaseCompiler.java:83) at
[jira] [Updated] (NPANDAY-623) Support reactor reference to other modules at compile phase
[ https://issues.apache.org/jira/browse/NPANDAY-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Domjan updated NPANDAY-623: Affects Version/s: 1.5.0-incubating Support reactor reference to other modules at compile phase Key: NPANDAY-623 URL: https://issues.apache.org/jira/browse/NPANDAY-623 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.4-incubating, 1.5.0-incubating Reporter: Greg Domjan When building multiple artifacts with dependencies in the reactor it appears to be currently required that you build to the install phase. This can actually be a bug - see http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html Even if not a bug, this goes against some common practices such as used in the release-plugin which attempts to test the build by running all projects to compile stage only. In comparison the maven reactor allows for dependency resolution in Java JAR dependencies as soon as the compile phase is run. It does this by pointing the artifact file to the local class folder. NPanday could take similar action and point the file to the local target file as soon as compile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NPANDAY-623) Support reactor reference to other modules at compile phase
[ https://issues.apache.org/jira/browse/NPANDAY-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015310#comment-14015310 ] Greg Domjan commented on NPANDAY-623: - It may be a Maven2 specific issue? Bumped version numbers so that there where no stored artifacts. Ran ```mvn clean compile -pl foo -am``` on a solution ( solution bar baz foo (depends on bar, baz) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] NPANDAY-901-003: Could not satisfy required dependencies for scope test Embedded error: NPANDAY-148-001: Could not resolve project dependencies com.somegroup:foo:dotnet-executable:8.1.0-0-SNAPSHOT Missing: -- 1) com.somegroup:bar:dotnet-library:8.1.0-1-SNAPSHOT ... 2) com.somegroup:baz:dotnet-library:8.1.0-1-SNAPSHOT As I've only requested building to the compile phase it shouldn't be trying to resolve dependencies for the test phase. This can be hidden if you have run to install previously, and it can lead to issue of linking against previous objects outside the reactor. Support reactor reference to other modules at compile phase Key: NPANDAY-623 URL: https://issues.apache.org/jira/browse/NPANDAY-623 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.4-incubating, 1.5.0-incubating Reporter: Greg Domjan When building multiple artifacts with dependencies in the reactor it appears to be currently required that you build to the install phase. This can actually be a bug - see http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html Even if not a bug, this goes against some common practices such as used in the release-plugin which attempts to test the build by running all projects to compile stage only. In comparison the maven reactor allows for dependency resolution in Java JAR dependencies as soon as the compile phase is run. It does this by pointing the artifact file to the local class folder. NPanday could take similar action and point the file to the local target file as soon as compile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (NPANDAY-624) NPE in ilMerge
[ https://issues.apache.org/jira/browse/NPANDAY-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Domjan updated NPANDAY-624: Environment: Windows, VS2005, VS2012, Platform SDK 6,7,7.1,8.0,8.1 Using npanday.settings to select mininmal framework version 3.0 Maven 2.2.1 was: Windows, VS2005, VS2012, Platform SDK 6,7,7.1,8.0,8.1 Using npanday.settings to select mininmal framework version 3.0 NPE in ilMerge -- Key: NPANDAY-624 URL: https://issues.apache.org/jira/browse/NPANDAY-624 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.5.0-incubating Environment: Windows, VS2005, VS2012, Platform SDK 6,7,7.1,8.0,8.1 Using npanday.settings to select mininmal framework version 3.0 Maven 2.2.1 Reporter: Greg Domjan ilMerge appears to be looking for the compiler details to select the appropriate ilMerge app. The compiler list is returning multiple options, but then ilMerge gets NPE on following call to ```File assemblyPath = compilerExecutable.getAssemblyPath();``` [DEBUG] NPANDAY-102-003: Apply rule:npanday.vendor.impl.VendorInfoTransitionRuleFactory$8@38c9aa93 [DEBUG] NPANDAY-103-017: Entering State = FFF [DEBUG] NPANDAY-103-052: Set defaults: 3.0 [DEBUG] NPANDAY-102-004: Vendor info requirement after rule:[VendorRequirement for vendor MICROSOFT version 3.0, Framework Version = 3.0] [DEBUG] NPANDAY-065-008: Found vendor [Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0] for requirement [VendorRequirement for vendor MICROSOFT version 3.0, Framework Version = 3.0] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[profile: 'FULL'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[language: 'C_SHARP'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='VB'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[language: 'C_SHARP'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='ASP'] [WARNING] NPANDAY-065-010: Found multiple matching capabilities; will choose the first one: [CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP']] [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:dotnet-library [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:dotnet-library [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil [DEBUG] NPANDAY-061-007: Artifact Type:false [WARNING] NPANDAY-231: previously netDependencyId was used to resolve some private bin path... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO]
[jira] [Updated] (NPANDAY-623) Support reactor reference to other modules at compile phase
[ https://issues.apache.org/jira/browse/NPANDAY-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Domjan updated NPANDAY-623: Environment: Maven 2.2.1 Support reactor reference to other modules at compile phase Key: NPANDAY-623 URL: https://issues.apache.org/jira/browse/NPANDAY-623 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.4-incubating, 1.5.0-incubating Environment: Maven 2.2.1 Reporter: Greg Domjan When building multiple artifacts with dependencies in the reactor it appears to be currently required that you build to the install phase. This can actually be a bug - see http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html Even if not a bug, this goes against some common practices such as used in the release-plugin which attempts to test the build by running all projects to compile stage only. In comparison the maven reactor allows for dependency resolution in Java JAR dependencies as soon as the compile phase is run. It does this by pointing the artifact file to the local class folder. NPanday could take similar action and point the file to the local target file as soon as compile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NPANDAY-625) Support /debug:pdbonly compile option
Greg Domjan created NPANDAY-625: --- Summary: Support /debug:pdbonly compile option Key: NPANDAY-625 URL: https://issues.apache.org/jira/browse/NPANDAY-625 Project: NPanday Issue Type: Improvement Components: Maven Plugins Affects Versions: 1.5.0-incubating Reporter: Greg Domjan Compiler mojo supports creating a pdb, however /debug+ is equivelant to /debug:full and can tend to cause decreased performance due to setting the DebuggableAttribute http://msdn.microsoft.com/en-us/library/8cw0bt21.aspx http://msdn.microsoft.com/en-us/library/9dd8z24x.aspx CompilerMojo:138 if (isDebug) { params.add(/debug+); } Would like some way to choose params.add(/debug:pdbonly); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NPANDAY-623) Support reactor reference to other modules at compile phase
[ https://issues.apache.org/jira/browse/NPANDAY-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027505#comment-14027505 ] Greg Domjan commented on NPANDAY-623: - Ok, I see where this might not have been covered now. When using custom-lifecycle-maven-plugin externally generated items are identified at install/deploy if they have the right name, but are not identified at 'compile' because there is no compile goal, instead they are identified by custom-lifecycle:set-artifact Requires adding this to work around the issue executions execution idCSharpObjGen/id phasecompile/phase goals goalset-artifact/goal /goals /execution /executions Then, this is working differently to the compile-lifecycle. As custom-lifecycle uses final name which will by default include a version number, compared to compile-lifecycle wich will build a dll without version in the name and attach it. [INFO] [custom-lifecycle:set-artifact {execution: default-set-artifact}] [WARNING] NPANDAY-105-001: Could not set expected artifact to 'E:\example\bar\target\bar-8.1.0-0-SNAPSHOT.dll', because it does not exist So also to configure finalName${project.artifactId}/finalName Support reactor reference to other modules at compile phase Key: NPANDAY-623 URL: https://issues.apache.org/jira/browse/NPANDAY-623 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.4-incubating, 1.5.0-incubating Environment: Maven 2.2.1 Reporter: Greg Domjan When building multiple artifacts with dependencies in the reactor it appears to be currently required that you build to the install phase. This can actually be a bug - see http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html Even if not a bug, this goes against some common practices such as used in the release-plugin which attempts to test the build by running all projects to compile stage only. In comparison the maven reactor allows for dependency resolution in Java JAR dependencies as soon as the compile phase is run. It does this by pointing the artifact file to the local class folder. NPanday could take similar action and point the file to the local target file as soon as compile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NPANDAY-623) Support reactor reference to other modules at compile phase
[ https://issues.apache.org/jira/browse/NPANDAY-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14030319#comment-14030319 ] Greg Domjan commented on NPANDAY-623: - I think perhaps this needs to change to a doc issue, it's not so much a bug as a 'maven doesn't work that way' issue that needs some reminder. Attaching the artifact or 'set-artifact' needs to be run as a step in compile - and needs to run after the artifact file is present. - anything after compile it is not much better than being run in package. option 1) could change set-artifact to run during compile (instead of package), but as part of default lifecycle it would run before other project additional actions also run during compile - this could make it run too early and thus fail on clean builds. 'custom builds' could be done during an earlier phase like generate-sources, this would need to be documented. While the artifact should match finalName newbies might not know, could be good to include in that doc. (I still make the mistake often as can be seen even in the example I didn't use it for the target name) option 2) use some other plugin to attach the artifact when it is built - like build-helper or if using some other maven scripting tools such as the example maven-antrun-plugin ensuring you have a suitable ```attachartifact file=${project.build.directory}\${project.build.finalName}.dll type=dll/``` option 3) add to usage document of custom-lifecycle-maven-plugin that an execution should be added to support the release pluggin and compilation only builds. executions execution idCSharpObjGen/id phasecompile/phase goals goalset-artifact/goal /goals /execution /executions Feel free to close this out, if I get a chance I'll submit a change for doc along the lines above. Support reactor reference to other modules at compile phase Key: NPANDAY-623 URL: https://issues.apache.org/jira/browse/NPANDAY-623 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.4-incubating, 1.5.0-incubating Environment: Maven 2.2.1 Reporter: Greg Domjan Attachments: example.zip When building multiple artifacts with dependencies in the reactor it appears to be currently required that you build to the install phase. This can actually be a bug - see http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html Even if not a bug, this goes against some common practices such as used in the release-plugin which attempts to test the build by running all projects to compile stage only. In comparison the maven reactor allows for dependency resolution in Java JAR dependencies as soon as the compile phase is run. It does this by pointing the artifact file to the local class folder. NPanday could take similar action and point the file to the local target file as soon as compile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (NPANDAY-624) NPE in ilMerge
[ https://issues.apache.org/jira/browse/NPANDAY-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Domjan updated NPANDAY-624: Description: ilMerge appears to be looking for the compiler details to select the appropriate ilMerge app. The compiler list is returning multiple options, but then ilMerge gets NPE on following call to {code}File assemblyPath = compilerExecutable.getAssemblyPath();{code} {noformat} [DEBUG] NPANDAY-102-003: Apply rule:npanday.vendor.impl.VendorInfoTransitionRuleFactory$8@38c9aa93 [DEBUG] NPANDAY-103-017: Entering State = FFF [DEBUG] NPANDAY-103-052: Set defaults: 3.0 [DEBUG] NPANDAY-102-004: Vendor info requirement after rule:[VendorRequirement for vendor MICROSOFT version 3.0, Framework Version = 3.0] [DEBUG] NPANDAY-065-008: Found vendor [Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0] for requirement [VendorRequirement for vendor MICROSOFT version 3.0, Framework Version = 3.0] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[profile: 'FULL'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[language: 'C_SHARP'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='VB'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[language: 'C_SHARP'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='ASP'] [WARNING] NPANDAY-065-010: Found multiple matching capabilities; will choose the first one: [CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP']] [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:dotnet-library [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:dotnet-library [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil [DEBUG] NPANDAY-061-007: Artifact Type:false [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil [DEBUG] NPANDAY-061-007: Artifact Type:false [WARNING] NPANDAY-231: previously netDependencyId was used to resolve some private bin path... {noformat} {noformat} [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [DEBUG] Trace java.lang.NullPointerException at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:187) at com.google.common.base.Objects.firstNonNull(Objects.java:174) at npanday.executable.impl.CompilerContextImpl.getAssemblyPath(CompilerContextImpl.java:139) at npanday.executable.compiler.impl.BaseCompiler.getAssemblyPath(BaseCompiler.java:83) at npanday.executable.compiler.impl.DefaultCompiler.getAssemblyPath(DefaultCompiler.java:48) at npanday.plugin.ilmerge.AssemblyMerger.execute(AssemblyMerger.java:263) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at
[jira] [Commented] (NPANDAY-624) NPE in ilMerge
[ https://issues.apache.org/jira/browse/NPANDAY-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14030353#comment-14030353 ] Greg Domjan commented on NPANDAY-624: - I did have a brief look at the code at the ilmerge.AssemblyMerger but didn't dig further because I had no idea why it was getting settings from the compiler. At the moment it is a bit of a magic black box to me :) I'll certainly have a go at digging further when I next get a chance. Some other things I noticed while trying to look into this more in relation to compile only Vs install ... I notice with that other sample that there are log lines com.somegroup:baz:dotnet-symbols:8.1.0-0-SNAPSHOT however unless running a debug build the symbols are not generated. This info is a bit noisy, and not sure if it is a real issue or not. When turning on debug symbols {code:xml} configuration isDebugtrue/isDebug attachPdbtrue/attachPdb /configuration {code} {noformat} [DEBUG] NPANDAY-900-016: Attaching pdb project artifact E:\Data\Projects\Securelogin\SecureLogin-8-1\SecureLogin\example\baz\target\baz.pdb [DEBUG] NPANDAY-900-015: Attaching default project artifact E:\Data\Projects\Securelogin\SecureLogin-8-1\SecureLogin\example\baz\target\baz. dll {noformat} Still the following process of ilmerge on foo has issue - appears to be ignoring the reactor provided artifacts for maven2 during compile only. {noformat} [INFO] [ilmerge:merge-assemblies {execution: unpack tools}] Downloading: http://nexus.labs.blr.novell.com:8080/nexus/content/groups/nsl-team/com/somegroup/baz/8.1.0-0-SNAPSHOT/baz-8.1.0-0-SNAPSHOT.pdb [INFO] Unable to find resource 'com.somegroup:baz:dotnet-symbols:8.1.0-0-SNAPSHOT' in repository nsl.nexus (http://nexus.labs.blr.novell.com :8080/nexus/content/groups/nsl-team) Downloading: http://nexus.labs.blr.novell.com:8080/nexus/content/groups/public/com/somegroup/baz/8.1.0-0-SNAPSHOT/baz-8.1.0-0-SNAPSHOT.pdb [INFO] Unable to find resource 'com.somegroup:baz:dotnet-symbols:8.1.0-0-SNAPSHOT' in repository public (http://nexus.labs.blr.novell.com:80 80/nexus/content/groups/public) [INFO] NPANDAY-148-009: Took 112ms to resolve dependencies for com.somegroup:foo:dotnet-executable:8.1.0-0-SNAPSHOT with filter org.apache.m aven.artifact.resolver.filter.ScopeArtifactFilter@75eee7b7 [WARNING] NPANDAY-065-010: Found multiple matching capabilities; will choose the first one: [CompilerCapability [vendorInfo=[Configured Vend or Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configu red Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo= [Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [ven dorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP']] [WARNING] NPANDAY-231: previously netDependencyId was used to resolve some private bin path... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:187) at com.google.common.base.Objects.firstNonNull(Objects.java:174) at npanday.executable.impl.CompilerContextImpl.getAssemblyPath(CompilerContextImpl.java:139) at npanday.executable.compiler.impl.BaseCompiler.getAssemblyPath(BaseCompiler.java:83) at npanday.executable.compiler.impl.DefaultCompiler.getAssemblyPath(DefaultCompiler.java:48) at npanday.plugin.ilmerge.AssemblyMerger.execute(AssemblyMerger.java:263) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at
[jira] [Commented] (NPANDAY-618) Plugin for execution of tlbimp.exe from windows platform sdk
[ https://issues.apache.org/jira/browse/NPANDAY-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047374#comment-14047374 ] Greg Domjan commented on NPANDAY-618: - I hadn't noted the com_reference dependency type. Though I might be missing something, this doesn't seem to capture the generated dll as an artifact? It would be nice to be able to customize the options for tlbimp further. Plugin for execution of tlbimp.exe from windows platform sdk Key: NPANDAY-618 URL: https://issues.apache.org/jira/browse/NPANDAY-618 Project: NPanday Issue Type: Improvement Components: Maven Plugins Affects Versions: 1.4-incubating Environment: Windows Reporter: Greg Domjan Labels: COM, plugin It would be nice to have a maven plugin that used the tlbimp.exe tool to generate an interop dll and do what is appropriate to archive it. This doesn't fit well within the compile lifecycle, but might work as a plugin used with the custom-lifecycle-maven-plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NPANDAY-632) NPE when using netHome maven configuration
Greg Domjan created NPANDAY-632: --- Summary: NPE when using netHome maven configuration Key: NPANDAY-632 URL: https://issues.apache.org/jira/browse/NPANDAY-632 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.5.0-incubating Reporter: Greg Domjan When adding to the ilmerge-plugin the configuration {code}netHome\Some\Custom\PathnetHome{code} Get an NPE when adding to the executableConfig.getExecutionPaths container before creating it. My quick fix was {code} ### Eclipse Workspace Patch 1.0 #P org.apache.npanday.dotnet-executable Index: src/main/java/npanday/executable/impl/NetExecutableFactoryImpl.java === --- src/main/java/npanday/executable/impl/NetExecutableFactoryImpl.java (revision 1609378) +++ src/main/java/npanday/executable/impl/NetExecutableFactoryImpl.java (working copy) @@ -85,6 +85,8 @@ ? new ArrayListString() : executableConfig.getExecutionPaths(); +executableConfig.setExecutionPaths( executablePaths ); + if ( netHome != null ) { getLogger().info( NPANDAY-066-014: Found executable path in pom: Path = + netHome.getAbsolutePath() ); @@ -92,8 +94,6 @@ } -executableConfig.setExecutionPaths( executablePaths ); - final ExecutableCapability executableCapability = capabilityMatcher.matchExecutableCapabilityFor( executableRequirement ); {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NPANDAY-624) NPE in ilMerge
[ https://issues.apache.org/jira/browse/NPANDAY-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14057398#comment-14057398 ] Greg Domjan commented on NPANDAY-624: - Thanks Brett, That took me a step further, and gave me some ideas on taking further steps. Next as ILMerge isn't part of the .net framework had to adjust the netHome so it could be found. (NPANDAY-632 found) {code} profileAssemblyPath${project.build.directory}/profileAssemblyPath netHome${ILMerge.path}/netHome {code} Then the plugin didn't seem to have any dependencies except the the project. Missing {code}@requiresDependencyResolution compile{code} Following that I had some follow on issues with selecting only some dependencies to merge, especially where there are unmerged dependencies that are not in the GAC. I'm working out what really should happen to try and submit a patch, is there some integration test that I can verify I'm not breaking other previous rules with? (its doesn't appear to be stored with each plugin) Other issues are with * /lib list should be containing .references/{artifact} paths to find dependencies without version name mangling. ILmerge can't find them otherwise if the repo paths are added directly * ?getting the .references for a maven build * lack of clarity on what artifacts and internalizeArtifact lists should contain * artifacts list doesn't seem like it should be added to the merge list * internalizeArtifact list doesn't contain the projectArtifact (it is coming in from artifacts list) NPE in ilMerge -- Key: NPANDAY-624 URL: https://issues.apache.org/jira/browse/NPANDAY-624 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.5.0-incubating Environment: Windows, VS2005, VS2012, Platform SDK 6,7,7.1,8.0,8.1 Using npanday.settings to select mininmal framework version 3.0 Maven 2.2.1 Reporter: Greg Domjan ilMerge appears to be looking for the compiler details to select the appropriate ilMerge app. The compiler list is returning multiple options, but then ilMerge gets NPE on following call to {code}File assemblyPath = compilerExecutable.getAssemblyPath();{code} {noformat} [DEBUG] NPANDAY-102-003: Apply rule:npanday.vendor.impl.VendorInfoTransitionRuleFactory$8@38c9aa93 [DEBUG] NPANDAY-103-017: Entering State = FFF [DEBUG] NPANDAY-103-052: Set defaults: 3.0 [DEBUG] NPANDAY-102-004: Vendor info requirement after rule:[VendorRequirement for vendor MICROSOFT version 3.0, Framework Version = 3.0] [DEBUG] NPANDAY-065-008: Found vendor [Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0] for requirement [VendorRequirement for vendor MICROSOFT version 3.0, Framework Version = 3.0] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[profile: 'FULL'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[language: 'C_SHARP'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='VB'] [DEBUG] NPANDAY-065-009: Failed to match policy: ExecutableMatchPolicy[language: 'C_SHARP'] [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='ASP'] [WARNING] NPANDAY-065-010: Found multiple matching capabilities; will choose the first one: [CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', language='C_SHARP'],
[jira] [Created] (NPANDAY-636) Support .Net4 Additional option Embed Com Interop to ArtifactType.COM_REFERENCE
Greg Domjan created NPANDAY-636: --- Summary: Support .Net4 Additional option Embed Com Interop to ArtifactType.COM_REFERENCE Key: NPANDAY-636 URL: https://issues.apache.org/jira/browse/NPANDAY-636 Project: NPanday Issue Type: Improvement Components: Maven Plugins, Visual Studio Add-in Affects Versions: 1.5.0-incubating Reporter: Greg Domjan Visual studio makes available when compiling a .NetFramework 4 module, for references that are Interop/com a new option Embed Interop Types. This option swaps between using /reference to /link and also manages Copy Local where an embedded /link[ed] item doesn't need to be copied to the output location. About embedded Interop types Vs Primary Interop Assemblies (PIA) Where MS suggest * a preference for embedded as it is more flexible for multiple versions of an interface * Interop that is not embedded, should ideally be signed and identified as primary for security. http://msdn.microsoft.com/en-us/library/vstudio/3y76b69k%28v=vs.100%29.aspx http://msdn.microsoft.com/en-us/library/dd997297(v=vs.100).aspx About compilation http://msdn.microsoft.com/en-us/library/538aes2a%28v=vs.110%29.aspx http://msdn.microsoft.com/en-us/library/dd264728(v=vs.110).aspx My understanding is that these Interop modules are not attached/kept as output for maven, rather rebuilt in downstream as necessary. It seems that if not embedding, then it is more appropriate to have the Interop as a seperate module. Makes me wonder if COM_REFERENCE is an appropriate dependency if not embedding, could COM_REFERENCE imply embedding? -- This message was sent by Atlassian JIRA (v6.3.4#6332)