from:"Brett Porter"


[ 
https://issues.apache.org/jira/browse/NPANDAY-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105089#comment-14105089
 ] 

Brett Porter commented on NPANDAY-537:
--

will break out into a separate ticket

 Add dotnet-windows-executable packaging
 ---

 Key: NPANDAY-537
 URL: https://issues.apache.org/jira/browse/NPANDAY-537
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 In an earlier release, winexe was deprecated in favour of a unified 
 dotnet-executable (along with exe). However, there is still a valid use 
 case for a separate packaging that triggers the alternate /target parameter 
 to CSC that will generate a windows executable (with no console window 
 attached, for example).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-537) Add dotnet-windows-executable packaging


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

Brett Porter resolved NPANDAY-537.
--

Resolution: Fixed

 Add dotnet-windows-executable packaging
 ---

 Key: NPANDAY-537
 URL: https://issues.apache.org/jira/browse/NPANDAY-537
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 In an earlier release, winexe was deprecated in favour of a unified 
 dotnet-executable (along with exe). However, there is still a valid use 
 case for a separate packaging that triggers the alternate /target parameter 
 to CSC that will generate a windows executable (with no console window 
 attached, for example).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (NPANDAY-633) Deprecate dotnet-windows-exectable packaging

Brett Porter created NPANDAY-633:


 Summary: Deprecate dotnet-windows-exectable packaging
 Key: NPANDAY-633
 URL: https://issues.apache.org/jira/browse/NPANDAY-633
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Brett Porter
Priority: Minor


Per NPANDAY-537, this would be better to just be EXE, with a consistent method 
of supplying this as the target to the compile plugin through an argument.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (NPANDAY-599) Cache resolve-result reactor-wide to avoid pdb/gac/++ beeing resolved multiple times


[ 
https://issues.apache.org/jira/browse/NPANDAY-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105249#comment-14105249
 ] 

Brett Porter commented on NPANDAY-599:
--

thanks, I forgot to update the ticket.

Yes, I think rather than trying to modify the lookups, it's better to have a 
single cache, but key it based on the project ID.

 Cache resolve-result reactor-wide to avoid pdb/gac/++ beeing resolved 
 multiple times
 

 Key: NPANDAY-599
 URL: https://issues.apache.org/jira/browse/NPANDAY-599
 Project: NPanday
  Issue Type: Sub-task
  Components: Maven Plugins
Reporter: Lars Corneliussen
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 Currently it seems like our custom contributors/resolvers execute for every 
 possible path (artifact.getDependencyTrail() changes...).
 We can cache what we resolved reactor-wide in a separate component.
 Cachekey would be artifact.getId(), right?
 Should we let each contributor implement the cache 
 (ArtifactResolvingContributor) - or should it be generically handled in the 
 artifact resolver? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-293) AddIn file created by installer differs from maven-vsinstaller-plugin


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

Brett Porter resolved NPANDAY-293.
--

   Resolution: Fixed
Fix Version/s: (was: Backlog)
   1.5.0-incubating
 Assignee: Brett Porter

Did this yesterday, didn't realise there was a ticket for it

 AddIn file created by installer differs from maven-vsinstaller-plugin
 -

 Key: NPANDAY-293
 URL: https://issues.apache.org/jira/browse/NPANDAY-293
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Brett Porter
Priority: Minor
 Fix For: 1.5.0-incubating


 The About box is empty, and the version not displayed, when using the MSI to 
 install NPanday. This is because the .AddIn file generated in 
 ~/Documents/Visual Studio 200x/AddIns is different and does not contain the 
 About Box info and the same description tag.
 It would be good if the AddIn got the console version from the assembly 
 version of the AddIn instead of parsing the description. I'm not sure if 
 there is an alternative for the About box that would make it available inside 
 the AddIn DLL instead - maybe as a resource?
 If not, then the MSI WiX script generator needs to be changed to create an 
 identical AddIn file with the additional information. We should also add a 
 comment or automated way to DRY the info for the AddIn template.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (NPANDAY-467) resgen:generate-existing-resx-to-resource not finding resx files for translation to resources


[ 
https://issues.apache.org/jira/browse/NPANDAY-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106277#comment-14106277
 ] 

Brett Porter commented on NPANDAY-467:
--

patch looks good, applying. Note that adding this feature in partially 
addresses NPANDAY-227, but can cause some backwards compatibility issues, so I 
will address that as well.

 resgen:generate-existing-resx-to-resource not finding resx files for 
 translation to resources
 -

 Key: NPANDAY-467
 URL: https://issues.apache.org/jira/browse/NPANDAY-467
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.4-incubating
 Environment: Windows XP, .Net Framework 3.5, Java 6
Reporter: Anthony Whitford
Priority: Critical
 Fix For: 1.5.0-incubating

 Attachments: ExistingResxGenerator.patch


 The code says:{code}
 List commands = null;
 for (EmbeddedResource embeddedResource : embeddedResources)
 {
 File file = new File(project.getBuild().getSourceDirectory() 
 + File.separator + embeddedResource.getSourceFile());
 if(!file.exists()) continue;
 commands = getCommands(file.getAbsoluteFile(), 
 resourceDirectory, embeddedResource.getName());
 netExecutableFactory.getNetExecutableFor( vendor, 
 frameworkVersion, RESGEN,commands ,
   netHome ).execute();
 }
 if(embeddedResources == null)
 {
String sourceDirectory = project.getBasedir().getPath();
String[] resourceFilenames  = 
 FileUtils.getFilesFromExtension(sourceDirectory, new String[]{resx});
for(String resourceFilename : resourceFilenames)
{
   File file = new File(resourceFilename);
   if(!file.exists()) continue;
   String name = 
 resourceFilename.substring(sourceDirectory.length() + 1).replace('\\', '.');
   name = project.getArtifactId() + . + name.substring(0, 
 name.lastIndexOf('.'));
   commands = getCommands(file.getAbsoluteFile(), 
 resourceDirectory, name);
   netExecutableFactory.getNetExecutableFor( vendor, 
 frameworkVersion, RESGEN,commands ,
  netHome ).execute();
   }
 }
 {code}
 The {{if(embeddedResources == null)}} doesn't really make sense here because 
 {{embeddedResources}} is an empty array.  This needs to be changed to: {{if 
 (0 == embeddedResources.length)}}.  Without this fix, the plugin is not 
 running this code that is designed to find the resx files and generate the 
 resource files.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-227) Improve Implementation on handling of Resources


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

Brett Porter updated NPANDAY-227:
-

Fix Version/s: (was: Backlog)
   1.5.0-incubating

 Improve Implementation on handling of Resources
 ---

 Key: NPANDAY-227
 URL: https://issues.apache.org/jira/browse/NPANDAY-227
 Project: NPanday
  Issue Type: Bug
  Components: Project Importer
Reporter: Joe Ocaba
Assignee: Brett Porter
Priority: Minor
 Fix For: 1.5.0-incubating


 This is related to 
 http://npanday.codeplex.com/WorkItem/View.aspx?WorkItemId=10603# 
 The current implementation deals with a lot of configurations on the part of 
 the pom.
 We should have a simpler pom and follow more on the conventions that is set 
 by maven.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (NPANDAY-227) Improve Implementation on handling of Resources


[ 
https://issues.apache.org/jira/browse/NPANDAY-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106327#comment-14106327
 ] 

Brett Porter commented on NPANDAY-227:
--

applied, adding IT

 Improve Implementation on handling of Resources
 ---

 Key: NPANDAY-227
 URL: https://issues.apache.org/jira/browse/NPANDAY-227
 Project: NPanday
  Issue Type: Bug
  Components: Project Importer
Reporter: Joe Ocaba
Assignee: Brett Porter
Priority: Minor
 Fix For: 1.5.0-incubating


 This is related to 
 http://npanday.codeplex.com/WorkItem/View.aspx?WorkItemId=10603# 
 The current implementation deals with a lot of configurations on the part of 
 the pom.
 We should have a simpler pom and follow more on the conventions that is set 
 by maven.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-467) resgen:generate-existing-resx-to-resource not finding resx files for translation to resources


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

Brett Porter resolved NPANDAY-467.
--

Resolution: Fixed
  Assignee: Brett Porter

Applied - thanks for the patch and sorry for the significant delay!

 resgen:generate-existing-resx-to-resource not finding resx files for 
 translation to resources
 -

 Key: NPANDAY-467
 URL: https://issues.apache.org/jira/browse/NPANDAY-467
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.4-incubating
 Environment: Windows XP, .Net Framework 3.5, Java 6
Reporter: Anthony Whitford
Assignee: Brett Porter
Priority: Critical
 Fix For: 1.5.0-incubating

 Attachments: ExistingResxGenerator.patch


 The code says:{code}
 List commands = null;
 for (EmbeddedResource embeddedResource : embeddedResources)
 {
 File file = new File(project.getBuild().getSourceDirectory() 
 + File.separator + embeddedResource.getSourceFile());
 if(!file.exists()) continue;
 commands = getCommands(file.getAbsoluteFile(), 
 resourceDirectory, embeddedResource.getName());
 netExecutableFactory.getNetExecutableFor( vendor, 
 frameworkVersion, RESGEN,commands ,
   netHome ).execute();
 }
 if(embeddedResources == null)
 {
String sourceDirectory = project.getBasedir().getPath();
String[] resourceFilenames  = 
 FileUtils.getFilesFromExtension(sourceDirectory, new String[]{resx});
for(String resourceFilename : resourceFilenames)
{
   File file = new File(resourceFilename);
   if(!file.exists()) continue;
   String name = 
 resourceFilename.substring(sourceDirectory.length() + 1).replace('\\', '.');
   name = project.getArtifactId() + . + name.substring(0, 
 name.lastIndexOf('.'));
   commands = getCommands(file.getAbsoluteFile(), 
 resourceDirectory, name);
   netExecutableFactory.getNetExecutableFor( vendor, 
 frameworkVersion, RESGEN,commands ,
  netHome ).execute();
   }
 }
 {code}
 The {{if(embeddedResources == null)}} doesn't really make sense here because 
 {{embeddedResources}} is an empty array.  This needs to be changed to: {{if 
 (0 == embeddedResources.length)}}.  Without this fix, the plugin is not 
 running this code that is designed to find the resx files and generate the 
 resource files.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-227) Improve Implementation on handling of Resources


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

Brett Porter resolved NPANDAY-227.
--

Resolution: Fixed

 Improve Implementation on handling of Resources
 ---

 Key: NPANDAY-227
 URL: https://issues.apache.org/jira/browse/NPANDAY-227
 Project: NPanday
  Issue Type: Bug
  Components: Project Importer
Reporter: Joe Ocaba
Assignee: Brett Porter
Priority: Minor
 Fix For: 1.5.0-incubating


 This is related to 
 http://npanday.codeplex.com/WorkItem/View.aspx?WorkItemId=10603# 
 The current implementation deals with a lot of configurations on the part of 
 the pom.
 We should have a simpler pom and follow more on the conventions that is set 
 by maven.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-454) maven-compile-plugin: includeSources section has issues with the path delimiter


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

Brett Porter resolved NPANDAY-454.
--

Resolution: Fixed

Either separator now correctly translated on Mono now.

 maven-compile-plugin: includeSources section has issues with the path 
 delimiter
 -

 Key: NPANDAY-454
 URL: https://issues.apache.org/jira/browse/NPANDAY-454
 Project: NPanday
  Issue Type: Bug
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
 Java version: 1.6.0_24
 Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
 Default locale: en_US, platform encoding: MacRoman
 OS name: mac os x version: 10.6.7 arch: x86_64 Family: mac
 Mono 2.6.7
 NPanday: 1.4.0-incubating
Reporter: Matthias Weßendorf
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 The pom.xml (sample) files in NPanday are using the following syntax to 
 include the AssemblyInfo.cs file:
 {code}
 includeSources
   includeSourceProperties\AssemblyInfo.cs/includeSource   
 /includeSources
 {code}
 However on Mac/Mono this seems to be ignored. Changing to this
 {code}
 includeSources
   includeSourceProperties/AssemblyInfo.cs/includeSource   
 /includeSources
 {code}
 make it working...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-77) New project types (support Database Projects?)


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

Brett Porter resolved NPANDAY-77.
-

Resolution: Cannot Reproduce
  Assignee: Brett Porter

The GUID 4F174C21-8C12-11D0-8340-F80270F8 is listed as an unsupported 
project type, and so is skipped in the current version.

 New project types (support Database Projects?)
 --

 Key: NPANDAY-77
 URL: https://issues.apache.org/jira/browse/NPANDAY-77
 Project: NPanday
  Issue Type: Bug
Reporter: cbown75
Assignee: Brett Porter
Priority: Minor
 Fix For: 1.5.0-incubating


 I am getting an error when I try and import a solution with a Database 
 project type.  It says The given key is not present in the dictionary.  A 
 better error would be nice, took me a while to figure out what that meant.
 Also I was wondering if it would be possible to say that the project, give 
 the name, is not supported and skip it and import the other projects.  
 In this example the DB project type should be skipped by nPanday as there is 
 nothing for it to compile.  MSBuild skips this project type when it compiles. 
  But if it would tell you that Project A is not supported by the importer, 
 but import Project B and C, then I could go and write the pom for Project A 
 by hand and modify the parent pom as needed as well.
 I think that would be a really flexible option.
 The GUID for the db project type is 4F174C21-8C12-11D0-8340-F80270F8.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-523) have WIX plugin use the new execution framework


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

Brett Porter resolved NPANDAY-523.
--

Resolution: Fixed
  Assignee: Brett Porter

Finally applied, great patch - thanks!

[~adrianboimvaser] are you still using and following NPanday?

 have WIX plugin use the new execution framework
 ---

 Key: NPANDAY-523
 URL: https://issues.apache.org/jira/browse/NPANDAY-523
 Project: NPanday
  Issue Type: Improvement
