[jira] [Commented] (NPANDAY-537) Add dotnet-windows-executable packaging
[ 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] [Updated] (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 ] Lars Corneliussen updated NPANDAY-402: -- Summary: Add support to automatically attach and resolve PDB-symbols (was: Add support to automatically attach and resolve PDB-symbols and Code-Documentation (comment.xml) ) 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 * 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] [Created] (NPANDAY-634) Automatically attach (and resolve) VS Code Documentation files (comment.xml)
Lars Corneliussen created NPANDAY-634: - Summary: Automatically attach (and resolve) VS Code Documentation files (comment.xml) Key: NPANDAY-634 URL: https://issues.apache.org/jira/browse/NPANDAY-634 Project: NPanday Issue Type: Improvement Components: Maven Plugins Affects Versions: 1.5.0-incubating Reporter: Lars Corneliussen Priority: Minor Fix For: Backlog With NPANDAY-402 we introduced attaching and resolving PDBs. Also handling Code-Documentation files should be an quite easy addition. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (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 ] Lars Corneliussen updated NPANDAY-402: -- Summary: Add support to automatically attach and resolve PDB-symbols (was: Add support to automatically attach and resolve PDB-symbols ) 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 * 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] [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=14105206#comment-14105206 ] Lars Corneliussen commented on NPANDAY-599: --- We talked about making i a per-project somehow, didn't we? [code] [07.08.2014 12:04:04] Lars Corneliussen: iirc somehow the deps were cached between reactor projects [07.08.2014 12:04:34] Lars Corneliussen: but I can't remember what happend then... if it failed, or if it just included pdbs you wouldn't want... [07.08.2014 12:06:07] Brett Porter (NPanday team): can see why it could be a problem, maybe better just to have the cache be mapped per project instead [07.08.2014 12:09:19] Lars Corneliussen: if per-project is available, it seems much more approprieate than per-lookup1 [07.08.2014 12:22:07] Brett Porter (NPanday team): no per project lookup, but we can do that in the maps [code] 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)
AW: Release 1.5.0 ??
I think we should just release it as it is and take it from there. The snapshot-version has been in use for quite a while now. Last issue to resolve would be https://issues.apache.org/jira/browse/NPANDAY-599 Brett, you talked about somehow caching the resolver per project. I think if that's done we're fine and can close 599 and thus 402. -Ursprüngliche Nachricht- Von: Brett Porter [mailto:br...@porterclan.net] Im Auftrag von Brett Porter Gesendet: Donnerstag, 21. August 2014 02:43 An: npanday-dev@incubator.apache.org Betreff: Re: Release 1.5.0 ?? 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] [Assigned] (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
]
Lars Corneliussen reassigned NPANDAY-454:
-
Assignee: Brett Porter (was: Lars Corneliussen)
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] [Assigned] (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 ] Lars Corneliussen reassigned NPANDAY-599: - Assignee: Brett Porter (was: Lars Corneliussen) 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] [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)
