[jira] [Commented] (NPANDAY-542) Support for multiple source dirs

2014-05-07 Thread Greg Domjan (JIRA) 

[ 
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

2014-05-11 Thread Greg Domjan (JIRA) 
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

2014-05-12 Thread Greg Domjan (JIRA) 
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

2014-05-16 Thread Greg Domjan (JIRA) 
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

2014-05-16 Thread Greg Domjan (JIRA) 
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

2014-05-16 Thread Greg Domjan (JIRA) 

[ 
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

2014-05-16 Thread Greg Domjan (JIRA) 
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

2014-05-19 Thread Greg Domjan (JIRA) 
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

2014-05-26 Thread Greg Domjan (JIRA) 
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

2014-06-02 Thread Greg Domjan (JIRA) 
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

2014-06-02 Thread Greg Domjan (JIRA) 

 [ 
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

2014-06-02 Thread Greg Domjan (JIRA) 

[ 
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

2014-06-02 Thread Greg Domjan (JIRA) 

 [ 
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

2014-06-02 Thread Greg Domjan (JIRA) 

 [ 
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

2014-06-10 Thread Greg Domjan (JIRA) 
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

2014-06-11 Thread Greg Domjan (JIRA) 

[ 
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

2014-06-13 Thread Greg Domjan (JIRA) 

[ 
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

2014-06-13 Thread Greg Domjan (JIRA) 

 [ 
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

2014-06-13 Thread Greg Domjan (JIRA) 

[ 
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

2014-06-29 Thread Greg Domjan (JIRA) 

[ 
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

2014-07-10 Thread Greg Domjan (JIRA) 
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

2014-07-10 Thread Greg Domjan (JIRA) 

[ 
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

2014-12-10 Thread Greg Domjan (JIRA) 
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)