Affects Versions: 1.5.0-incubating
Reporter: Brett Porter
Assignee: Brett Porter
 Fix For: 1.5.0-incubating

 Attachments: NPANDAY-523.patch


 See comments from NPANDAY-510



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-599) Cache resolve-result reactor-wide to avoid pdb/gac/++ beeing resolved multiple times


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

Brett Porter resolved NPANDAY-599.
--

Resolution: Fixed

It was actually there already for both of these, but there was problems with 
the keys. Fixed in r1619665

 Cache resolve-result reactor-wide to avoid pdb/gac/++ beeing resolved 
 multiple times
 

 Key: NPANDAY-599
 URL: https://issues.apache.org/jira/browse/NPANDAY-599
 Project: NPanday
  Issue Type: Sub-task
  Components: Maven Plugins
Reporter: Lars Corneliussen
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 Currently it seems like our custom contributors/resolvers execute for every 
 possible path (artifact.getDependencyTrail() changes...).
 We can cache what we resolved reactor-wide in a separate component.
 Cachekey would be artifact.getId(), right?
 Should we let each contributor implement the cache 
 (ArtifactResolvingContributor) - or should it be generically handled in the 
 artifact resolver? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-402) Add support to automatically attach and resolve PDB-symbols


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

Brett Porter resolved NPANDAY-402.
--

Resolution: Fixed

Subtasks closed.

 Add support to automatically attach and resolve PDB-symbols
 ---

 Key: NPANDAY-402
 URL: https://issues.apache.org/jira/browse/NPANDAY-402
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Affects Versions: 1.4-incubating, 1.5.0-incubating
 Environment: $ mvn -v
 Apache Maven 2.2.1 (rdebian-4)
 Java version: 1.6.0_24
 Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux version: 2.6.35-28-generic arch: amd64 Family: unix
Reporter: John R. Fallows
Assignee: Lars Corneliussen
Priority: Critical
 Fix For: 1.5.0-incubating


 h2. ISSUES/TODO
 * -Integration tests missing-
 * -impl for attaching comments.xml missing- moved to NPANDAY-634
 * created subtasks (/)
 h2. Original Description
 The comments.xml file generated during CSharp compilation needs to be shipped 
 to developers for use in Visual Studio, similar to the javadoc artifact 
 produced by Maven for Java projects.
 This is not currently attached as an artifact during the NPanday build for 
 dotnet-library.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (NPANDAY-598) Problem: resolving PDBs in a reactor module makes them a dependency for subsequent modules


[ 
https://issues.apache.org/jira/browse/NPANDAY-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106489#comment-14106489
 ] 

Brett Porter edited comment on NPANDAY-598 at 8/22/14 5:37 AM:
---

Note: leaving this in place, but not sure it was the intended solution. Here's 
a comment from r1619669:

{quote}
This is probably not the ideal way to address this issue - it seems like
the cache are actually collectors that should be scoped to the
resolution request, and are storing instead of saving computation. The
resolve cache is safe as it is only used to intersect with the resolved
artifacts, but the dependency cache will grow as highlighted in this
issue. These could be adjusted in future as a listener, or a processor on
the resolved artifacts, or something passed in to the resolution request,
allowing these to become singleton objects again.
{quote}


was (Author: brettporter):
Note: leaving this in place, but not sure it was the intended solution. Here's 
a comment from r1619669:

{blockquote}
This is probably not the ideal way to address this issue - it seems like
the cache are actually collectors that should be scoped to the
resolution request, and are storing instead of saving computation. The
resolve cache is safe as it is only used to intersect with the resolved
artifacts, but the dependency cache will grow as highlighted in this
issue. These could be adjusted in future as a listener, or a processor on
the resolved artifacts, or something passed in to the resolution request,
allowing these to become singleton objects again.
{blockquote}

 Problem: resolving PDBs in a reactor module makes them a dependency for 
 subsequent modules
 --

 Key: NPANDAY-598
 URL: https://issues.apache.org/jira/browse/NPANDAY-598
 Project: NPanday
  Issue Type: Sub-task
  Components: Maven Plugins
Reporter: Lars Corneliussen
 Fix For: 1.5.0-incubating






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-629) Unable to build dist projects with Maven 3


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

Brett Porter updated NPANDAY-629:
-

Priority: Blocker  (was: Major)

 Unable to build dist projects with Maven 3
 --

 Key: NPANDAY-629
 URL: https://issues.apache.org/jira/browse/NPANDAY-629
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Priority: Blocker
 Fix For: 1.5.0-incubating


 A NullPointerException occurs in the assembly plugin - it seems that the 
 repository code in there has an incompatibility with Maven 3.
 Will need to look into an alternative, or a fix to the assembly plugin.
 This might cause problems for release at the moment because the site 
 publishing requires Maven 3 - that'll need to be further extracted to a 
 profile if we can't build the rest with Maven 3.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-558) Library importer requires nuget and manifest info on the path


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

Brett Porter updated NPANDAY-558:
-

Fix Version/s: (was: 1.5.0-incubating)

 Library importer requires nuget and manifest info on the path
 -

 Key: NPANDAY-558
 URL: https://issues.apache.org/jira/browse/NPANDAY-558
 Project: NPanday
  Issue Type: Bug
  Components: Library Importer
Affects Versions: 1.5.0-incubating
Reporter: Lars Corneliussen
  Labels: nuget, path

 They should be resolved from the repo instead - and be redeployed to npandays 
 3rdparty repository.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-485) Upgrade to newer NUnit version and deploy it somewhere


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

Brett Porter updated NPANDAY-485:
-

Fix Version/s: (was: 1.5.0-incubating)

 Upgrade to newer NUnit version and deploy it somewhere
 --

 Key: NPANDAY-485
 URL: https://issues.apache.org/jira/browse/NPANDAY-485
 Project: NPanday
  Issue Type: Improvement
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen

 NUnit 2.2.8 was build against .NET 2.0 Beta 1. When I use the reference to 
 that NUnit version (which probably nobody else does) i get theese errors:
 {code}
 C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9):
  warning MSB3258: The primary reference NUnit.Framework, Version=2.2.8.0, 
 Culture=neutral, processorArchitecture=MSIL could not be resolved because it 
 has an indirect dependency on the .NET Framework assembly mscorlib, 
 Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 which 
 has a higher version 2.0.3600.0 than the version 2.0.0.0 in the current 
 target framework.
 C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9):
  warning MSB3258: The primary reference NUnit.Framework, Version=2.2.8.0, 
 Culture=neutral, processorArchitecture=MSIL could not be resolved because it 
 has an indirect dependency on the .NET Framework assembly System, 
 Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 which 
 has a higher version 2.0.3600.0 than the version 2.0.0.0 in the current 
 target framework.
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-403) successful generation of poms after clicking on 'Cancel' button


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

Brett Porter updated NPANDAY-403:
-

Fix Version/s: (was: 1.5.0-incubating)

 successful generation of poms after clicking on 'Cancel' button
 ---

 Key: NPANDAY-403
 URL: https://issues.apache.org/jira/browse/NPANDAY-403
 Project: NPanday
  Issue Type: Bug
  Components: Project Importer
Affects Versions: 1.2.1
Reporter: Adelita L. Padilla
Priority: Minor

 Pom files were generated successfully even if 'Cancel' button was clicked.
 1) Start NPanday
 2) Open Project
 2) Right-click on project then select 'Generate Solution's POM Information...'
 3) Provide all needed information and click 'Generate Poms'
 4) In Project Unit Test window, click the 'Close' button on the upper right 
 side of the form
 5) Click on 'Cancel' button
 Result:POMs were successfully generated
 Actual Behavior: POMs were successfully generated.
 Expected Behavior: Import window should be closed and no POMs should be 
 generated



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Release 1.5.0 ??

2014-08-20 Thread Brett Porter

Thanks for the review and the nudge here Konstantin.

I've just dropped a couple out, and will take a quick pass over the 
non-blockers and ones assigned to me to see what else can be closed or bumped.

Do any others have a moment to look through them?

Thanks,
Brett

On 19 Aug 2014, at 7:37 am, Konstantin Boudnik c...@apache.org wrote:

 Ladies and gentlemen.
 
 I've pocked around a little bit and it seems that there are only 4 tickets (of
 which only 2 are real blockers) are effectively standing between today and the
 next release of the project. One of the critical is also an improvement.
 
Here's what I am referring to http://is.gd/WzgibS
 
 I am thinking if this would be a sane idea to deal with the blockers and push
 Major bugs into 1.6-incubating? This tactic will help to get the release out
 so the users have something new to work with. And it also will provide a new
 development baseline for the contributors?
 
 What do you guys think?
  Cos

[jira] [Resolved] (NPANDAY-483) Installation docs are outdated


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

Brett Porter resolved NPANDAY-483.
--

Resolution: Fixed

 Installation docs are outdated
 --

 Key: NPANDAY-483
 URL: https://issues.apache.org/jira/browse/NPANDAY-483
 Project: NPanday
  Issue Type: Bug
  Components: Reference and Documentations
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 The documentation on installing NPanday is VERY outdated. We should just 
 simply describe three ways:
 * For Windows Developers: Install both NPanday build system and NPanday 
 Visual Studio Add-in using the Windows Installer
 * For Build-Servers or Mono developers: 
   * Bulk download and install all artifacts at once to the local repository
   * Let Maven download from Maven Central
 * Install from source (including installing the add-in from source)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (NPANDAY-629) Unable to build dist projects with Maven 3


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

Brett Porter reassigned NPANDAY-629:


Assignee: Brett Porter

 Unable to build dist projects with Maven 3
 --

 Key: NPANDAY-629
 URL: https://issues.apache.org/jira/browse/NPANDAY-629
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Brett Porter
Priority: Blocker
 Fix For: 1.5.0-incubating


 A NullPointerException occurs in the assembly plugin - it seems that the 
 repository code in there has an incompatibility with Maven 3.
 Will need to look into an alternative, or a fix to the assembly plugin.
 This might cause problems for release at the moment because the site 
 publishing requires Maven 3 - that'll need to be further extracted to a 
 profile if we can't build the rest with Maven 3.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-629) Unable to build dist projects with Maven 3


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

Brett Porter resolved NPANDAY-629.
--

Resolution: Fixed

remove metadata to avoid issues

 Unable to build dist projects with Maven 3
 --

 Key: NPANDAY-629
 URL: https://issues.apache.org/jira/browse/NPANDAY-629
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Brett Porter
Priority: Blocker
 Fix For: 1.5.0-incubating


 A NullPointerException occurs in the assembly plugin - it seems that the 
 repository code in there has an incompatibility with Maven 3.
 Will need to look into an alternative, or a fix to the assembly plugin.
 This might cause problems for release at the moment because the site 
 publishing requires Maven 3 - that'll need to be further extracted to a 
 profile if we can't build the rest with Maven 3.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Reopened] (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:all-tabpanel
 ]

Brett Porter reopened NPANDAY-572:
--


confirmed this is still happening

 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] [Resolved] (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:all-tabpanel
 ]

Brett Porter resolved NPANDAY-572.
--

Resolution: Fixed

the problem is due to the namespaces (it worked if none was declared on the 
settings file). Corrected.

 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] [Resolved] (NPANDAY-573) remove maven-vsinstaller-plugin


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

Brett Porter resolved NPANDAY-573.
--

Resolution: Fixed
  Assignee: Brett Porter

 remove maven-vsinstaller-plugin
 ---

 Key: NPANDAY-573
 URL: https://issues.apache.org/jira/browse/NPANDAY-573
 Project: NPanday
  Issue Type: Task
Reporter: Brett Porter
Assignee: Brett Porter
Priority: Blocker
 Fix For: 1.5.0-incubating


 NPANDAY-231 has broken the vsinstaller plugin. Rather than fix it, we should 
 push our effort towards using the MSI instead.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-543) Resync References doesn´t update dependencies from remote repositories with LDAP verification


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

Brett Porter updated NPANDAY-543:
-

Fix Version/s: (was: 1.5.0-incubating)

 Resync References doesn´t update dependencies from remote repositories with 
 LDAP verification
 -

 Key: NPANDAY-543
 URL: https://issues.apache.org/jira/browse/NPANDAY-543
 Project: NPanday
  Issue Type: Bug
  Components: Visual Studio Add-in
Affects Versions: 1.4-incubating
 Environment: Archiva 1.3.5.,
 NPanday 1.4-incubating,
 Visual studion 2010
 Maven 3.0.3
Reporter: Jiri Pergl
Assignee: Brett Porter
Priority: Blocker

 Steps:
 1. Add references using Add Maven Artifact from the menu(VS) or direct in 
 the project pom.
 2. Update the configuration in the settings.xml.
- I insert to the configuration in the setting.xml this snippet:
 ... 
 server
   idnpanday.repo.0/id
   username{LDAP user name}/username
   password{encrypted password}/password
  /server
 ...
 3. Refresh references using Resync References from the menu(VS).
 After action I see message Download Failed The remote server returned an 
 error: (401) Unauthorized. 
 I found out that Archiva is contacted without LDAP parameters in the 
 communication between Archiva and local machine. If I try the goal deploy 
 on the simple project, the communication is ok.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (NPANDAY-543) Resync References doesn´t update dependencies from remote repositories with LDAP verification

[
https://issues.apache.org/jira/browse/NPANDAY-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105079#comment-14105079
]

Brett Porter commented on NPANDAY-543:
--

Sorry, this isn't yet supported. While a user/pass is prompted in the add maven
artifact dialog, it is not stored in the servers section automatically, and
that section is not used by the resync code to set the credentials when
synchronising.

Those changes might be straightforward, but supporting the encrypted plugins
may be more difficult as it would need to emulate the same logic as Maven
itself.

Resync References doesn´t update dependencies from remote repositories with
LDAP verification
-

Key: NPANDAY-543
URL: https://issues.apache.org/jira/browse/NPANDAY-543
Project: NPanday
Issue Type: Bug
Components: Visual Studio Add-in
Affects Versions: 1.4-incubating
Environment: Archiva 1.3.5.,
NPanday 1.4-incubating,
Visual studion 2010
Maven 3.0.3
Reporter: Jiri Pergl
Assignee: Brett Porter
Priority: Blocker

Steps:
1. Add references using Add Maven Artifact from the menu(VS) or direct in
the project pom.
2. Update the configuration in the settings.xml.
- I insert to the configuration in the setting.xml this snippet:
...
server
idnpanday.repo.0/id
username{LDAP user name}/username
password{encrypted password}/password
/server
...
3. Refresh references using Resync References from the menu(VS).
After action I see message Download Failed The remote server returned an
error: (401) Unauthorized.
I found out that Archiva is contacted without LDAP parameters in the
communication between Archiva and local machine. If I try the goal deploy
on the simple project, the communication is ok.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (NPANDAY-393) NPanday ITs still need ildasm (or disasm for Mono) to be on the PATH

2014-08-04 Thread Brett Porter (JIRA)


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

Brett Porter closed NPANDAY-393.


   Resolution: Fixed
Fix Version/s: (was: Backlog)
   1.5.0-incubating
 Assignee: Brett Porter

Addressed in r1609664

 NPanday ITs still need ildasm (or disasm for Mono) to be on the PATH
 

 Key: NPANDAY-393
 URL: https://issues.apache.org/jira/browse/NPANDAY-393
 Project: NPanday
  Issue Type: Improvement
  Components: Integration Tests
Reporter: Lars Corneliussen
Assignee: Brett Porter
  Labels: integration-tests
 Fix For: 1.5.0-incubating


 As NPanday doesn't need the PATH environment setup anymore, it would be 
 great, if the ITs ran without that, too. Instead some ITs expect ildasm or 
 disasm to be available in the executing command line environment.
 Workaround: Run ITs in the SDK or Visual Studio Prompt.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Draft August report

2014-08-03 Thread Brett Porter

Thoughts?

--

NPanday allows projects using the .NET framework to be built with Apache
Maven.

NPanday has been incubating since 2010-08-13.

Since the last report in July:
 - the build issues on the Windows Jenkins slaves were resolved
 - further JIRA issues have been cleaned up to prepare for the release
 - Konstantin Boudnik was formally added as a mentor for the project

While some progress was made towards getting the release out, there is still 
more work to do as time allows.

Three most important issues to address in the move towards graduation:

  1. Ship the changes on trunk as a release and make it easier for new users to 
get up to speed when interested in the project
  2. Get a critical mass of committers/PPMC members that can respond to 
contributors, apply patches, nominate committers, and vote on releases
  3. Provide guidance on how to get involved in contributing

The incubator is already aware of the low level of activity, that many of the 
PPMC are now disengaged. There continues to be interest in a new release from 
users, and new
interest from some in making contributions that continue to be followed up.

Date of last release:

  2011-05-16

The last committer was added on 2011-04-19. There have not been any PPMC 
additions since inception.

Signed-off-by:

  [ ](npanday) Raphael Bircher
  [ ](npanday) Konstantin Boudnik

Shepherd/Mentor notes:

Re: help!

2014-07-25 Thread Brett Porter

Hi Joseph,

Glad to hear you're trying out NPanday. I'm not exactly sure of the easiest way 
to connect the debugger to the plugin runner, though those are infrequently 
used with the latest code.

Is there a specific problem you're having with one of those plugins that you're 
trying to fix?

Regards,
Brett

On 24 Jul 2014, at 4:40 pm, 谢柳平 xlp875645...@163.com wrote:

 hi，dear  brett porter 
   I am joseph xie ,now i am interested in npanday ,so i download this program 
 ,I can debug add-in plugin and maven plugin,but I can not debug 
 vs-project,such as NPanday.Plugin project ,I have attempted to debug it by 
 attach process to vs ,but it not work.now I really want to know how 
 NPanday.Plugin.Runner 、 NPanday.Plugin.Loader and NPanday.Plugin runs 
 .I know you are very familiar with npanday,so  please help me .
 I am waitting for you online.If you have others contact ways ,please tell me.
 
 Best regards,
 Joseph xie

Re: [jira] [Comment Edited] (NPANDAY-525) Make sure UnifiedShellCommandExecutor works with BourneShell

2014-07-15 Thread Brett Porter

Thanks David - I've also responded on the JIRA ticket.

Do you have any thoughts on how to correct this?

- Brett

On 15 Jul 2014, at 4:23 am, David Akehurst d...@akehurst.net wrote:

 I have just tried to do a build on linux, the output is attached.
 
 it doesn't build for me.
 
 
 On 14 July 2014 03:47, Brett Porter (JIRA) j...@apache.org wrote:
 
 [ 
 https://issues.apache.org/jira/browse/NPANDAY-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14060269#comment-14060269
  ]
 
 Brett Porter edited comment on NPANDAY-525 at 7/14/14 1:45 AM:
 ---
 
 Any progress David?
 
 These are what I've found so far:
 - some failures occur because the tests check the output of an echo 
 command, however echo's handling of quotes is different on Mac, Linux and 
 Windows, so you can't have just one assertion. Either need to adjust the 
 assertions per OS, or use a different command than echo that can equally test 
 quoting
 - the tests seem to want to run {{/bin/sh -c echo ...}}, where it should be 
 {{/bin/sh -c echo ...}}, which would be a problem in the executor
 
 
 was (Author: brettporter):
 Any progress David?
 
 These are what I've found so far:
 - some failures occur because the tests check the output of an echo 
 command, however echo's handling of quotes is different on Mac, Linux and 
 Windows, so you can't have just one assertion. Either need to adjust the 
 assertions per OS, or use a different command than echo that can equally test 
 quoting
 - the tests seem to want to run {{/bin/sh -c echo ...}}, where it should be 
 /bin/sh -c echo ..., which would be a problem in the executor
 
  Make sure UnifiedShellCommandExecutor works with BourneShell
  
 
  Key: NPANDAY-525
  URL: https://issues.apache.org/jira/browse/NPANDAY-525
  Project: NPanday
   Issue Type: Improvement
   Components: Maven Plugins
 Reporter: Lars Corneliussen
  Fix For: 1.5.0-incubating
 
 
  As Part of NPANDAY-509 the execution engine for executing shell commands 
  was replaced. We have to make sure, that quoting++ still works as expected 
  on !Windows.
 
 
 
 --
 This message was sent by Atlassian JIRA
 (v6.2#6252)
 
 out.txt

[jira] [Commented] (NPANDAY-525) Make sure UnifiedShellCommandExecutor works with BourneShell

2014-07-15 Thread Brett Porter (JIRA)


[ 
https://issues.apache.org/jira/browse/NPANDAY-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14062067#comment-14062067
 ] 

Brett Porter commented on NPANDAY-525:
--

Thanks [~dhakehurst] - that's the same results I got (the failures are the 
first bullet in my comment, the errors are the second bullet). I haven't got 
any further at fixing that, though - and unfortunately the patch on NPANDAY-611 
didn't address the issue.

 Make sure UnifiedShellCommandExecutor works with BourneShell
 

 Key: NPANDAY-525
 URL: https://issues.apache.org/jira/browse/NPANDAY-525
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Reporter: Lars Corneliussen
 Fix For: 1.5.0-incubating

 Attachments: out.txt


 As Part of NPANDAY-509 the execution engine for executing shell commands was 
 replaced. We have to make sure, that quoting++ still works as expected on 
 !Windows.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (NPANDAY-525) Make sure UnifiedShellCommandExecutor works with BourneShell


[ 
https://issues.apache.org/jira/browse/NPANDAY-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14060269#comment-14060269
 ] 

Brett Porter edited comment on NPANDAY-525 at 7/14/14 1:45 AM:
---

Any progress David?

These are what I've found so far:
- some failures occur because the tests check the output of an echo command, 
however echo's handling of quotes is different on Mac, Linux and Windows, so 
you can't have just one assertion. Either need to adjust the assertions per OS, 
or use a different command than echo that can equally test quoting
- the tests seem to want to run {{/bin/sh -c echo ...}}, where it should be 
{{/bin/sh -c echo ...}}, which would be a problem in the executor


was (Author: brettporter):
Any progress David?

These are what I've found so far:
- some failures occur because the tests check the output of an echo command, 
however echo's handling of quotes is different on Mac, Linux and Windows, so 
you can't have just one assertion. Either need to adjust the assertions per OS, 
or use a different command than echo that can equally test quoting
- the tests seem to want to run {{/bin/sh -c echo ...}}, where it should be 
/bin/sh -c echo ..., which would be a problem in the executor

 Make sure UnifiedShellCommandExecutor works with BourneShell
 

 Key: NPANDAY-525
 URL: https://issues.apache.org/jira/browse/NPANDAY-525
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Reporter: Lars Corneliussen
 Fix For: 1.5.0-incubating


 As Part of NPANDAY-509 the execution engine for executing shell commands was 
 replaced. We have to make sure, that quoting++ still works as expected on 
 !Windows.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (NPANDAY-611) Linux build of plugins broken by \ in tests


[ 
https://issues.apache.org/jira/browse/NPANDAY-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915584#comment-13915584
 ] 

Brett Porter edited comment on NPANDAY-611 at 7/14/14 1:53 AM:
---

{code}
Index: 
components/dotnet-executable/src/test/groovy/npanday/executable/execution/CommandExecutorTest.groovy
===
--- 
components/dotnet-executable/src/test/groovy/npanday/executable/execution/CommandExecutorTest.groovy
(revision 1572887)
+++ 
components/dotnet-executable/src/test/groovy/npanday/executable/execution/CommandExecutorTest.groovy
(working copy)
@@ -89,14 +89,14 @@
 public void testCommandArgWithSpaces()
 throws ExecutionException
 {
-testArgExpansion([a b], 'a b\');
+testArgExpansion([a b], 'a b');
 }
 
 @Test
 public void testCommandArgWithEmbeddedSingleQuotes_middle()
 throws ExecutionException
 {
-testArgExpansion([a ' b], 'a \' b');
+testArgExpansion([a ' b], 'a ' b');
 }
 
 @Test
@@ -417,4 +417,4 @@
 {
return Os.isFamily(Os.FAMILY_WINDOWS);
 }
-}
\ No newline at end of file
+}
{code}


was (Author: dhakehurst):
Index: 
components/dotnet-executable/src/test/groovy/npanday/executable/execution/CommandExecutorTest.groovy
===
--- 
components/dotnet-executable/src/test/groovy/npanday/executable/execution/CommandExecutorTest.groovy
(revision 1572887)
+++ 
components/dotnet-executable/src/test/groovy/npanday/executable/execution/CommandExecutorTest.groovy
(working copy)
@@ -89,14 +89,14 @@
 public void testCommandArgWithSpaces()
 throws ExecutionException
 {
-testArgExpansion([a b], 'a b\');
+testArgExpansion([a b], 'a b');
 }
 
 @Test
 public void testCommandArgWithEmbeddedSingleQuotes_middle()
 throws ExecutionException
 {
-testArgExpansion([a ' b], 'a \' b');
+testArgExpansion([a ' b], 'a ' b');
 }
 
 @Test
@@ -417,4 +417,4 @@
 {
return Os.isFamily(Os.FAMILY_WINDOWS);
 }
-}
\ No newline at end of file
+}


 Linux build of plugins broken by \ in tests
 ---

 Key: NPANDAY-611
 URL: https://issues.apache.org/jira/browse/NPANDAY-611
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: David Akehurst
 Fix For: 1.5.0-incubating


 Building the maven plugins on linux breaks when compiling the tests because 
 of a few backslashes in the tests.
 not been able to test this on windows, but the attached comment of svn diff 
 fixes it for linux.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (NPANDAY-611) Linux build of plugins broken by \ in tests


[ 
https://issues.apache.org/jira/browse/NPANDAY-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14060278#comment-14060278
 ] 

Brett Porter commented on NPANDAY-611:
--

This patch doesn't work when I apply it, as the middle single quote terminates 
the string too early on the second change. The first line change didn't have 
any impact on the result, as it just removed a superfluous escaping of the 
double quotes. I've added more comments about that on NPANDAY-525. Closing this 
one as a duplicate - please drop a comment over there if you've moved further 
on it!

 Linux build of plugins broken by \ in tests
 ---

 Key: NPANDAY-611
 URL: https://issues.apache.org/jira/browse/NPANDAY-611
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: David Akehurst
 Fix For: 1.5.0-incubating


 Building the maven plugins on linux breaks when compiling the tests because 
 of a few backslashes in the tests.
 not been able to test this on windows, but the attached comment of svn diff 
 fixes it for linux.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-611) Linux build of plugins broken by \ in tests


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

Brett Porter resolved NPANDAY-611.
--

Resolution: Duplicate
  Assignee: Brett Porter

 Linux build of plugins broken by \ in tests
 ---

 Key: NPANDAY-611
 URL: https://issues.apache.org/jira/browse/NPANDAY-611
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: David Akehurst
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 Building the maven plugins on linux breaks when compiling the tests because 
 of a few backslashes in the tests.
 not been able to test this on windows, but the attached comment of svn diff 
 fixes it for linux.



--
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=14060280#comment-14060280
 ] 

Brett Porter commented on NPANDAY-624:
--

{quote}
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)
{quote}

Initially they weren't, but more recent additions like the {{wix-maven-plugin}} 
and others do use the invoker. You can add ITs to the plugin and they'll be 
automatically run with {{-Prun-its}} on. There are no tests for ilmerge in 
either place unfortunately, so just go with your instinct on what is right with 
the merge rules.

{quote}
- /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
{quote}

I think {{.references}} is specific to addin and hint paths placed in the 
solution files - it might not always have the dependencies you want, especially 
on a clean build. Other plugins typically copy the required dependencies into 
the target directory as part of the process so that they have unmangled names - 
for example the test plugin does this: 
https://github.com/apache/npanday/blob/trunk/plugins/maven-test-plugin/src/main/java/npanday/plugin/test/TesterMojo.java#L267

{quote}
- 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)
{quote}

Sorry, not familiar enough with the plugin to know the answers here. [~ejit], 
any chance you could help Greg out here from memory?



 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

[jira] [Commented] (NPANDAY-631) Something seems to be adding additional repo's partway through build?


[ 
https://issues.apache.org/jira/browse/NPANDAY-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14060281#comment-14060281
 ] 

Brett Porter commented on NPANDAY-631:
--

{{apache.snapshots}} comes from the Apache parent POM, {{npanday.snapshots}} 
from the NPanday top-most POM. These are used by the plugins, as well as to 
resolve plugins.

It's not clear why you would have got these inconsistently, or if there's 
anything wrong on NPanday here - just seems like more motivation to get a newer 
stable release out - do you agree?

 Something seems to be adding additional repo's partway through build?
 -

 Key: NPANDAY-631
 URL: https://issues.apache.org/jira/browse/NPANDAY-631
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Greg Domjan
Priority: Minor
  Labels: newbie

 Perhaps a newbie question, but this was confusing this morning when our build 
 started failing with no idea of external inputs.
 I have been able to resolve this by rebuilding our local from source to bring 
 our local nexus up to date.
 It seems we may need to Add npanday.snapshots and apach.snapshots to our 
 nexus to proxy, however I can't find where apache.snapshots is defined so far.
 We have these 2 repo's defined that appear like 
  {code} 
 [INFO] snapshot org.apache.npanday:apache-npanday:1.5.0-incubating-SNAPSHOT: 
 checking for updates from nsl.nexus
 [INFO] snapshot org.apache.npanday:apache-npanday:1.5.0-incubating-SNAPSHOT: 
 checking for updates from public
  {code} 
 Partway through artifact resolution 2 more 'appear'
  {code} 
 [INFO] snapshot org.apache.npanday:dotnet-registry:1.5.0-incubating-SNAPSHOT: 
 checking for updates from nsl.nexus
 [INFO] snapshot org.apache.npanday:dotnet-registry:1.5.0-incubating-SNAPSHOT: 
 checking for updates from public
 [INFO] snapshot org.apache.npanday:dotnet-registry:1.5.0-incubating-SNAPSHOT: 
 checking for updates from npanday.snapshots
 [INFO] snapshot org.apache.npanday:dotnet-registry:1.5.0-incubating-SNAPSHOT: 
 checking for updates from apache.snapshots
  {code} 
 With recent changes overnight our build started failing and the only thing I 
 could find is that the following cause some external updates to be applied 
 inconsitently.
 [INFO] [compile:initialize {execution: default-initialize}]
 [INFO] NPANDAY-148-009: Took 18ms to resolve dependencies for 
 com.netIQ.IAM.SecureLogin:netWizardModel:dotnet-library:8.1.0-0-SNAPSHOT with
 filter org.apache.maven.artifact.resolver.filter.AndArtifactFilter@4b28899a
 [FATAL ERROR] npanday.plugin.compile.ComponentInitializerMojo#execute() 
 caused a linkage error (java.lang.NoSuchMethodError) and may be out-
 of-date. Check the realms:
 [FATAL ERROR] Plugin realm = 
 app0.child-container[org.apache.npanday.plugins:maven-compile-plugin:1.5.0-incubating-SNAPSHOT]
 urls[0] = 
 file:/e:/data/.m2/repository/org/apache/npanday/plugins/maven-compile-plugin/1.5.0-incubating-SNAPSHOT/maven-compile-plugin-1.5.0-
 incubating-SNAPSHOT.jar
 urls[1] = 
 file:/e:/data/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.jar
 urls[2] = 
 file:/e:/data/.m2/repository/org/apache/npanday/dotnet-registry/1.5.0-incubating-SNAPSHOT/dotnet-registry-1.5.0-incubating-SNAPSHOT.jar
 ...
 urls[37] = 
 file:/e:/data/.m2/repository/org/apache/npanday/dotnet-model-configuration-appenders/1.5.0-incubating-SNAPSHOT/dotnet-model-confi
 guration-appenders-1.5.0-incubating-SNAPSHOT.jar
 [FATAL ERROR] Container realm = plexus.core
 urls[0] = file:/E:/Data/Devtool/apache-maven-2.2.1/lib/maven-2.2.1-uber.jar
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] 
 npanday.assembler.AssemblerContext.init(Lorg/apache/maven/project/MavenProject;)V
 [INFO] 
 
 [INFO] Trace
 java.lang.NoSuchMethodError: 
 npanday.assembler.AssemblerContext.init(Lorg/apache/maven/project/MavenProject;)V
 at 
 npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:100)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
  {code} 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (NPANDAY-632) NPE when using netHome maven configuration


[ 
https://issues.apache.org/jira/browse/NPANDAY-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14060293#comment-14060293
 ] 

Brett Porter commented on NPANDAY-632:
--

Good catch! Applied. For future patches, a couple of things you can do to 
assist:
- take the patch from the root of the project, rather than in a submodule
- attach to the issue as a file that can be saved

An alternative is to send us a pull request against the Apache mirror of the 
project's SVN repository.

 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
 Fix For: 1.5.0-incubating


 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] [Resolved] (NPANDAY-632) NPE when using netHome maven configuration


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

Brett Porter resolved NPANDAY-632.
--

   Resolution: Fixed
Fix Version/s: 1.5.0-incubating
 Assignee: Brett Porter

 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
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 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] [Updated] (NPANDAY-600) When running list-dependencies on a pom, no pdbs are resolved (from dll dependencies)

2014-07-12 Thread Brett Porter (JIRA)


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

Brett Porter updated NPANDAY-600:
-

Fix Version/s: (was: 1.5.0-incubating)
   Backlog

 When running list-dependencies on a pom, no pdbs are resolved (from dll 
 dependencies)
 -

 Key: NPANDAY-600
 URL: https://issues.apache.org/jira/browse/NPANDAY-600
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Reporter: Lars Corneliussen
 Fix For: Backlog






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-596) Error: When running require the first time, PDBs will not be part of the result (ListDependenciesMojo)

2014-07-12 Thread Brett Porter (JIRA)


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

Brett Porter updated NPANDAY-596:
-

Issue Type: Bug  (was: Sub-task)
Parent: (was: NPANDAY-402)

 Error: When running require the first time, PDBs will not be part of the 
 result (ListDependenciesMojo)
 --

 Key: NPANDAY-596
 URL: https://issues.apache.org/jira/browse/NPANDAY-596
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Reporter: Lars Corneliussen
 Fix For: Backlog






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-600) When running list-dependencies on a pom, no pdbs are resolved (from dll dependencies)

2014-07-12 Thread Brett Porter (JIRA)


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

Brett Porter updated NPANDAY-600:
-

Issue Type: Bug  (was: Sub-task)
Parent: (was: NPANDAY-402)

 When running list-dependencies on a pom, no pdbs are resolved (from dll 
 dependencies)
 -

 Key: NPANDAY-600
 URL: https://issues.apache.org/jira/browse/NPANDAY-600
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Reporter: Lars Corneliussen
 Fix For: Backlog






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-630) Some integration tests fail when run with Maven 3

2014-07-11 Thread Brett Porter (JIRA)


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

Brett Porter resolved NPANDAY-630.
--

Resolution: Fixed

Both fixed:
- 329 by removing a duplicate lifecycle that was incorrect, but never picked up 
in Maven 2
- 0028 by skipping under Maven 3

The above comment was unrelated.

 Some integration tests fail when run with Maven 3
 -

 Key: NPANDAY-630
 URL: https://issues.apache.org/jira/browse/NPANDAY-630
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 There are two tests that still fail when run with Maven 3, but not with Maven 
 2:
 - NPANDAY-329 (seems the bin directory is not generated as expected - may be 
 a bug in NPanday when run under Maven 3)
 - IT0028 (lack of support for non-unique snapshots - should be disabled under 
 Maven 3).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-567) Copy along app.config (and transform with app.test.config) for test runs

2014-07-10 Thread Brett Porter (JIRA)


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

Brett Porter resolved NPANDAY-567.
--

Resolution: Fixed

Closing out with what's in place then, new tickets for taking it further.

 Copy along app.config (and transform with app.test.config) for test runs
 

 Key: NPANDAY-567
 URL: https://issues.apache.org/jira/browse/NPANDAY-567
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Reporter: Lars Corneliussen
Assignee: Lars Corneliussen
 Fix For: 1.5.0-incubating


 Currently there is no way to configure tests...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (NPANDAY-622) NPE - compile:testCompile

2014-07-09 Thread Brett Porter (JIRA)


[ 
https://issues.apache.org/jira/browse/NPANDAY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055950#comment-14055950
 ] 

Brett Porter commented on NPANDAY-622:
--

I started seeing this in the integration tests today after making a few other 
changes to the way metadata is generated, and found it was easy to remove the 
initialization step for this code. I'll push that shortly.

You might still need the initialize method to ensure that dependencies are 
resolved, but that can probably also be removed in the future.

 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

[jira] [Commented] (NPANDAY-618) Plugin for execution of tlbimp.exe from windows platform sdk

2014-07-09 Thread Brett Porter (JIRA)


[ 
https://issues.apache.org/jira/browse/NPANDAY-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055951#comment-14055951
 ] 

Brett Porter commented on NPANDAY-618:
--

The COM reference resolver now uses the executable framework to run tlbimp, so 
that could more feasibly be extracted into a reusable class that would also be 
the basis for such a plugin.

 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] [Updated] (NPANDAY-618) Plugin for execution of tlbimp.exe from windows platform sdk

2014-07-09 Thread Brett Porter (JIRA)


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

Brett Porter updated NPANDAY-618:
-

Fix Version/s: Backlog

 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
 Fix For: Backlog


 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] [Resolved] (NPANDAY-505) Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)


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

Brett Porter resolved NPANDAY-505.
--

Resolution: Fixed

 Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)
 -

 Key: NPANDAY-505
 URL: https://issues.apache.org/jira/browse/NPANDAY-505
 Project: NPanday
  Issue Type: Improvement
  Components: Development Setup, Maven Plugins
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 Currently NPanday sometimes generates a {{npanday-settings.xml}}-file; 
 preferably in {{~/.m2}}. Currently this is done by 
 NPanday.Plugin.Settings:generate-settings. The problem is, that the file is 
 needed to compile the plugin that generates it. That makes it hard to 
 bootstrap without a path.
 h2. New Approach
 We create a master superset configuration {{npanday-settings.xml}} (or 
 better {{supported-vendors.xml}}?? that contains all frameworks and vendors 
 NPanday supports. Then based on various rules, NPanday checks which 
 combinations of vendor, vendorVersion and frameworkVersion(s) are available 
 on the current platform (registry and path lookup, as currently done in 
 generate-settings).
 h2. Example
 Currently this code:
 {code:title=plugins\netplugins\NPanday.Plugin.Settings\src\main\csharp\DotnetSdkLocator.cs}
 ..
 RegistryKey Microsoft_NETFramework = 
 Registry.LocalMachine.OpenSubKey(@SOFTWARE\Microsoft\.NETFramework);
 RegistryKey Microsoft_SDKs_NETFramework = 
 Registry.LocalMachine.OpenSubKey(@SOFTWARE\Microsoft\SDKs\.NETFramework);
 ..
 return PathUtil.FirstExisting(
 registryFind(Microsoft_NETFramework, sdkInstallRootv2.0),
 registryFind(Microsoft_SDKs_NETFramework, v2.0, 
 InstallationFolder),
 ProgramFilesX86(@Microsoft.NET\SDK\v2.0),
 ProgramFilesX86(@Microsoft.NET\SDK\v2.0 64bit),
 ProgramFilesX86(@Microsoft SDKs\Windows\v6.0A\bin),
 ProgramFiles(@Microsoft SDKs\Windows\v6.0A\bin)
 );
 {code}
 Generates this:
 {code:title=~\.m2\npanday-settings.xml}
 ...
 vendor
   vendorNameMICROSOFT/vendorName
   vendorVersion3.0/vendorVersion
   frameworks
 framework
   frameworkVersion3.0/frameworkVersion
   installRootC:\Windows\Microsoft.NET\Framework64\v3.0/installRoot
   sdkInstallRootC:\Program Files\Microsoft.NET\SDK\v2.0 
 64bit\/sdkInstallRoot
   executablePaths
 
 executablePathC:\Windows\Microsoft.NET\Framework64\v2.0.50727/executablePath
 executablePathC:\Program Files\Microsoft.NET\SDK\v2.0 
 64bit\bin/executablePath
   /executablePaths
 /framework
   /frameworks
 /vendor
 ...
 {code}
 {code:title=components\dotnet-core\src\main\resources\META-INF\npanday\npanday-settings.xml}
 ...
   vendors
 ...
 vendor
   vendorNameMICROSOFT/vendorName
   vendorVersion3.0/vendorVersion
   frameworks
 framework
   !-- new !! --
   frameworkArchitectureAMD64/frameworkArchitecture  
   frameworkVersion3.0/frameworkVersion
   
   !-- registry (Software\Microsoft\.NETFrameworkd@InstallPath) 
 allways finds Framework64 on 64bit windows; hence path is better --
   
 installRoot${env.WINDIR}\Microsoft.NET\Framework64\v3.0/installRoot
   
   !-- first one wins --
   sdkInstallRootProbingPaths
 
 sdkInstallRootProbingPath${HKLM\Software\Microsoft\.NETFramework@sdkInstallRootv2.0}/sdkInstallRootProbingPath
 sdkInstallRootProbingPath${HKLM\SOFTWARE\Microsoft\Microsoft 
 SDKs\.NETFramework\v2.0@InstallationFolder}/sdkInstallRootProbingPath
 
 sdkInstallRootProbingPath${env.ProgramFiles}\Microsoft.NET\SDK\v2.0/sdkInstallRootProbingPath
 sdkInstallRootProbingPath${env.ProgramFiles}\Microsoft 
 SDKs\Windows\v6.0A\bin/sdkInstallRootProbingPath
 sdkInstallRootProbingPath${env.ProgramFilesX86}(@Microsoft 
 SDKs\Windows\v6.0A\bin}/sdkInstallRootProbingPath
   /sdkInstallRootProbingPaths
   executableProbingPaths
 !-- 3.0 doesn't come with new tools --
 
 executableProbingPath${env.WINDIR}\Microsoft.NET\Framework64\v2.0.50727/executablePath
 
 !-- we could by default add installRoot and sdkInstallRoot(+bin) 
 --
 !-- executableProbingPathC:\Program 
 Files\Microsoft.NET\SDK\v2.0 64bit\bin/executablePath --
   /executableProbingPaths
 /framework
   /frameworks
 /vendor
 ...
   /vendors
 ...
 {code}
 Both registry access with ${HKLM*}, ${HKCU*}, ${HKEY_LOCAL_MACHINE*}, 
 ${HKEY_CURRENT_USER

Optional npanday-settings.xml

2014-07-08 Thread Brett Porter

Hi,

I'd found that the settings generator was not picking up all of the newer 
configuration, meaning that I'd again had to have the PATH set to build on my 
VM, and the same problem was on Jenkins. Rather than add more configuration, I 
went ahead with NPANDAY-505 and made NPanday work without the 
npanday-settings.xml file. There are more details in the ticket.

Could others give this a try in their environment and see if it exposes any 
problems based on the VS/SDK versions you have installed?

Do the changes make sense?

Cheers,
Brett

Jenkins is passing again

2014-07-08 Thread Brett Porter

Hi,

Sorry for the list noise as issues were worked through, but the Jenkins builds 
are now passing again. I've had to peg it to windows1 until some software can 
be installed on the other node.

We should be better equipped to keep it that way, but feel free to ping me if 
you get a failure after committing and aren't sure why.

- Brett

[jira] [Assigned] (NPANDAY-483) Installation docs are outdated


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

Brett Porter reassigned NPANDAY-483:


Assignee: Brett Porter

 Installation docs are outdated
 --

 Key: NPANDAY-483
 URL: https://issues.apache.org/jira/browse/NPANDAY-483
 Project: NPanday
  Issue Type: Bug
  Components: Reference and Documentations
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 The documentation on installing NPanday is VERY outdated. We should just 
 simply describe three ways:
 * For Windows Developers: Install both NPanday build system and NPanday 
 Visual Studio Add-in using the Windows Installer
 * For Build-Servers or Mono developers: 
   * Bulk download and install all artifacts at once to the local repository
   * Let Maven download from Maven Central
 * Install from source (including installing the add-in from source)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-562) [possible regression to NPANDAY-231] Resolving gac and system assemblies has to be revisited


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

Brett Porter resolved NPANDAY-562.
--

Resolution: Cannot Reproduce
  Assignee: Brett Porter

I don't see any problems with system scope dependencies in current tests. I 
think the fact that it's using Maven's built in resolution now is probably 
taking care of it.

 [possible regression to NPANDAY-231] Resolving gac and system assemblies has 
 to be revisited
 

 Key: NPANDAY-562
 URL: https://issues.apache.org/jira/browse/NPANDAY-562
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Lars Corneliussen
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 I'm not sure how important that code is.
 {code}
  // resolve system scope dependencies
 if ( projectDependency.getScope() != null  
 projectDependency.getScope().equals( system ) )
 {
 if ( projectDependency.getSystemPath() == null )
 {
 throw new ProjectDaoException( systemPath required 
 for System Scoped dependencies  + in Group ID = 
 + projectDependency.getGroupId() + , Artiract ID 
 =  + projectDependency.getArtifactId() );
 }
 File f = new File( projectDependency.getSystemPath() );
 if ( !f.exists() )
 {
 throw new IOException( Dependency systemPath File 
 not found:
 + projectDependency.getSystemPath() + in Group 
 ID =  + projectDependency.getGroupId()
 + , Artiract ID =  + 
 projectDependency.getArtifactId() );
 }
 assembly.setFile( f );
 assembly.setResolved( true );
 artifactDependencies.add( assembly );
 projectDependency.setResolved( true );
 logger.finer( NPANDAY-180-011.1: Project Dependency 
 Resolved: Artifact ID = 
 + projectDependency.getArtifactId() + , Group ID =  
 + projectDependency.getGroupId()
 + , Version =  + projectDependency.getVersion() + 
 , Scope =  + projectDependency.getScope()
 + SystemPath =  + projectDependency.getSystemPath()
 );
 continue;
 }
 {code}
 This does more then the current new GacResolver:
 {code}  
 // resolve gac references
 // note: the old behavior of gac references, used to have 
 system path properties in the pom of the
 // project
 // now we need to generate the system path of the gac 
 references so we can use
 // System.getenv(SystemRoot)
 //we have already set file for the assembly above (in 
 createArtifactFrom) so we do not need re-resovle it
 if ( !projectDependency.isResolved() )
 {
 if ( ArtifactTypeHelper.isDotnetAnyGac( 
 projectDependency.getArtifactType() ) )
 {
 try
 {
 if (assembly.getFile().exists())
 {
 projectDependency.setSystemPath( 
 assembly.getFile().getAbsolutePath());
 projectDependency.setResolved( true );
 assembly.setResolved( true );
 }
 artifactDependencies.add( assembly );
 }
 catch ( ExceptionInInitializerError e )
 {
 logger.warning( NPANDAY-180-516.82: Project 
 Failed to Resolve Dependency: Artifact ID = 
 + projectDependency.getArtifactId() + , 
 Group ID =  + projectDependency.getGroupId()
 + , Version =  + 
 projectDependency.getVersion() + , Scope = 
 + projectDependency.getScope() + SystemPath 
 =  + projectDependency.getSystemPath() );
 }
 }
 else
 {
 try
 {
 // re-resolve snapshots
 if ( !assembly.isSnapshot() )
 {
 Project dep =
 this.getProjectFor( 
 projectDependency.getGroupId(), projectDependency.getArtifactId

[jira] [Commented] (NPANDAY-599) Cache resolve-result reactor-wide to avoid pdb/gac/++ beeing resolved multiple times


[ 
https://issues.apache.org/jira/browse/NPANDAY-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055757#comment-14055757
 ] 

Brett Porter commented on NPANDAY-599:
--

In my last commit moving the resolver, I changed to generated component 
metadata, and removed the per-lookup on many of those classes, so the cache 
should be a singleton now.

[~lcorneliussen] can you review and let me know if that would address this 
issue, or if it might have any unintended consequences I didn't anticipate?

 Cache resolve-result reactor-wide to avoid pdb/gac/++ beeing resolved 
 multiple times
 

 Key: NPANDAY-599
 URL: https://issues.apache.org/jira/browse/NPANDAY-599
 Project: NPanday
  Issue Type: Sub-task
  Components: Maven Plugins
Reporter: Lars Corneliussen
 Fix For: 1.5.0-incubating


 Currently it seems like our custom contributors/resolvers execute for every 
 possible path (artifact.getDependencyTrail() changes...).
 We can cache what we resolved reactor-wide in a separate component.
 Cachekey would be artifact.getId(), right?
 Should we let each contributor implement the cache 
 (ArtifactResolvingContributor) - or should it be generically handled in the 
 artifact resolver? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (NPANDAY-629) Unable to build dist projects with Maven 3

Brett Porter created NPANDAY-629:


 Summary: Unable to build dist projects with Maven 3
 Key: NPANDAY-629
 URL: https://issues.apache.org/jira/browse/NPANDAY-629
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
 Fix For: 1.5.0-incubating


A NullPointerException occurs in the assembly plugin - it seems that the 
repository code in there has an incompatibility with Maven 3.

Will need to look into an alternative, or a fix to the assembly plugin.

This might cause problems for release at the moment because the site publishing 
requires Maven 3 - that'll need to be further extracted to a profile if we 
can't build the rest with Maven 3.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (NPANDAY-630) Some integration tests fail when run with Maven 3

Brett Porter created NPANDAY-630:


 Summary: Some integration tests fail when run with Maven 3
 Key: NPANDAY-630
 URL: https://issues.apache.org/jira/browse/NPANDAY-630
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


There are two tests that still fail when run with Maven 3, but not with Maven 2:
- NPANDAY-329 (seems the bin directory is not generated as expected - may be a 
bug in NPanday when run under Maven 3)
- IT0028 (lack of support for non-unique snapshots - should be disabled under 
Maven 3).





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (NPANDAY-630) Some integration tests fail when run with Maven 3


[ 
https://issues.apache.org/jira/browse/NPANDAY-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055774#comment-14055774
 ] 

Brett Porter commented on NPANDAY-630:
--

This might relate to the first: 
https://github.com/apache/npanday/commit/194e6f2375045733d228201996c256929597ae15

 Some integration tests fail when run with Maven 3
 -

 Key: NPANDAY-630
 URL: https://issues.apache.org/jira/browse/NPANDAY-630
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 There are two tests that still fail when run with Maven 3, but not with Maven 
 2:
 - NPANDAY-329 (seems the bin directory is not generated as expected - may be 
 a bug in NPanday when run under Maven 3)
 - IT0028 (lack of support for non-unique snapshots - should be disabled under 
 Maven 3).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-628) Refactor SDK location

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

Brett Porter updated NPANDAY-628:
-

Attachment: 0001-experiment-with-adding-a-toolsVersion.patch

An experiment I'd done previously for adding a toolsVersion. Might provide some
help when picking up again, though the patch will likely be overridden by
NPANDAY-627, and dotnet-msbuild already has that probing path via NPANDAY-505
now.

Refactor SDK location
-

Key: NPANDAY-628
URL: https://issues.apache.org/jira/browse/NPANDAY-628
Project: NPanday
Issue Type: Improvement
Components: Maven Plugins
Reporter: Brett Porter
Fix For: Backlog

Attachments: 0001-experiment-with-adding-a-toolsVersion.patch

See NPANDAY-505 for more details on the initial proposal. In the interim,
several probing paths have been added to the compile/executable plugins
metadata. However, these suffer some failings:
- imprecise location of the right framework in some cases (e.g. vbc always
uses the latest tools version, matches 4.0 even when targetting 2.0, etc.)
- no way to specify the tools version vs. the framework (target) version
- duplication of probing paths that need to be updated for new SDK releases
We should pick up on the suggestions in the original ticket to create an SDK
description that can find the right paths for MSBuild tools and for NET FX
tools based on a given tools version, framework version, SDK version (if
applicable/desired) and executable. This can then be referenced by more
succinct plugin definitions (one per executable).
The same API could be used for other SDKs, like Azure and Web Deploy.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (NPANDAY-505) Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)


[ 
https://issues.apache.org/jira/browse/NPANDAY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727460#comment-13727460
 ] 

Brett Porter edited comment on NPANDAY-505 at 7/8/14 3:06 AM:
--

Looking closer at the code for this, it seems that the SDK locators are too 
broad in the first place, and there is some confusion between .NET SDK and 
Windows SDK references. We would be better specifying the expected path of the 
specific commands needed:

* csc, etc. in the framework tools path
* xsd, gacutil in the framework NETFX path

That way it should just be one path rather than a search.

I note that there are the following to help now, which reference the specific 
Windows SDK:

{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0@MSBuildToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\3.5@MSBuildToolsPath}}

and from 4.0 also:

{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@FrameworkSDKRoot}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@SDK35ToolsPath}}
 (points to the Windows SDK suitable for 3.5 tools)
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@SDK40ToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft 
SDKs\Windows@CurrentInstallFolder}} (points to the Windows SDK suitable for 3.5 
tools also, if {{bin}} subdirectory is referenced)

For 4.5 SDK:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0@SDK40ToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\11.0@SDK40ToolsPath}}
 (if MSBuild 12.0 has been installed)

For 4.5.1 SDK:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\12.0@SDK40ToolsPath}}



was (Author: brettporter):
Looking closer at the code for this, it seems that the SDK locators are too 
broad in the first place, and there is some confusion between .NET SDK and 
Windows SDK references. We would be better specifying the expected path of the 
specific commands needed:

* csc, etc. in the framework tools path
* xsd, gacutil in the framework NETFX path

That way it should just be one path rather than a search.

I note that there are the following to help now, which reference the specific 
Windows SDK:

{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0@MSBuildToolsPath}}

and from 4.0 also:

{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@FrameworkSDKRoot}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@SDK40ToolsPath}}

 Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)
 -

 Key: NPANDAY-505
 URL: https://issues.apache.org/jira/browse/NPANDAY-505
 Project: NPanday
  Issue Type: Improvement
  Components: Development Setup, Maven Plugins
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 Currently NPanday sometimes generates a {{npanday-settings.xml}}-file; 
 preferably in {{~/.m2}}. Currently this is done by 
 NPanday.Plugin.Settings:generate-settings. The problem is, that the file is 
 needed to compile the plugin that generates it. That makes it hard to 
 bootstrap without a path.
 h2. New Approach
 We create a master superset configuration {{npanday-settings.xml}} (or 
 better {{supported-vendors.xml}}?? that contains all frameworks and vendors 
 NPanday supports. Then based on various rules, NPanday checks which 
 combinations of vendor, vendorVersion and frameworkVersion(s) are available 
 on the current platform (registry and path lookup, as currently done in 
 generate-settings).
 h2. Example
 Currently this code:
 {code:title=plugins\netplugins\NPanday.Plugin.Settings\src\main\csharp\DotnetSdkLocator.cs}
 ..
 RegistryKey Microsoft_NETFramework = 
 Registry.LocalMachine.OpenSubKey(@SOFTWARE\Microsoft\.NETFramework);
 RegistryKey Microsoft_SDKs_NETFramework = 
 Registry.LocalMachine.OpenSubKey(@SOFTWARE\Microsoft\SDKs\.NETFramework);
 ..
 return PathUtil.FirstExisting(
 registryFind(Microsoft_NETFramework, sdkInstallRootv2.0),
 registryFind(Microsoft_SDKs_NETFramework, v2.0, 
 InstallationFolder),
 ProgramFilesX86(@Microsoft.NET\SDK\v2.0),
 ProgramFilesX86(@Microsoft.NET\SDK\v2.0 64bit),
 ProgramFilesX86(@Microsoft SDKs\Windows\v6.0A\bin),
 ProgramFiles(@Microsoft SDKs\Windows\v6.0A\bin)
 );
 {code}
 Generates this:
 {code:title=~\.m2\npanday-settings.xml}
 ...
 vendor
   vendorNameMICROSOFT/vendorName
   vendorVersion3.0/vendorVersion
   frameworks
 framework
   frameworkVersion3.0/frameworkVersion
   installRootC:\Windows\Microsoft.NET\Framework64\v3.0

[jira] [Comment Edited] (NPANDAY-505) Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)


[ 
https://issues.apache.org/jira/browse/NPANDAY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727460#comment-13727460
 ] 

Brett Porter edited comment on NPANDAY-505 at 7/8/14 3:45 AM:
--

Looking closer at the code for this, it seems that the SDK locators are too 
broad in the first place, and there is some confusion between .NET SDK and 
Windows SDK references. We would be better specifying the expected path of the 
specific commands needed:

* csc, etc. in the framework tools path
* xsd, gacutil in the framework NETFX path

That way it should just be one path rather than a search.

I note that there are the following to help now, which reference the specific 
Windows SDK:

{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0@MSBuildToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\3.5@MSBuildToolsPath}}

and from 4.0 also:

{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@MSBuildToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@SDK35ToolsPath}}
 (points to the Windows SDK suitable for 3.5 tools)
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@SDK40ToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft 
SDKs\Windows@CurrentInstallFolder}} (points to the Windows SDK suitable for 3.5 
tools also, if {{bin}} subdirectory is referenced)

For 4.5 SDK:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0@SDK40ToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\11.0@SDK40ToolsPath}}
 (if MSBuild 12.0 has been installed)

For 4.5.1 SDK:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\12.0@SDK40ToolsPath}}



was (Author: brettporter):
Looking closer at the code for this, it seems that the SDK locators are too 
broad in the first place, and there is some confusion between .NET SDK and 
Windows SDK references. We would be better specifying the expected path of the 
specific commands needed:

* csc, etc. in the framework tools path
* xsd, gacutil in the framework NETFX path

That way it should just be one path rather than a search.

I note that there are the following to help now, which reference the specific 
Windows SDK:

{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0@MSBuildToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\3.5@MSBuildToolsPath}}

and from 4.0 also:

{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@FrameworkSDKRoot}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@SDK35ToolsPath}}
 (points to the Windows SDK suitable for 3.5 tools)
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@SDK40ToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft 
SDKs\Windows@CurrentInstallFolder}} (points to the Windows SDK suitable for 3.5 
tools also, if {{bin}} subdirectory is referenced)

For 4.5 SDK:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0@SDK40ToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\11.0@SDK40ToolsPath}}
 (if MSBuild 12.0 has been installed)

For 4.5.1 SDK:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\12.0@SDK40ToolsPath}}


 Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)
 -

 Key: NPANDAY-505
 URL: https://issues.apache.org/jira/browse/NPANDAY-505
 Project: NPanday
  Issue Type: Improvement
  Components: Development Setup, Maven Plugins
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 Currently NPanday sometimes generates a {{npanday-settings.xml}}-file; 
 preferably in {{~/.m2}}. Currently this is done by 
 NPanday.Plugin.Settings:generate-settings. The problem is, that the file is 
 needed to compile the plugin that generates it. That makes it hard to 
 bootstrap without a path.
 h2. New Approach
 We create a master superset configuration {{npanday-settings.xml}} (or 
 better {{supported-vendors.xml}}?? that contains all frameworks and vendors 
 NPanday supports. Then based on various rules, NPanday checks which 
 combinations of vendor, vendorVersion and frameworkVersion(s) are available 
 on the current platform (registry and path lookup, as currently done in 
 generate-settings).
 h2. Example
 Currently this code:
 {code:title=plugins\netplugins\NPanday.Plugin.Settings\src\main\csharp\DotnetSdkLocator.cs}
 ..
 RegistryKey Microsoft_NETFramework = 
 Registry.LocalMachine.OpenSubKey(@SOFTWARE\Microsoft\.NETFramework);
 RegistryKey Microsoft_SDKs_NETFramework = 
 Registry.LocalMachine.OpenSubKey(@SOFTWARE\Microsoft\SDKs\.NETFramework);
 ..
 return PathUtil.FirstExisting

[jira] [Assigned] (NPANDAY-203) MSBuild should be called from Java / remove .NET-MSBuild-Plugin


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

Brett Porter reassigned NPANDAY-203:


Assignee: Brett Porter  (was: Lars Corneliussen)

 MSBuild should be called from Java / remove .NET-MSBuild-Plugin
 ---

 Key: NPANDAY-203
 URL: https://issues.apache.org/jira/browse/NPANDAY-203
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Brett Porter
Priority: Minor
 Fix For: Backlog


 Currently this is doing nothing more than reading the parameters and forking 
 msbuild - this can be done in a Java mojo, removing one of the Process.Start 
 calls.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-203) MSBuild should be called from Java / remove .NET-MSBuild-Plugin


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

Brett Porter resolved NPANDAY-203.
--

   Resolution: Fixed
Fix Version/s: (was: Backlog)
   1.5.0-incubating

Done. Kept the same mojo and parameters, though it might make sense to 
deprecate that and make a cleaned up msbuild-maven-plugin for the next release.

 MSBuild should be called from Java / remove .NET-MSBuild-Plugin
 ---

 Key: NPANDAY-203
 URL: https://issues.apache.org/jira/browse/NPANDAY-203
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Brett Porter
Priority: Minor
 Fix For: 1.5.0-incubating


 Currently this is doing nothing more than reading the parameters and forking 
 msbuild - this can be done in a Java mojo, removing one of the Process.Start 
 calls.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (NPANDAY-626) Clean up and rename MSBuild plugin

Brett Porter created NPANDAY-626:


 Summary: Clean up and rename MSBuild plugin
 Key: NPANDAY-626
 URL: https://issues.apache.org/jira/browse/NPANDAY-626
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Reporter: Brett Porter
 Fix For: Backlog


See NPANDAY-203: currently still using the old JavaBinding name from the C# 
wrapper.

It would be good to create a clean {{msbuild-maven-plugin}} using the current 
code, remove the deprecated arguments field, and update the project importer to 
use the new plugin.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (NPANDAY-627) Remove npanday-settings and generator plugin

Brett Porter created NPANDAY-627:


 Summary: Remove npanday-settings and generator plugin
 Key: NPANDAY-627
 URL: https://issues.apache.org/jira/browse/NPANDAY-627
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Reporter: Brett Porter
 Fix For: Backlog


See NPANDAY-505 - we previously removed reliance on the settings file, but it 
is still created (and used if it exists as a fallback).

In a future release we should remove it entirely and focus on the SDK probing.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-628) Refactor SDK location


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

Brett Porter updated NPANDAY-628:
-

Fix Version/s: Backlog

 Refactor SDK location
 -

 Key: NPANDAY-628
 URL: https://issues.apache.org/jira/browse/NPANDAY-628
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Reporter: Brett Porter
 Fix For: Backlog


 See NPANDAY-505 for more details on the initial proposal. In the interim, 
 several probing paths have been added to the compile/executable plugins 
 metadata. However, these suffer some failings:
 - imprecise location of the right framework in some cases (e.g. vbc always 
 uses the latest tools version, matches 4.0 even when targetting 2.0, etc.)
 - no way to specify the tools version vs. the framework (target) version
 - duplication of probing paths that need to be updated for new SDK releases
 We should pick up on the suggestions in the original ticket to create an SDK 
 description that can find the right paths for MSBuild tools and for NET FX 
 tools based on a given tools version, framework version, SDK version (if 
 applicable/desired) and executable. This can then be referenced by more 
 succinct plugin definitions (one per executable).
 The same API could be used for other SDKs, like Azure and Web Deploy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (NPANDAY-628) Refactor SDK location

Brett Porter created NPANDAY-628:


 Summary: Refactor SDK location
 Key: NPANDAY-628
 URL: https://issues.apache.org/jira/browse/NPANDAY-628
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Reporter: Brett Porter


See NPANDAY-505 for more details on the initial proposal. In the interim, 
several probing paths have been added to the compile/executable plugins 
metadata. However, these suffer some failings:
- imprecise location of the right framework in some cases (e.g. vbc always uses 
the latest tools version, matches 4.0 even when targetting 2.0, etc.)
- no way to specify the tools version vs. the framework (target) version
- duplication of probing paths that need to be updated for new SDK releases

We should pick up on the suggestions in the original ticket to create an SDK 
description that can find the right paths for MSBuild tools and for NET FX 
tools based on a given tools version, framework version, SDK version (if 
applicable/desired) and executable. This can then be referenced by more 
succinct plugin definitions (one per executable).

The same API could be used for other SDKs, like Azure and Web Deploy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (NPANDAY-505) Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)


[ 
https://issues.apache.org/jira/browse/NPANDAY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14054525#comment-14054525
 ] 

Brett Porter commented on NPANDAY-505:
--

Took a simpler approach to this and added the necessary probingPaths for all 
the different executables in the detected vendors. The settings are still used 
if present, but no longer required.

See NPANDAY-627 and NPANDAY-628 for further improvements, similar to those 
initially suggested here.

 Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)
 -

 Key: NPANDAY-505
 URL: https://issues.apache.org/jira/browse/NPANDAY-505
 Project: NPanday
  Issue Type: Improvement
  Components: Development Setup, Maven Plugins
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 Currently NPanday sometimes generates a {{npanday-settings.xml}}-file; 
 preferably in {{~/.m2}}. Currently this is done by 
 NPanday.Plugin.Settings:generate-settings. The problem is, that the file is 
 needed to compile the plugin that generates it. That makes it hard to 
 bootstrap without a path.
 h2. New Approach
 We create a master superset configuration {{npanday-settings.xml}} (or 
 better {{supported-vendors.xml}}?? that contains all frameworks and vendors 
 NPanday supports. Then based on various rules, NPanday checks which 
 combinations of vendor, vendorVersion and frameworkVersion(s) are available 
 on the current platform (registry and path lookup, as currently done in 
 generate-settings).
 h2. Example
 Currently this code:
 {code:title=plugins\netplugins\NPanday.Plugin.Settings\src\main\csharp\DotnetSdkLocator.cs}
 ..
 RegistryKey Microsoft_NETFramework = 
 Registry.LocalMachine.OpenSubKey(@SOFTWARE\Microsoft\.NETFramework);
 RegistryKey Microsoft_SDKs_NETFramework = 
 Registry.LocalMachine.OpenSubKey(@SOFTWARE\Microsoft\SDKs\.NETFramework);
 ..
 return PathUtil.FirstExisting(
 registryFind(Microsoft_NETFramework, sdkInstallRootv2.0),
 registryFind(Microsoft_SDKs_NETFramework, v2.0, 
 InstallationFolder),
 ProgramFilesX86(@Microsoft.NET\SDK\v2.0),
 ProgramFilesX86(@Microsoft.NET\SDK\v2.0 64bit),
 ProgramFilesX86(@Microsoft SDKs\Windows\v6.0A\bin),
 ProgramFiles(@Microsoft SDKs\Windows\v6.0A\bin)
 );
 {code}
 Generates this:
 {code:title=~\.m2\npanday-settings.xml}
 ...
 vendor
   vendorNameMICROSOFT/vendorName
   vendorVersion3.0/vendorVersion
   frameworks
 framework
   frameworkVersion3.0/frameworkVersion
   installRootC:\Windows\Microsoft.NET\Framework64\v3.0/installRoot
   sdkInstallRootC:\Program Files\Microsoft.NET\SDK\v2.0 
 64bit\/sdkInstallRoot
   executablePaths
 
 executablePathC:\Windows\Microsoft.NET\Framework64\v2.0.50727/executablePath
 executablePathC:\Program Files\Microsoft.NET\SDK\v2.0 
 64bit\bin/executablePath
   /executablePaths
 /framework
   /frameworks
 /vendor
 ...
 {code}
 {code:title=components\dotnet-core\src\main\resources\META-INF\npanday\npanday-settings.xml}
 ...
   vendors
 ...
 vendor
   vendorNameMICROSOFT/vendorName
   vendorVersion3.0/vendorVersion
   frameworks
 framework
   !-- new !! --
   frameworkArchitectureAMD64/frameworkArchitecture  
   frameworkVersion3.0/frameworkVersion
   
   !-- registry (Software\Microsoft\.NETFrameworkd@InstallPath) 
 allways finds Framework64 on 64bit windows; hence path is better --
   
 installRoot${env.WINDIR}\Microsoft.NET\Framework64\v3.0/installRoot
   
   !-- first one wins --
   sdkInstallRootProbingPaths
 
 sdkInstallRootProbingPath${HKLM\Software\Microsoft\.NETFramework@sdkInstallRootv2.0}/sdkInstallRootProbingPath
 sdkInstallRootProbingPath${HKLM\SOFTWARE\Microsoft\Microsoft 
 SDKs\.NETFramework\v2.0@InstallationFolder}/sdkInstallRootProbingPath
 
 sdkInstallRootProbingPath${env.ProgramFiles}\Microsoft.NET\SDK\v2.0/sdkInstallRootProbingPath
 sdkInstallRootProbingPath${env.ProgramFiles}\Microsoft 
 SDKs\Windows\v6.0A\bin/sdkInstallRootProbingPath
 sdkInstallRootProbingPath${env.ProgramFilesX86}(@Microsoft 
 SDKs\Windows\v6.0A\bin}/sdkInstallRootProbingPath
   /sdkInstallRootProbingPaths
   executableProbingPaths
 !-- 3.0 doesn't come with new tools --
 
 executableProbingPath${env.WINDIR}\Microsoft.NET\Framework64\v2.0.50727/executablePath
 
 !-- we could by default add installRoot and sdkInstallRoot(+bin

[jira] [Resolved] (NPANDAY-570) Unable to build NPanday due to missing npanday-settings.xml

2014-07-04 Thread Brett Porter (JIRA)


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

Brett Porter resolved NPANDAY-570.
--

Resolution: Fixed
  Assignee: Brett Porter

 Unable to build NPanday due to missing npanday-settings.xml
 ---

 Key: NPANDAY-570
 URL: https://issues.apache.org/jira/browse/NPANDAY-570
 Project: NPanday
  Issue Type: Bug
  Components: Development Setup
Affects Versions: 1.5.0-incubating
 Environment: Windows 7 Professional x64, Java 1.7 (x86), Maven 3.0.4, 
 Windows SDK 7.1
Reporter: Julian Cromarty
Assignee: Brett Porter
  Labels: build
 Fix For: 1.5.0-incubating

 Attachments: dotnet-pom.patch


 Possibly related to NPANDAY-413
 Having been unsuccessful in getting NPanday to work from the msi installer 
 (it doesn't seem to install the NPanday plugins anywhere and repo.npanday.org 
 doesn't exist anymore) I figured I'd try building it from source. I followed 
 the instructions on the site, i.e. running mvn clean install from the 
 directory where I checked out the source and it fails when trying to build 
 NPanday.Model.Pom with the following error:
 [INFO] 
 
 [INFO] Building NPanday :: .NET Model :: POM 1.5.0-incubating-SNAPSHOT
 [INFO] 
 
 [INFO]
 [INFO] --- maven-compile-plugin:1.5.0-incubating-SNAPSHOT:initialize 
 (default-initialize) @ NPanday.Model.Pom ---
 [WARNING] Invalid POM for NUnit:NUnit.Framework:dotnet-library:2.2.8.0, 
 transitive dependencies (if any) will not be available, enable debug logging 
 for more details
 [INFO]
 [INFO] --- 
 NPanday.Plugin.Settings.JavaBinding:1.5.0-incubating-SNAPSHOT:generate-settings
  (default-generate-settings) @ NPanday.Model.Pom ---
 [INFO] NPANDAY-119-000: Excecution of generate-settings has been skipped.
 [INFO]
 [INFO] --- 
 maven-compile-plugin:1.5.0-incubating-SNAPSHOT:generate-assembly-info 
 (default-generate-assembly-info) @ NPanday.Model.Pom ---
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] NPanday :: .NET Model :: POM .. FAILURE [0.747s]
 [INFO] NPanday :: .NET Model :: Settings . SKIPPED
 [INFO] NPanday :: .NET Model :: AutomationExtensibility .. SKIPPED
 [INFO] NPanday :: .NET Utils . SKIPPED
 [INFO] NPanday :: .NET Artifact .. SKIPPED
 [INFO] NPanday :: .NET Plugin  SKIPPED
 [INFO] NPanday :: .NET Plugin MojoGenerator .. SKIPPED
 [INFO] NPanday :: .NET Plugin Loader . SKIPPED
 [INFO] NPanday :: .NET Plugin Runner . SKIPPED
 [INFO] NPanday :: Project Importer ... SKIPPED
 [INFO] NPanday :: Project Importer :: Engine . SKIPPED
 [INFO] NPanday :: Project Importer :: Console  SKIPPED
 [INFO] NPanday :: VisualStudio Addin . SKIPPED
 [INFO] NPanday :: VisualStudio Project Wizard  SKIPPED
 [INFO] NPanday :: .NET Plugins ... SKIPPED
 [INFO] NPanday :: Addin Plugin ... SKIPPED
 [INFO] NPanday :: Devenv Plugin .. SKIPPED
 [INFO] NPanday :: ResX Plugin  SKIPPED
 [INFO] NPanday :: Settings Plugin  SKIPPED
 [INFO] NPanday :: SysRef Plugin .. SKIPPED
 [INFO] NPanday :: Msbuild Plugin . SKIPPED
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 2.131s
 [INFO] Finished at: Fri Aug 31 09:58:01 BST 2012
 [INFO] Final Memory: 18M/44M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.npanday.plugins:maven-compile-plugin:1.5.0-incubating-SNAPSHOT:generate-assembly-info
  (default-generate-assembly-info) on project NPanday.Model.Pom: 
 NPANDAY-108-005:
 nfigured settings file does not exist: 
 C:\Users\jooles\.m2\npanday-settings.xml - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal 
 org.apache.npanday.plugins:maven-compile-plugin:1.5.0-incubating-SNAPSHOT:generate-assembly-info
  (default-generate-assembly-info)
 n project NPanday.Model.Pom: NPANDAY-108-005: Configured settings file does 
 not exist: C:\Users\jooles\.m2\npanday-settings.xml
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217

Re: Incubator PMC/Board report for Jul 2014 ([ppmc])

2014-07-03 Thread Brett Porter

Thoughts on the below?

---

NPanday allows projects using the .NET framework to be built with Apache
Maven.

NPanday has been incubating since 2010-08-13.

Since the last report in April, a few obstacles have been removed:
 - the status page was updated with the current podling state and correct 
mentors
 - svnpubsub was enabled so the website can be updated again
 - a number of JIRA issues have been cleaned up to prepare for the release

Not blocking, but outstanding things to do:
 - resolve issues with Jenkins builds with infrastructure
 - finish closing out JIRA issues that have been partially finished for release
 - apply suitable patches that have been overlooked in the past and try to 
reconnect with contributors

Three most important issues to address in the move towards graduation:

  1. Ship the changes on trunk as a release and make it easier for new users to 
get up to speed when interested in the project
  2. Get a critical mass of committers/PPMC members that can respond to 
contributors, apply patches, nominate committers, and vote on releases
  3. Provide guidance on how to get involved in contributing

The incubator is already aware of the low level of activity, that many of the 
PPMC are now disengaged and lack of mentors for the project. Konstantin Boudnik 
has put his hand up to help out and that discussion is in progress.

There continues to be interest in a new release from users, and new interest 
from some in making contributions that continue to be followed up.

Date of last release:

  2011-05-16

The last committer was added on 2011-04-19. There have not been any PPMC 
additions since inception.

Signed-off-by:

  [ ](npanday) Raphael Bircher

Shepherd/Mentor notes:

---

On 3 Jul 2014, at 12:15 am, Marvin no-re...@apache.org wrote:

 
 
 Dear podling,
 
 This email was sent by an automated system on behalf of the Apache Incubator 
 PMC.
 It is an initial reminder to give you plenty of time to prepare your quarterly
 board report.
 
 The board meeting is scheduled for Wed, 16 July 2014, 10:30:30:00 PST. The 
 report 
 for your podling will form a part of the Incubator PMC report. The Incubator 
 PMC 
 requires your report to be submitted 2 weeks before the board meeting, to 
 allow 
 sufficient time for review and submission (Wed, Jul 2nd).
 
 Please submit your report with sufficient time to allow the incubator PMC, 
 and 
 subsequently board members to review and digest. Again, the very latest you 
 should submit your report is 2 weeks prior to the board meeting.
 
 Thanks,
 
 The Apache Incubator PMC
 
 Submitting your Report
 --
 
 Your report should contain the following:
 
 * Your project name
 * A brief description of your project, which assumes no knowledge of the 
 project
   or necessarily of its field
 * A list of the three most important issues to address in the move towards 
   graduation.
 * Any issues that the Incubator PMC or ASF Board might wish/need to be aware 
 of
 * How has the community developed since the last report
 * How has the project developed since the last report.
 
 This should be appended to the Incubator Wiki page at:
 
  http://wiki.apache.org/incubator/July2014
 
 Note: This manually populated. You may need to wait a little before this page 
 is
  created from a template.
 
 Mentors
 ---
 Mentors should review reports for their project(s) and sign them off on the 
 Incubator wiki page. Signing off reports shows that you are following the 
 project - projects that are not signed may raise alarms for the Incubator PMC.
 
 Incubator PMC

[jira] [Commented] (NPANDAY-624) NPE in ilMerge

2014-07-01 Thread Brett Porter (JIRA)


[ 
https://issues.apache.org/jira/browse/NPANDAY-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14049602#comment-14049602
 ] 

Brett Porter commented on NPANDAY-624:
--

That plugin has been unloved for a while - it looks like what you need to add 
is:

{code:xml}
profileAssemblyPathC:\Path\To\ILMerge\bin/profileAssemblyPath
{code}

Does that help?

What should be done to the plugin is to replace the compiler lookup with 
{{netExecutableFactory.getExecutable}}, trim out the parameters, and perhaps 
add a default path / registry based path into {{executable-plugins.xml}}. An 
example of how this is done is in {{AbstractCSPackDeployMojo.java}} in the 
{{azure-maven-plugin}}.

 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'], 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

[jira] [Commented] (NPANDAY-622) NPE - compile:testCompile

2014-07-01 Thread Brett Porter (JIRA)


[ 
https://issues.apache.org/jira/browse/NPANDAY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14049609#comment-14049609
 ] 

Brett Porter commented on NPANDAY-622:
--

Try adding this before the other goals for {{maven-compile-plugin}} in your 
example:

{code:xml}
goalinitialize/goal
{code}

Does that help?

 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

Updated NPanday JIRA issues

2014-07-01 Thread Brett Porter

Hi,

As one of the things remaining on the list for a while, I went through the 
outstanding JIRA issues.

There are a few with open questions.. Lars, several in particular were things 
you were looking at.

PDBs  subtasks
NPANDAY-402: PDBs - ready to close as done?
NPANDAY-566, NPANDAY-595, NPANDAY-597: close as done?
NPANDAY-596, NPANDAY-599, NPANDAY-600: split out for a later release?

Others:
NPANDAY-499: compiler-plugins split - looks to be done now?
NPANDAY-575: looks done. Need to add the supplied test project as an IT?
NPANDAY-567: what needs to be done to finish?

For the others I've either closed them out, or moved them to the Backlog if 
they aren't being actively worked on or needed for the next release. Anyone 
interested in working on them can pull them back in, but for the moment the 
focus should be on closing out 1.5.0 and making that long-overdue release.

Thanks,
Brett

[jira] [Resolved] (NPANDAY-231) Remove RDF repository and model

2014-07-01 Thread Brett Porter (JIRA)


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

Brett Porter resolved NPANDAY-231.
--

Resolution: Fixed

One straggling reference that I just removed. Looks good.

 Remove RDF repository and model
 ---

 Key: NPANDAY-231
 URL: https://issues.apache.org/jira/browse/NPANDAY-231
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Brett Porter
Assignee: Lars Corneliussen
Priority: Critical
 Fix For: 1.5.0-incubating


 This will be a significant change to the way NPanday works internally, but 
 should have no external effect. We desire to have it more closely work with 
 Maven's dependency resolution, as the RDF adds no value and produces a number 
 of confusing results and error messages.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[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=14045583#comment-14045583
 ] 

Brett Porter commented on NPANDAY-618:
--

Have you tried a {{com_reference}} dependency type?

http://svn.apache.org/viewvc/incubator/npanday/npanday-its/trunk/src/test/resources/NPANDAY_538_COMReferenceTest/COMApplication/pom.xml?view=markup

That creates a temporary interop DLL by calling {{tlbimp}} with {{/out}} and 
{{/namespace}}

Or do you need a more custom execution of {{tlbimp}}?

(BTW, Dropped the fix version - trying to cut that down to regressions so we 
can get a release out).



 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] [Updated] (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:all-tabpanel
 ]

Brett Porter updated NPANDAY-618:
-

Fix Version/s: (was: 1.5.0-incubating)

 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] [Resolved] (NPANDAY-561) [regression to NPANDAY-231] Resolving com_reference is untested


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

Brett Porter resolved NPANDAY-561.
--

Resolution: Fixed
  Assignee: Brett Porter

Now has IT (see NPANDAY-538)

 [regression to NPANDAY-231] Resolving com_reference is untested
 ---

 Key: NPANDAY-561
 URL: https://issues.apache.org/jira/browse/NPANDAY-561
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Lars Corneliussen
Assignee: Brett Porter
 Fix For: 1.5.0-incubating


 Implementation for resolving com_reference was ported to 
 ComReferenceResolver, but is untested!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-203) MSBuild should be called from Java / remove .NET-MSBuild-Plugin


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

Brett Porter updated NPANDAY-203:
-

Fix Version/s: (was: 1.5.0-incubating)

 MSBuild should be called from Java / remove .NET-MSBuild-Plugin
 ---

 Key: NPANDAY-203
 URL: https://issues.apache.org/jira/browse/NPANDAY-203
 Project: NPanday
  Issue Type: Bug
Reporter: Brett Porter
Assignee: Lars Corneliussen
Priority: Minor

 Currently this is doing nothing more than reading the parameters and forking 
 msbuild - this can be done in a Java mojo, removing one of the Process.Start 
 calls.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-568) When removing the last test, npanday still runs the previously compiled tests


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

Brett Porter updated NPANDAY-568:
-

Fix Version/s: Backlog

 When removing the last test, npanday still runs the previously compiled tests
 -

 Key: NPANDAY-568
 URL: https://issues.apache.org/jira/browse/NPANDAY-568
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Lars Corneliussen
 Fix For: Backlog


 We have to remove the test-dll if it exists and no tests are found...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-557) Support import of multiple framework versions from a Nuget Package


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

Brett Porter updated NPANDAY-557:
-

Fix Version/s: Backlog

 Support import of multiple framework versions from a Nuget Package
 --

 Key: NPANDAY-557
 URL: https://issues.apache.org/jira/browse/NPANDAY-557
 Project: NPanday
  Issue Type: Improvement
  Components: Library Importer
Affects Versions: 1.5.0-incubating
Reporter: Lars Corneliussen
  Labels: multi-targeting
 Fix For: Backlog


 The Library Importer currently only imports one of the lib-folders in a nuget 
 package.
 When importing multiple, we have to decide how we map the framework to the 
 artifactId or version. Classifier will not work, because each framework 
 version would need it's own pom, since it can have different dependencies.
 This should also be correlated with [#NPANDAY-405] (Allow to build multiple 
 configurations in one build (Multi-targeting))



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-484) Remove NPanday.Plugin.Addin as it is outdated and unused


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

Brett Porter updated NPANDAY-484:
-

Fix Version/s: Backlog

 Remove NPanday.Plugin.Addin as it is outdated and unused
 

 Key: NPANDAY-484
 URL: https://issues.apache.org/jira/browse/NPANDAY-484
 Project: NPanday
  Issue Type: Wish
  Components: Maven Plugins
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen
 Fix For: Backlog


 It it one of three sources for the *.Addin-file (we also have wix and 
 maven-vsinstaller-plugin.
 It only supports VS 2005 and seems to be quite outdated. I think people 
 should rather create theese manually and then filter in properties from the 
 pom.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-482) Consistent use of NPanday.Logger (or Apache Commons Logging?) thoughout .NET code base


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

Brett Porter updated NPANDAY-482:
-

Fix Version/s: Backlog

 Consistent use of NPanday.Logger (or Apache Commons Logging?) thoughout .NET 
 code base
 --

 Key: NPANDAY-482
 URL: https://issues.apache.org/jira/browse/NPANDAY-482
 Project: NPanday
  Issue Type: Improvement
  Components: Project Importer, Visual Studio Add-in
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen
Assignee: Lars Corneliussen
 Fix For: Backlog


 Refactor all Console.WriteLines and OutputPane.OutputString to use the logger 
 (which writes to the Output pane).
 Also consider to replace the current logger with a standard logger like 
 Commons Logging 
 (http://netcommon.sourceforge.net/docs/2.0.0/reference/html/index.html). 
 Commons Logging can be used to delegate logging to for example NLog or 
 log4net.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-475) Consolidate AssemblyInfo-generation + modification


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

Brett Porter updated NPANDAY-475:
-

Fix Version/s: Backlog

 Consolidate AssemblyInfo-generation + modification
 --

 Key: NPANDAY-475
 URL: https://issues.apache.org/jira/browse/NPANDAY-475
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen
 Fix For: Backlog


 h2. Current Situation
 Currently, code that handles AssemblyInfo.cs(.vb) is cluttered all over the 
 project.
 # AbstractCompilerMojo (compile phase) patches AssemblyInfo-versions for 
 **/AssemblyInfo(.cs|.vb)
 # AssemblyInfoGeneratorMojo (generate-sources phase) uses AssemblyInfo + 
 AssemblyInfoMarshaller to generate new AssemblyInfos
 The AssemblyInfoMarshaller does have a read implementation, but it's 
 half-baked.
 h2. Solution
 I think everything should be unified according to these rules:
 * Make the name of AssemblyInfo and COPYRIGHT configurable (includes 
 NPANDAY-406)
 * generate-sources: If no AssemblyInfo found, generate one *to target*. Else 
 copy the existing one.
 ** Never change the original AssemblyInfo file
 ** Make sure, AssemblyInfo file is not overridden by default compiler copy
 * process-sources: Read the AssemblyInfo (Marshaller.unmarshal), patch it, 
 and write it back using marshal-Method.
 ** Expose all attributes to the pom (copyright, description, ...)
 ** Allow custom assemblyinfo attributes to be specified in the pom



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-481) Refactor Connect.cs into Command-Pattern / Span over multiple classes


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

Brett Porter updated NPANDAY-481:
-

Fix Version/s: Backlog

 Refactor Connect.cs into Command-Pattern / Span over multiple classes
 -

 Key: NPANDAY-481
 URL: https://issues.apache.org/jira/browse/NPANDAY-481
 Project: NPanday
  Issue Type: Improvement
  Components: Visual Studio Add-in
Affects Versions: 1.4-incubating
Reporter: Lars Corneliussen
 Fix For: Backlog


 Continuation for NPANDAY-479
 Currently Connect.cs contains most of the code for both commands and events. 
 These should be refactored out to classes per Command and Event Receiver.
 Base class {{{ButtonCommand}}} and helper class {{{CommandRegistry}}} are 
 already done (in Context of NPANDAY-479) and can be used for the commands.
 For events we still have to find a good system.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-503) Make use of Assembly-Info marshallers, or remove related (unused) projects


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

Brett Porter updated NPANDAY-503:
-

Fix Version/s: Backlog

 Make use of Assembly-Info marshallers, or remove related (unused) projects
 --

 Key: NPANDAY-503
 URL: https://issues.apache.org/jira/browse/NPANDAY-503
 Project: NPanday
  Issue Type: Improvement
Reporter: Lars Corneliussen
 Fix For: Backlog


 There were some thoughts about pluggable assembyinfo modification through 
 'dotnet-assembler' (bad name, anyway) and dotnet-asssembly-model (plugins for 
 different languages CS/VB).
 I think that'd be much better than the current Mojo - but if we decide not to 
 use them, we should remove the unused modules.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (NPANDAY-501) COM references do not work on x64 machines


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

Brett Porter closed NPANDAY-501.


Resolution: Duplicate
  Assignee: Brett Porter

 COM references do not work on x64 machines
 --

 Key: NPANDAY-501
 URL: https://issues.apache.org/jira/browse/NPANDAY-501
 Project: NPanday
  Issue Type: Task
Affects Versions: 1.4-incubating
Reporter: Brett Porter
Assignee: Brett Porter

 ProjectDaoImpl contains the following hardcoding:
 {code}
 String registryPath = HKEY_CLASSES_ROOT\\TypeLib\\ + newClassifier + 
 \\win32\\;
 {code}
 On x64 machines, the last part is win64. I'm not sure if a straight 
 translation makes sense, however.
 There should be an integration test for this - the WiX example 
 https://svn.apache.org/repos/asf/incubator/npanday/trunk/plugins/wix-maven-plugin/src/it/IT004/pom.xml
  at -r1210927 exhibited this



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-536) Ability to map different role properties when packaging an Azure cloud service


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

Brett Porter updated NPANDAY-536:
-

Fix Version/s: Backlog

 Ability to map different role properties when packaging an Azure cloud service
 --

 Key: NPANDAY-536
 URL: https://issues.apache.org/jira/browse/NPANDAY-536
 Project: NPanday
  Issue Type: Improvement
Affects Versions: 1.5.0-incubating
Reporter: Brett Porter
 Fix For: Backlog


 In the current implementation, the call to CSPACK will always use the 
 artifact ID for the rolename of a dependency that is a web or worker role. 
 However, this may not be the case - so it should be possible to create a 
 mapping, and to generate that with the project importer.
 Likewise, currently a single framework version can be passed to the azure 
 plugin and is used to populate the role property for each dependency, but it 
 may be possible that the project was from a different SDK version. This can 
 be hard to detect from the artifact, unless additional data is written to the 
 repository, but it could be configurable as above.
 Something like the following would be suitable:
 {code:xml}
 roleMappings
   roleMapping
 artifactIdMy.WebRole/artifactId
 roleNameWebRole/roleName
 frameworkVersion3.5/frameworkVersion
   /roleMapping
 /roleMappings
 {code}
 Alternatively, the packaging plugins could generate this information and 
 store in the local repository, then retrieve it as part of the packaging 
 process to create the right role properties file - but it may be difficult if 
 some dependencies need to be used after this was originally considered.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-545) Visual Studio Addin Assembly path not matching 32/64 install folder to running Visual Studio app - fails to load


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

Brett Porter updated NPANDAY-545:
-

Fix Version/s: 1.5.0-incubating

 Visual Studio Addin Assembly path not matching 32/64 install folder to 
 running Visual Studio app - fails to load
 

 Key: NPANDAY-545
 URL: https://issues.apache.org/jira/browse/NPANDAY-545
 Project: NPanday
  Issue Type: Bug
  Components: Visual Studio Add-in
Affects Versions: 1.4-incubating
 Environment: Windows 7 64 bit,
 Visual Studio 10 32 bit
 Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel
 Microsoft .NET Framework Version 4.0.30319 SP1Rel
 Windows Installer XML Toolset 3.5.2519.0 
 NPanday 1.4.0-incubating Maven in .NET Applications
Reporter: Greg Domjan
  Labels: newbie
 Fix For: 1.5.0-incubating


 Pluggins fail to load, reports as error 0x80070002  (file not found)
 Appears that dll's are installed to 64 bit and 32 bit folders, but plugin 
 specifies only the 64 bit folder, 32 bit app is unable to load dlls located 
 in 64 bit program files folder.
 Any NPanday.VisualStudio.AddIn
   Addin
   AssemblyC:\Program 
 Files\NPanday\bin\NPanday.VisualStudio.Addin.dll/Assembly
 Workaround to manually edit the assembly path and add  (x86).
   Addin
   AssemblyC:\Program Files 
 (x86)\NPanday\bin\NPanday.VisualStudio.Addin.dll/Assembly



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (NPANDAY-460) hook for the dependency:purge-local-repository plugin


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

Brett Porter resolved NPANDAY-460.
--

Resolution: Incomplete
  Assignee: Brett Porter

Please reopen if you still need this after the other issue was completed.

 hook for the dependency:purge-local-repository plugin
 -

 Key: NPANDAY-460
 URL: https://issues.apache.org/jira/browse/NPANDAY-460
 Project: NPanday
  Issue Type: New Feature
  Components: Visual Studio Add-in
Reporter: Daniel Williams
Assignee: Brett Porter

 I've begun using NPanday plugin and have noticed that there is no 
 command/plugin to synch the .m2/repository and the .references libs created 
 when adding a maven artifact.  In the java usage of maven this can be done by 
 executing mvn dependency:purge-local-repository.  It would be nice if there 
 was a VS command that could handle this.  This would allow developers to 
 iterate with sharing of libraries in a development phase across many 
 development branches and be sure that they are all working against the most 
 recent version of snapshots.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-528) The assemblyInfo parameter of the generate-assembly-info goal is not described


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

Brett Porter updated NPANDAY-528:
-

Fix Version/s: Backlog

 The assemblyInfo parameter of the generate-assembly-info goal is not 
 described 
 -

 Key: NPANDAY-528
 URL: https://issues.apache.org/jira/browse/NPANDAY-528
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.4-incubating
Reporter: Matthias Weßendorf
 Fix For: Backlog


 The generate-assembly-info goal has the following documentation:
 http://incubator.apache.org/npanday/docs/1.4.0-incubating/plugins/maven-compile-plugin/generate-assembly-info-mojo.html
 In there, there is no information about the assemblyInfo paramter.
 It should contain an example that using the following, inside a pom.xml:
 {code}
 configuration
 ...
 assemblyInfo
 key1FOO/key1
 key2FOO/key2
 /assemblyInfo
 ...
 /configuration
 {code}
 results into the following in the generated pom.xml file:
 {code}
 ...
 [assembly: CustomStringAttribute(key1, FOO)]
 [assembly: CustomStringAttribute(key2, FOO)]
 ...
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-550) The .NET plugin execution framework should place plugin dependencies in a discreet directory instead of ${project.build.directory}


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

Brett Porter updated NPANDAY-550:
-

Fix Version/s: Backlog

 The .NET plugin execution framework should place plugin dependencies in a 
 discreet directory instead of ${project.build.directory}
 --

 Key: NPANDAY-550
 URL: https://issues.apache.org/jira/browse/NPANDAY-550
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Brett Porter
 Fix For: Backlog


 Currently these get copied to target for the MSBuild plugin (and others are 
 similar):
 * NPanday.Model.Pom.dll
 * NPanday.Plugin.dll
 * NPanday.Plugin.Loader.exe
 * NPanday.Plugin.Msbuild.dll
 * NPanday.Plugin.Runner.exe
 Probably  ${project.build.directory}/plugin-artifact-id or similar would make 
 sense.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-454) maven-compile-plugin: includeSources section has issues with the path delimiter


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

Brett Porter updated NPANDAY-454:
-

Fix Version/s: 1.5.0-incubating

 maven-compile-plugin: includeSources section has issues with the path 
 delimiter
 -

 Key: NPANDAY-454
 URL: https://issues.apache.org/jira/browse/NPANDAY-454
 Project: NPanday
  Issue Type: Bug
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
 Java version: 1.6.0_24
 Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
 Default locale: en_US, platform encoding: MacRoman
 OS name: mac os x version: 10.6.7 arch: x86_64 Family: mac
 Mono 2.6.7
 NPanday: 1.4.0-incubating
Reporter: Matthias Weßendorf
 Fix For: 1.5.0-incubating


 The pom.xml (sample) files in NPanday are using the following syntax to 
 include the AssemblyInfo.cs file:
 {code}
 includeSources
   includeSourceProperties\AssemblyInfo.cs/includeSource   
 /includeSources
 {code}
 However on Mac/Mono this seems to be ignored. Changing to this
 {code}
 includeSources
   includeSourceProperties/AssemblyInfo.cs/includeSource   
 /includeSources
 {code}
 make it working...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-607) Re-sync artifacts in addin can create unnecessary entries in the local repository


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

Brett Porter updated NPANDAY-607:
-

Fix Version/s: Backlog

 Re-sync artifacts in addin can create unnecessary entries in the local 
 repository
 -

 Key: NPANDAY-607
 URL: https://issues.apache.org/jira/browse/NPANDAY-607
 Project: NPanday
  Issue Type: Bug
  Components: Visual Studio Add-in
Affects Versions: 1.5.0-incubating
Reporter: Brett Porter
 Fix For: Backlog


 I've noticed that there is a harmless bug where resyncing copies files into 
 the local repository in the wrong location in addition to the right one (e.g. 
 System.Net.Http/System.Net.Http4.0.0.0-.dll instead of 
 System.Net.Http/4.0.0.0/System.Net.Http-4.0.0.0.dll)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (NPANDAY-611) Linux build of plugins broken by \ in tests


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

Brett Porter updated NPANDAY-611:
-

Fix Version/s: 1.5.0-incubating

 Linux build of plugins broken by \ in tests
 ---

 Key: NPANDAY-611
 URL: https://issues.apache.org/jira/browse/NPANDAY-611
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: David Akehurst
 Fix For: 1.5.0-incubating


 Building the maven plugins on linux breaks when compiling the tests because 
 of a few backslashes in the tests.
 not been able to test this on windows, but the attached comment of svn diff 
 fixes it for linux.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (NPANDAY-611) Linux build of plugins broken by \ in tests