[jira] [Commented] (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-tabpanel&focusedCommentId=14108711#comment-14108711 ] Brett Porter commented on NPANDAY-598: -- Hi [~lcorneliussen], basically what happened here was that the fix you'd applied got lost when I refactored. I noticed that, and reinstated it, and should now be working as before. However, I noted that this might not be the optimal solution in the long run - the scope is based on where it is instantiated rather than where it is used. Also, they are named as "caches", but they seem to be behaving as a way to collect information during a resolution run, that can be accessed after the resolution run, but are not to be used by subsequent resolution runs (hence the problem when retained where they accumulated information from previous resolutions). I don't think there is anything actionable here now - just wanted to add some information in case it's helpful for future reference. This is completely separate to NPANDAY-599, where we've also been discussing caching (which actually are keyed resolution caches for other scenarios), which I confusingly referenced this change before I understood what was happening there. > 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] [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-tabpanel&focusedCommentId=14106742#comment-14106742 ] Brett Porter commented on NPANDAY-599: -- I mixed up the tickets. The resolution cache that I changed was in NPANDAY-598. This issue was still present, but I fixed it during the investigation. > 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-525) Make sure UnifiedShellCommandExecutor works with BourneShell
[ https://issues.apache.org/jira/browse/NPANDAY-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter resolved NPANDAY-525. -- Resolution: Fixed Assignee: Brett Porter Fixed the tests for bash. > 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 >Assignee: Brett Porter > 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] [Resolved] (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 resolved NPANDAY-545. -- Resolution: Cannot Reproduce Assignee: Brett Porter When installing with the installer, it places it in the x86 directory for me, and sets the Addin file correctly. If you're still having an issue, feel free to reopen and we can work through the configuration that causes it. > 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 >Assignee: Brett Porter > 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 > > C:\Program > Files\NPanday\bin\NPanday.VisualStudio.Addin.dll > Workaround to manually edit the assembly path and add " (x86)". > > C:\Program Files > (x86)\NPanday\bin\NPanday.VisualStudio.Addin.dll -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (NPANDAY-585) Support future versions of Azure by making CSPACK selection use an expression
[ https://issues.apache.org/jira/browse/NPANDAY-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter resolved NPANDAY-585. -- Resolution: Fixed > Support future versions of Azure by making CSPACK selection use an expression > - > > Key: NPANDAY-585 > URL: https://issues.apache.org/jira/browse/NPANDAY-585 > Project: NPanday > Issue Type: Improvement > Components: Maven Plugins >Affects Versions: 1.5.0-incubating >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 1.5.0-incubating > > > See the comment on NPANDAY-571 - currently the supported versions are > hardcoded, but there is an opportunity to use an expression if that can be > supported -- 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-tabpanel&focusedCommentId=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] [Commented] (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-tabpanel&focusedCommentId=14106489#comment-14106489
]
Brett Porter commented on NPANDAY-598:
--
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] [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] [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-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-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-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}
>
> Properties\AssemblyInfo.cs
>
> {code}
> However on Mac/Mono this seems to be ignored. Changing to this
> {code}
>
> Properties/AssemblyInfo.cs
>
> {code}
> make it working...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (NPANDAY-635) Unable to build netplugins on Mono 3.6.0
Brett Porter created NPANDAY-635:
Summary: Unable to build netplugins on Mono 3.6.0
Key: NPANDAY-635
URL: https://issues.apache.org/jira/browse/NPANDAY-635
Project: NPanday
Issue Type: Bug
Environment: Mac OS X Mavericks, Mono 3.6.0 from homebrew, Maven
3.2.3, Java 1.7.0_65
Reporter: Brett Porter
I get this error when doing the mojo generation:
{code}
[ERROR] | [ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidOperationException:
There was an error reflecting type 'NPanday.Model.Pom.Model'. --->
System.InvalidOperationException: There was an error reflecting field
'ciManagement'. ---> System.InvalidOperationException: There was an error
reflecting type 'NPanday.Model.Pom.CiManagement'. --->
System.InvalidOperationException: There was an error reflecting field
'notifiers'. ---> System.InvalidOperationException: There was an error
reflecting type 'NPanday.Model.Pom.Notifier'. --->
System.InvalidOperationException: There was an error reflecting field
'configuration'. ---> System.InvalidOperationException: There was an error
reflecting type 'NPanday.Model.Pom.NotifierConfiguration'. --->
System.InvalidOperationException: There was an error reflecting field 'Any'.
---> System.InvalidOperationException: The element Any has been attributed with
an XmlAnyElementAttribute and a namespace '', but no name. When a namespace is
supplied, a name is also required. Supply a name or remove the namespace.
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportAnyElementInfo
(System.String defaultNamespace, System.Xml.Serialization.XmlReflectionMember
rmember, System.Xml.Serialization.XmlTypeMapMemberElement member,
System.Xml.Serialization.XmlAttributes atts) [0x0] in :0
[ERROR] | at System.Xml.Serialization.XmlReflectionImporter.CreateMapMember
(System.Type declaringType, System.Xml.Serialization.XmlReflectionMember
rmember, System.String defaultNamespace) [0x0] in :0
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportClassMapping
(System.Xml.Serialization.TypeData typeData,
System.Xml.Serialization.XmlRootAttribute root, System.String defaultNamespace)
[0x0] in :0
[ERROR] | --- End of inner exception stack trace ---
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportClassMapping
(System.Xml.Serialization.TypeData typeData,
System.Xml.Serialization.XmlRootAttribute root, System.String defaultNamespace)
[0x0] in :0
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping
(System.Xml.Serialization.TypeData typeData,
System.Xml.Serialization.XmlRootAttribute root, System.String defaultNamespace)
[0x0] in :0
[ERROR] | --- End of inner exception stack trace ---
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping
(System.Xml.Serialization.TypeData typeData,
System.Xml.Serialization.XmlRootAttribute root, System.String defaultNamespace)
[0x0] in :0
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping (System.Type
type, System.Xml.Serialization.XmlRootAttribute root, System.String
defaultNamespace) [0x0] in :0
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportElementInfo (System.Type
cls, System.String defaultName, System.String defaultNamespace, System.Type
defaultType, System.Xml.Serialization.XmlTypeMapMemberElement member,
System.Xml.Serialization.XmlAttributes atts) [0x0] in :0
[ERROR] | at System.Xml.Serialization.XmlReflectionImporter.CreateMapMember
(System.Type declaringType, System.Xml.Serialization.XmlReflectionMember
rmember, System.String defaultNamespace) [0x0] in :0
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportClassMapping
(System.Xml.Serialization.TypeData typeData,
System.Xml.Serialization.XmlRootAttribute root, System.String defaultNamespace)
[0x0] in :0
[ERROR] | --- End of inner exception stack trace ---
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportClassMapping
(System.Xml.Serialization.TypeData typeData,
System.Xml.Serialization.XmlRootAttribute root, System.String defaultNamespace)
[0x0] in :0
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping
(System.Xml.Serialization.TypeData typeData,
System.Xml.Serialization.XmlRootAttribute root, System.String defaultNamespace)
[0x0] in :0
[ERROR] | --- End of inner exception stack trace ---
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping
(System.Xml.Serialization.TypeData typeData,
System.Xml.Serialization.XmlRootAttribute root, System.String defaultNamespace)
[0x0] in :0
[ERROR] | at
System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping (System.Type
type, System.Xml.Serialization.XmlRootAttribute root, System.String
defaultN
[jira] [Resolved] (NPANDAY-371) npanday install phase creates a zero byte library
[ https://issues.apache.org/jira/browse/NPANDAY-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter resolved NPANDAY-371. -- Resolution: Cannot Reproduce Assignee: Brett Porter Unable to reproduce this issue - and realise it is still very old. If anyone spots it again with a more recent version, please reopen. I did look at the differences in the code between the install plugin in 1.2.1 and 1.3 - the only change was the addition of one logging line, so it seems the cause was elsewhere. > npanday install phase creates a zero byte library > - > > Key: NPANDAY-371 > URL: https://issues.apache.org/jira/browse/NPANDAY-371 > Project: NPanday > Issue Type: Bug > Components: Maven Plugins >Affects Versions: 1.2.1, 1.4-incubating > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_22 > Java home: C:\Program Files\Java\jdk1.6.0_22\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Khai Do >Assignee: Brett Porter > Fix For: 1.5.0-incubating > > Attachments: console.log, file-list.log, pom-bad.xml, pom-good.xml > > > I'm having a problem with NPanday. I created a simple C sharp project using > the npanday archetype. I am able to build it without any failures. The > problem is that when I run install phase it spits out a bad library file, the > the output > dll is zero bytes. It also gets installed to the local repository as a 0 > byte file. However when I execute the compile, test, or package phases the > output dll file is good, it's not empty and it has all the version info in > it. I do run a clean before every build. > Here's some additional info. I have tried npanday ver 1.2.1, > 1.2.2-incubating,and 1.3-incubating. I got the same result from all three. > I'm also using maven ver 2.2.1. -- 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-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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=14106281#comment-14106281
]
Brett Porter commented on NPANDAY-227:
--
This is already implemented as {{**/*.resx}} in the base directory, but wasn't
being used due to the bug found in NPANDAY-467.
Once implemented, it can cause some backwards compatibility issues due to
picking up unexpected resx files, as [~lcorneliussen] identified in the
comments of the linked issue (which is now NPANDAY-162). As also highlighted in
those comments, using the elements is not appropriate as those are
copied verbatim into the assembly.
Therefore, adding a {{}} configuration element to the plugin
configuration, including a directory, includes and excludes. If none is given,
and there are no embeddedResource configuration elements, then the default will
be {{src/main/resgen/**}}
> 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
>Priority: Minor
> Fix For: Backlog
>
>
> 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-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-tabpanel&focusedCommentId=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] [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-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-tabpanel&focusedCommentId=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] [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] [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] [Commented] (NPANDAY-537) Add dotnet-windows-executable packaging
[ https://issues.apache.org/jira/browse/NPANDAY-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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:
> ...
>
> npanday.repo.0
> {LDAP user name}
> {encrypted password}
>
> ...
> 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] [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:
> ...
>
> npanday.repo.0
> {LDAP user name}
> {encrypted password}
>
> ...
> 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] [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] [Closed] (NPANDAY-610) ArtifactType as an optional configuration argument
[ https://issues.apache.org/jira/browse/NPANDAY-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed NPANDAY-610. Resolution: Fixed Assignee: Brett Porter Applied, thanks > ArtifactType as an optional configuration argument > -- > > Key: NPANDAY-610 > URL: https://issues.apache.org/jira/browse/NPANDAY-610 > Project: NPanday > Issue Type: Improvement > Components: Maven Plugins >Affects Versions: 1.5.0-incubating >Reporter: David Akehurst >Assignee: Brett Porter > Fix For: 1.5.0-incubating > > Attachments: patch.txt > > > For one of my uses of npanday I need to be able to define the artifactType > using a configuration argument. (I.e. it is not defined by the package type > of the pom). > I have implemented this, and attached an svn diff of the trunk to this ticket. > Could we get it into the 1.5.0 release please. -- 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 {{}} 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 {{}} sections, one
> before {{}} 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] [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 {{}} 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 {{}} sections, one
> before {{}} 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-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] [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-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] [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)
[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-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-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] [Closed] (NPANDAY-393) NPanday ITs still need ildasm (or disasm for Mono) to be on the PATH
[ 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)
[jira] [Commented] (NPANDAY-525) Make sure UnifiedShellCommandExecutor works with BourneShell
[ https://issues.apache.org/jira/browse/NPANDAY-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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}\Some\Custom\Path{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 ArrayList()
> : executableConfig.getExecutionPaths();
>
> +executableConfig.setExecutionPaths( executablePaths );
> +
> if ( netHome != null )
> {
> getLogger().info( "NPANDAY-066-014: Found executable path in
> pom: Path = " + netHome.getAbsolutePath() );
> @@ -92,8 +94,6 @@
> }
>
>
> -executableConfig.setExecutionPaths( executablePaths );
> -
> final ExecutableCapability executableCapability =
> capabilityMatcher.matchExecutableCapabilityFor(
> executableRequirement );
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (NPANDAY-632) NPE when using netHome maven configuration
[
https://issues.apache.org/jira/browse/NPANDAY-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}\Some\Custom\Path{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 ArrayList()
> : executableConfig.getExecutionPaths();
>
> +executableConfig.setExecutionPaths( executablePaths );
> +
> if ( netHome != null )
> {
> getLogger().info( "NPANDAY-066-014: Found executable path in
> pom: Path = " + netHome.getAbsolutePath() );
> @@ -92,8 +94,6 @@
> }
>
>
> -executableConfig.setExecutionPaths( executablePaths );
> -
> final ExecutableCapability executableCapability =
> capabilityMatcher.matchExecutableCapabilityFor(
> executableRequirement );
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (NPANDAY-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-tabpanel&focusedCommentId=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-624) NPE in ilMerge
[
https://issues.apache.org/jira/browse/NPANDAY-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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']
> [WARN
[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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [Commented] (NPANDAY-525) Make sure UnifiedShellCommandExecutor works with BourneShell
[
https://issues.apache.org/jira/browse/NPANDAY-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14060269#comment-14060269
]
Brett Porter commented on NPANDAY-525:
--
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] [Commented] (NPANDAY-402) Add support to automatically attach and resolve PDB-symbols and Code-Documentation (comment.xml)
[ https://issues.apache.org/jira/browse/NPANDAY-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14059840#comment-14059840 ] Brett Porter commented on NPANDAY-402: -- Ok, so after NPANDAY-599 is reviewed, we can close this out. I moved the other list-dependencies issues to separate bugs. > Add support to automatically attach and resolve PDB-symbols and > Code-Documentation (comment.xml) > - > > 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] [Updated] (NPANDAY-596) Error: When running require the first time, PDBs will not be part of the result (ListDependenciesMojo)
[ https://issues.apache.org/jira/browse/NPANDAY-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated NPANDAY-596: - Fix Version/s: (was: 1.5.0-incubating) Backlog > 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)
[ 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] [Updated] (NPANDAY-600) When running list-dependencies on a pom, no pdbs are resolved (from dll dependencies)
[ 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)
[ 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] [Resolved] (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: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
[ 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] [Resolved] (NPANDAY-499) Make configuration for compiler-plugins and executable-plugins more flexible
[
https://issues.apache.org/jira/browse/NPANDAY-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter resolved NPANDAY-499.
--
Resolution: Fixed
Fix Version/s: (was: Backlog)
1.5.0-incubating
Assignee: Lars Corneliussen (was: Brett Porter)
Marking fixed with the work done to date.
Agree there are more improvements that could be made here - there is an awful
lot of cut and paste needed to provide new versions that don't have big
differences, and no smarts about how the frameworks build up. It'd be good for
the framework to be able to pick up on the tools version and visual studio
version where applicable. We can defer those to other issues though.
> Make configuration for compiler-plugins and executable-plugins more flexible
>
>
> Key: NPANDAY-499
> URL: https://issues.apache.org/jira/browse/NPANDAY-499
> Project: NPanday
> Issue Type: Improvement
> Components: Maven Plugins
>Reporter: Lars Corneliussen
>Assignee: Lars Corneliussen
> Fix For: 1.5.0-incubating
>
>
> Currently all configuration for compiler-plugins and executable-plugins are
> located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
> h3. Design
> * (/) Plugins should be able to contribute their own configurations
> (for example: the test-plugin should specify where to find nunit; currently
> it is specified in dotnet-core)
> * Mojos should accept additional configurations as parameters (if
> probingPaths do not match, or a new version has not yet made it into NPanday)
> * It should be configurable per 'plugin' and overrideable through a Mojo
> param / project-level-property, whether or not NPanday should try to run the
> command from the %PATH%
> h3. Location of the right executable
> * Use 'identifier' to instead of 'profile' for locating the correct
> executable-plugin; still allowing profile for customizing.
> * Enable version ranges for matching of versions in executables and compilers
> for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}]
> or {{[2.0,3.0)}}
> * (/) It should be possible to configure executableVersion additionally to
> vendorVersion and frameworkVersion (for example in order to locate path's for
> Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
> h3. Path detection
> * (/) Enable filtering in configuration files, supporting Windows Registry,
> Environment Variables and (!) project properties
> h3. Naming and overall structure
> * (/) (A) Mojo comes with *Requirement and *Config, (B) Repository delivers
> *Capability which is based on *Plugins; Then we try to match (A) with (B).
> * Rebrand 'plugin' to 'capability-configuration', hence
> CompilerExecutableCapabilityConfiguration (?)
> * Rename 'vendor' and 'vendorVersion' to 'frameworkVendor' and
> 'frameworkVendorVersion' for better clarity (?)
> * Join executable-plugins and compiler-plugins into one model (MDO + base
> classes for Capability
> * distinguish three types of executables:
> ** *VendorExecutable* (is provided by the framework vendor
> ** *CompilerExecutable* (is also provided by the framwork vendor, but has
> some extra requirements/capabilities
> ** *ThirdpartyExecutable* (is provided by a third party, hence neither
> NPanday nor the vendor; adds 'probingPaths' and 'executableVersion')
> h3. Execution and Mojo Interaction
> * Refactor ExecutableRequirement.ctor to accept VendorRequirment +
> executableIdentifier, executableVersion and executableProfile.
> * Remove get/setCommands() from ExecutableConfig, and require them to be
> passed in to NetExecutable#execute() as parameter ->
> NetExecutable#execute(List commands) / filtering will happen inside
> * Provide utility methods, that handle exception conversions for Mojos (wrap
> PlatformUnsupportedException and ExecutionException) in
> MojoExecutionExceptions
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (NPANDAY-622) NPE - compile:testCompile
[
https://issues.apache.org/jira/browse/NPANDAY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter resolved NPANDAY-622.
--
Resolution: Fixed
Fix Version/s: 1.5.0-incubating
Assignee: Brett Porter
> 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
>Assignee: Brett Porter
> Fix For: 1.5.0-incubating
>
>
> As compile:compile cannot be skipped, needed to use
> custom-lifecycle-maven-plugin as the lifecycle extension to use tlbimp in
> createing the library.
>
> org.apache.npanday.plugins
>
> custom-lifecycle-maven-plugin
> true
>
> Following that, to add a test process tying to add
>
> org.apache.npanday.plugins
> maven-compile-plugin
>
> 3.0
>
>
>
> testing
>
>
> process-test-sources
> testCompile
>
>
>
>
>
>
> [INFO] [compile:testCompile {execution: testing}]
> [INFO] NPANDAY-148-009: Took 11ms to resolve dependencies for
> group:art:library:8.1.0-0-SNAPSHOT with filter org
> .apache.maven.artifact.resolver.filter.AndArtifactFilter@4f14e777
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> npanday.assembler.impl.AssemblerContextImpl.getClassExtensionFor(AssemblerContextImpl.java:190)
> at
> npanday.plugin.compile.AbstractCompilerMojo.getLanguageFileExtension(AbstractCompilerMojo.java:1471)
> at
> npanday.plugin.compile.TestCompilerMojo.getCompilerConfig(TestCompilerMojo.java:104)
> at
> npanday.plugin.compile.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1186)
> at
> npanday.plugin.compile.TestCompilerMojo.execute(TestCompilerMojo.java:59)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO]
>
> It appears there is some dependency in testCompile that r
[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: 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] [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-tabpanel&focusedCommentId=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] [Commented] (NPANDAY-622) NPE - compile:testCompile
[
https://issues.apache.org/jira/browse/NPANDAY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
>
> org.apache.npanday.plugins
>
> custom-lifecycle-maven-plugin
> true
>
> Following that, to add a test process tying to add
>
> org.apache.npanday.plugins
> maven-compile-plugin
>
> 3.0
>
>
>
> testing
>
>
> process-test-sources
> testCompile
>
>
>
>
>
>
> [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.mainWithEx
[jira] [Updated] (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 updated NPANDAY-505:
-
Attachment: 0001-NPANDAY-505-support-wildcards-in-registry-elements.patch
Didn't end up using this, so left it out, but might come in handy again in
future. Attachment contains a patch to the WinRegistry to support searching
some very basic wildcards (e.g. iterating the Windows SDK versions available).
> 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
>
> Attachments:
> 0001-NPANDAY-505-support-wildcards-in-registry-elements.patch
>
>
> 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}
> ...
>
> MICROSOFT
> 3.0
>
>
> 3.0
> C:\Windows\Microsoft.NET\Framework64\v3.0
> C:\Program Files\Microsoft.NET\SDK\v2.0
> 64bit\
>
>
> C:\Windows\Microsoft.NET\Framework64\v2.0.50727
> C:\Program Files\Microsoft.NET\SDK\v2.0
> 64bit\bin
>
>
>
>
> ...
> {code}
> {code:title=components\dotnet-core\src\main\resources\META-INF\npanday\npanday-settings.xml}
> ...
>
> ...
>
> MICROSOFT
> 3.0
>
>
>
> AMD64
> 3.0
>
>
>
> ${env.WINDIR}\Microsoft.NET\Framework64\v3.0
>
>
>
>
> ${HKLM\Software\Microsoft\.NETFramework@sdkInstallRootv2.0"}
> ${HKLM\SOFTWARE\Microsoft\Microsoft
> SDKs\.NETFramework\v2.0@InstallationFolder}
>
> ${env.ProgramFiles}\Microsoft.NET\SDK\v2.0
> ${env.ProgramFiles}\Microsoft
> SDKs\Windows\v6.0A\bin
> ${env.ProgramFilesX86}(@"Microsoft
> SDKs\Windows\v6.0A\bin"}
>
>
>
>
> ${env.WINDIR}\Microsoft.NET\Framework64\v2.0.50727
>
>
>
>
>
>
>
> ...
>
> ...
> {code}
> Both registry access with ${HKLM*}, ${HKCU*}, ${HKEY_LOCAL_MACHINE*},
> ${HKEY_CURRENT_USER*} and ${env.*} should work. I'd suggest to let
> ${env.ProgramFilesX86} fall back to ${env.ProgramFiles} for non-64-bit - (add
> an item to the properties in {{ContextAwareModelInterpolator}})
--
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] [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-tabpanel&focusedCommentId=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] [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] [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] [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-tabpanel&focusedCommentId=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] [Resolved] (NPANDAY-560) [regression to NPANDAY-231] Resolve attached *.exe.config / or any other known attachment
[
https://issues.apache.org/jira/browse/NPANDAY-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter resolved NPANDAY-560.
--
Resolution: Won't Fix
Assignee: Brett Porter
As the TODO indicated, and per NPANDAY-247, this wasn't really complete.
Suggest leaving it out, and if it's needed in future, follow through on that
ticket and perhaps follow the same approach as was used for PDBs, etc.
> [regression to NPANDAY-231] Resolve attached *.exe.config / or any other
> known attachment
> -
>
> Key: NPANDAY-560
> URL: https://issues.apache.org/jira/browse/NPANDAY-560
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
>Affects Versions: 1.5.0-incubating
>Reporter: Lars Corneliussen
>Assignee: Brett Porter
> Labels: attachments, dependencies
> Fix For: 1.5.0-incubating
>
>
> Code that got removed
> {code}
> if ( !ArtifactTypeHelper.isDotnetExecutableConfig( type ) ||
> !dotnetFile.exists() )// TODO: Generalize to any attached artifact
> {
> logger.warning( "NPANDAY-180-018: Not found in local
> repository, now retrieving artifact from wagon:"
> + assembly.getId()
> + ", Failed Path Check = " +
> dotnetFile.getAbsolutePath());
> try
> {
> artifactResolver.resolve( assembly,
> artifactRepositories,
> localArtifactRepository
> );
> projectDependency.setResolved( true );
>
> if ( assembly != null &&
> assembly.getFile().exists() )
> {
> dotnetFile.getParentFile().mkdirs();
> FileUtils.copyFile( assembly.getFile(),
> dotnetFile );
> assembly.setFile( dotnetFile );
> }
> }
> catch ( ArtifactNotFoundException e )
> {
> logger.log(Level.SEVERE, "NPANDAY-180-0201: Error
> resolving artifact. Reason:", e);
> throw new ProjectDaoException(
>"NPANDAY-180-020: Problem
> in resolving artifact: Artifact = "
>+ assembly.getId()
>+ ", Message = " +
> e.getMessage(), e );
> }
> catch ( ArtifactResolutionException e )
> {
> logger.log( Level.SEVERE, "NPANDAY-180-019:
> Problem in resolving artifact: Artifact = "
> + assembly.getId()
> + ", Message = " +
> e.getMessage(), e );
> throw new ProjectDaoException(
>"NPANDAY-180-019: Problem
> in resolving artifact: Artifact = "
>+ assembly.getId()
>+ ", Message = " +
> e.getMessage(), e );
> }
> }
> artifactDependencies.add( assembly );
> {code}
--
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() )
> {
> Pr
[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-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}
> ...
>
> MICROSOFT
> 3.0
>
>
> 3.0
> C:\Windows\Microsoft.NET\Framework64\v3.0
> C:\Program Files\Microsoft.NET\SDK\v2.0
> 64bit\
>
>
> C:\Windows\Microsoft.NET\Framework64\v2.0.50727
> C:\Program Files\Microsoft.NET\SDK\v2.0
> 64bit\bin
>
>
>
>
> ...
> {code}
> {code:title=components\dotnet-core\src\main\resources\META-INF\npanday\npanday-settings.xml}
> ...
>
> ...
>
> MICROSOFT
> 3.0
>
>
>
> AMD64
> 3.0
>
>
>
> ${env.WINDIR}\Microsoft.NET\Framework64\v3.0
>
>
>
>
> ${HKLM\Software\Microsoft\.NETFramework@sdkInstallRootv2.0"}
> ${HKLM\SOFTWARE\Microsoft\Microsoft
> SDKs\.NETFramework\v2.0@InstallationFolder}
>
> ${env.ProgramFiles}\Microsoft.NET\SDK\v2.0
> ${env.ProgramFiles}\Microsoft
> SDKs\Windows\v6.0A\bin
> ${env.ProgramFilesX86}(@"Microsoft
> SDKs\Windows\v6.0A\bin"}
>
>
>
>
> ${env.WINDIR}\Microsoft.NET\Framework64\v2.0.50727
>
>
>
>
>
>
>
> ...
>
> ...
> {code}
> Both registry access with ${HKLM*}, ${HKCU*}, ${HKEY_LOCAL_MACHINE*},
> ${HKEY_CURRENT_USER*} and ${env.*} should work. I'd suggest to let
> ${env.ProgramFilesX86} fall back to ${env.ProgramFiles} for non-64-bit - (add
> an item to the properties in {{ContextAwareModelInterpolator}})
--
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-tabpanel&focusedCommentId=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}
> ...
>
> MICROSOFT
> 3.0
>
>
> 3.0
> C:\Windows\Microsoft.NET\Framework64\v3.0
> C:\Program Files\Microsoft.NET\SDK\v2.0
> 64bit\
>
>
> C:\Windows\Microsoft.NET\Framework64\v2.0.50727
> C:\Program Files\Microsoft.NET\SDK\v2.0
> 64bit\bin
>
>
>
>
> ...
> {code}
> {code:title=components\dotnet-core\src\main\resources\META-INF\npanday\npanday-settings.xml}
> ...
>
> ...
>
> MICROSOFT
> 3.0
>
>
>
> AMD64
> 3.0
>
>
>
> ${env.WINDIR}\Microsoft.NET\Framework64\v3.0
>
>
>
>
> ${HKLM\Software\Microsoft\.NETFramework@sdkInstallRootv2.0"}
> ${HKLM\SOFTWARE\Microsoft\Microsoft
> SDKs\.NETFramework\v2.0@InstallationFolder}
>
> ${env.ProgramFiles}\Microsoft.NET\SDK\v2.0
> ${env.ProgramFiles}\Microsoft
> SDKs\Windows\v6.0A\bin
> ${env.ProgramFilesX86}(@"Microsoft
> SDKs\Windows\v6.0A\bin"}
>
>
>
>
> ${env.WINDIR}\Microsoft.NET\Framework64\v2.0.50727
>
>
>
>
>
>
>
> ...
>
> ...
> {code}
> Both registry access with ${HKLM*}, ${HKCU*}, ${HKEY_LOCAL_MACHINE*},
> ${HKEY_CURRENT_USER*} and ${env.*} should work. I'd suggest to let
> ${env.ProgramFilesX86} fall back to ${env.ProgramFiles} for non-64-bit - (add
> an item to the properties in {{ContextAwareModelInterpolator}})
--
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] [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-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] [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] [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] [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] [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-tabpanel&focusedCommentId=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");
> ..
[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-tabpanel&focusedCommentId=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}
> ...
>
> MICROSOFT
> 3.0
>
>
> 3.0
> C:\Windows\Microsoft.NET\Framework64\v3.0
> C:\Program Files\Microsoft.N
[jira] [Resolved] (NPANDAY-570) Unable to build NPanday due to missing npanday-settings.xml
[ 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
[jira] [Commented] (NPANDAY-570) Unable to build NPanday due to missing npanday-settings.xml
[ https://issues.apache.org/jira/browse/NPANDAY-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052375#comment-14052375 ] Brett Porter commented on NPANDAY-570: -- Thanks for the patch Victor. However, the comment about "bootstrap" there was really "before you've ever built the Settings code", which isn't done in the bootstrap. Currently it's built in .NET, which uses a lifecycle that will try to run the settings generation unless it's skipped, which causes problems. It's also hard to get the appropriate dependencies so that it is built first. There are two ways that particular problem can be addressed: # ship 1.5.0-incubating, and use that as the "bootstrap" version, so NPanday can build itself with an older version of NPanday. # rewrite the settings code in Java, which is discussed in NPANDAY-505 For the specific issue reported here, I've removed the requirement that npanday-settings.xml exist to build. That way, it'll just fallback to the PATH if it can't find what it needs, making it easier to bootstrap (say, from a VS Command Line), and then npanday-settings will be generated in due course for other projects (like the ITs). > 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 > 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] > -
[jira] [Resolved] (NPANDAY-231) Remove RDF repository and model
[ 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-622) NPE - compile:testCompile
[
https://issues.apache.org/jira/browse/NPANDAY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}
initialize
{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.
>
> org.apache.npanday.plugins
>
> custom-lifecycle-maven-plugin
> true
>
> Following that, to add a test process tying to add
>
> org.apache.npanday.plugins
> maven-compile-plugin
>
> 3.0
>
>
>
> testing
>
>
> process-test-sources
> testCompile
>
>
>
>
>
>
> [INFO] [compile:testCompile {execution: testing}]
> [INFO] NPANDAY-148-009: Took 11ms to resolve dependencies for
> group:art:library:8.1.0-0-SNAPSHOT with filter org
> .apache.maven.artifact.resolver.filter.AndArtifactFilter@4f14e777
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> npanday.assembler.impl.AssemblerContextImpl.getClassExtensionFor(AssemblerContextImpl.java:190)
> at
> npanday.plugin.compile.AbstractCompilerMojo.getLanguageFileExtension(AbstractCompilerMojo.java:1471)
> at
> npanday.plugin.compile.TestCompilerMojo.getCompilerConfig(TestCompilerMojo.java:104)
> at
> npanday.plugin.compile.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1186)
> at
> npanday.plugin.compile.TestCompilerMojo.execute(TestCompilerMojo.java:59)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO]
>
> It appears there is some dependency in t
[jira] [Commented] (NPANDAY-624) NPE in ilMerge
[
https://issues.apache.org/jira/browse/NPANDAY-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}
C:\Path\To\ILMerge\bin
{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: p
[jira] [Resolved] (NPANDAY-623) Support reactor reference to other modules at compile phase
[ https://issues.apache.org/jira/browse/NPANDAY-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter resolved NPANDAY-623. -- Resolution: Won't Fix Resolving per last comment - thanks for working through this, and let us know if you'd like to follow up the documentation aspect. > Support reactor reference to other modules at compile phase > > > Key: NPANDAY-623 > URL: https://issues.apache.org/jira/browse/NPANDAY-623 > Project: NPanday > Issue Type: Bug > Components: Maven Plugins >Affects Versions: 1.4-incubating, 1.5.0-incubating > Environment: Maven 2.2.1 >Reporter: Greg Domjan > Attachments: example.zip > > > When building multiple artifacts with dependencies in the reactor it appears > to be currently required that you build to the "install" phase. > This can actually be a bug - see > http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html > Even if not a bug, this goes against some common practices such as used in > the release-plugin which attempts to test the build by running all projects > to compile stage only. > In comparison the maven reactor allows for dependency resolution in Java JAR > dependencies as soon as the compile phase is run. It does this by pointing > the artifact file to the local class folder. > NPanday could take similar action and point the file to the local target file > as soon as compile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [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-tabpanel&focusedCommentId=14047436#comment-14047436 ] Brett Porter commented on NPANDAY-618: -- That's right, it doesn't capture the details (it replaces the dependency artifact with the interop DLL). This has a few limitations, both with the arguments and that it has to regenerate it for every build rather than caching it in the local repository. I agree that having a plugin that could generate and publish it as an artifact and then depend directly on that would be a better alternative. > 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-504) NPanday installer msi does not properly install when user home directory is on network
[ https://issues.apache.org/jira/browse/NPANDAY-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated NPANDAY-504: - Fix Version/s: Backlog > NPanday installer msi does not properly install when user home directory is > on network > -- > > Key: NPANDAY-504 > URL: https://issues.apache.org/jira/browse/NPANDAY-504 > Project: NPanday > Issue Type: Bug > Components: Visual Studio Add-in >Affects Versions: 1.4-incubating > Environment: Windows 7, VS 2010 >Reporter: Alan Baldwin >Priority: Minor > Labels: addin, installer, > Fix For: Backlog > > > My company has my home directory on a network share. When I install NPanday > 1.4-incubating from the msi, I get the following: > Failed to open XML file \\[network_share_name]\Home$\[username]\Visual Studio > 2010\Addins\NPanday.VisualStudio.Addin, system error: -2147024891 > It seems to be a permissions issue on the network share. When I run the > installer under an account that has a local HD home folder, it works fine. > Related to https://issues.apache.org/jira/browse/NPANDAY-194 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NPANDAY-504) NPanday installer msi does not properly install when user home directory is on network
[ https://issues.apache.org/jira/browse/NPANDAY-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045716#comment-14045716 ] Brett Porter commented on NPANDAY-504: -- This error is access denied, so probably should be installing for all users instead - though given addins are deprecated in VS 2013, converting to an extension package might be a better way to focus. In case anyone wants to make the improvement for the addin, try this info: http://www.mztools.com/articles/2011/MZ2011019.aspx http://www.mztools.com/articles/2008/MZ2008001.aspx > NPanday installer msi does not properly install when user home directory is > on network > -- > > Key: NPANDAY-504 > URL: https://issues.apache.org/jira/browse/NPANDAY-504 > Project: NPanday > Issue Type: Bug > Components: Visual Studio Add-in >Affects Versions: 1.4-incubating > Environment: Windows 7, VS 2010 >Reporter: Alan Baldwin >Priority: Minor > Labels: addin, installer, > Fix For: Backlog > > > My company has my home directory on a network share. When I install NPanday > 1.4-incubating from the msi, I get the following: > Failed to open XML file \\[network_share_name]\Home$\[username]\Visual Studio > 2010\Addins\NPanday.VisualStudio.Addin, system error: -2147024891 > It seems to be a permissions issue on the network share. When I run the > installer under an account that has a local HD home folder, it works fine. > Related to https://issues.apache.org/jira/browse/NPANDAY-194 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NPANDAY-572) When settings.xml already has a profiles section, configuring the remote repository from the AddIn creates an invalid settings file
[
https://issues.apache.org/jira/browse/NPANDAY-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045654#comment-14045654
]
Brett Porter commented on NPANDAY-572:
--
sorry for missing this - I'll double check. Did you confirm the right addin was
installed? Do you have any logging?
> 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 {{}} 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 {{}} sections, one
> before {{}} 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] [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: Backlog > 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 > 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] [Commented] (NPANDAY-620) Add Maven Artifact window doesn't resize/layout content to match change of window dialog size
[ https://issues.apache.org/jira/browse/NPANDAY-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045646#comment-14045646 ] Brett Porter commented on NPANDAY-620: -- Agree - adding to the backlog > Add Maven Artifact window doesn't resize/layout content to match change of > window dialog size > - > > Key: NPANDAY-620 > URL: https://issues.apache.org/jira/browse/NPANDAY-620 > Project: NPanday > Issue Type: Improvement > Components: Visual Studio Add-in >Affects Versions: 1.5.0-incubating > Environment: VS 2013 >Reporter: Greg Domjan >Priority: Minor > Labels: UI > Fix For: Backlog > > > Lists of artifacts can be quite long, being able to see a larger portion of > the list at once would be helpful. > The "Add Maven Artifact" window allows resizing but the content doesn't > resize to match. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (NPANDAY-620) Add Maven Artifact window doesn't resize/layout content to match change of window dialog size
[ https://issues.apache.org/jira/browse/NPANDAY-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated NPANDAY-620: - Fix Version/s: Backlog > Add Maven Artifact window doesn't resize/layout content to match change of > window dialog size > - > > Key: NPANDAY-620 > URL: https://issues.apache.org/jira/browse/NPANDAY-620 > Project: NPanday > Issue Type: Improvement > Components: Visual Studio Add-in >Affects Versions: 1.5.0-incubating > Environment: VS 2013 >Reporter: Greg Domjan >Priority: Minor > Labels: UI > Fix For: Backlog > > > Lists of artifacts can be quite long, being able to see a larger portion of > the list at once would be helpful. > The "Add Maven Artifact" window allows resizing but the content doesn't > resize to match. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NPANDAY-625) Support /debug:pdbonly compile option
[
https://issues.apache.org/jira/browse/NPANDAY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045642#comment-14045642
]
Brett Porter commented on NPANDAY-625:
--
Thanks Greg - are you interested in working through a patch for this?
> Support /debug:pdbonly compile option
> --
>
> Key: NPANDAY-625
> URL: https://issues.apache.org/jira/browse/NPANDAY-625
> Project: NPanday
> Issue Type: Improvement
> Components: Maven Plugins
>Affects Versions: 1.5.0-incubating
>Reporter: Greg Domjan
>
> Compiler mojo supports creating a pdb, however /debug+ is equivelant to
> /debug:full and can tend to cause decreased performance due to setting the
> DebuggableAttribute
> http://msdn.microsoft.com/en-us/library/8cw0bt21.aspx
> http://msdn.microsoft.com/en-us/library/9dd8z24x.aspx
> CompilerMojo:138
> if (isDebug)
> {
> params.add("/debug+");
> }
> Would like some way to choose
> params.add("/debug:pdbonly");
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (NPANDAY-569) local dependency and Npanday
[
https://issues.apache.org/jira/browse/NPANDAY-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045638#comment-14045638
]
Brett Porter commented on NPANDAY-569:
--
do you have any more information on this?
> local dependency and Npanday
>
>
> Key: NPANDAY-569
> URL: https://issues.apache.org/jira/browse/NPANDAY-569
> Project: NPanday
> Issue Type: Bug
>Reporter: François
>
> When adding the following a dll from a local .m2, NPanday tries to build the
> pom in the dependency repo. This leads to an error because it the
> configuration does not fit anymore. In the .m2 folder there is the
> corresponding dll. Here is the error, which is generate from the console
> …
> [INFO] --- maven-compile-plugin:1.4.0-incubating:initialize
> (default-initialize) @ ServiceTestConsole ---
> Jul 04, 2012 11:45:29 PM npanday.dao.impl.ProjectDaoImpl
> storeProjectAndResolveDependencies
> WARNING: NPANDAY-180-018: Not found in local repository, now retrieving
> artifact from
> wagon:org.openengsb.loom.csharp.common.bridge:ExampleDomainEventsInterfaces:dotnet-library:1.0.0-SNAPSHOT,
> Failed Path Check =
> C:\Users\User\Projekts\Example\target\ExampleDomainEventsInterfaces.dll
> Jul 04, 2012 11:45:29 PM
> npanday.dao.impl.ProjectDaoImplstoreProjectAndResolveDependencies
> WARNING: NPANDAY-180-018: Not found in local repository, now retrieving
> artifact from
> wagon:org.openengsb.loom.csharp.common.bridge:ExampleDomainInterfaces:dotnet-library:1.0.0-SNAPSHOT,
> Failed Path Check =
> C:\Users\User\Projekts\Example\target\ExampleDomainInterfaces.dll
> Jul 04, 2012 11:45:29 PM npanday.dao.impl.ProjectDaoImpl
> storeProjectAndResolveDependencies
> WARNING: NPANDAY-180-018: Not found in local repository, now retrieving
> artifact from
> wagon:org.openengsb.loom.csharp.common.bridge:Implementation:dotnet-library:1.0.0-SNAPSHOT,
> Failed Path Check = C:\Users\User\Projekts\Example\target\Implementation.dll
> Jul 04, 2012 11:45:29 PM npanday.dao.impl.ProjectDaoImpl
> storeProjectAndResolveDependencies
> WARNING: NPANDAY-180-018: Not found in local repository, now retrieving
> artifact from
> wagon:org.openengsb.loom.csharp.common.bridge:Interface:dotnet-library:1.0.0-SNAPSHOT,
> Failed Path Check = C:\Users\User\Projekts\Example\target\Interface.dll
> Jul 04, 2012 11:45:29 PM npanday.PathUtil getDotNetArtifact
> WARNING:
> NPANDAY-1005-0001: Error copying dependency
> org.openengsb.domain:org.openengsb.domain.example:wsdl:ExampleDomainEvents:3.0.0-SNAPSHOT:compile
> File
> C:\Users\User\.m2\repository\org\openengsb\domain\org.openengsb.domain.example\3.0.0-SNAPSHOT\org.openengsb.domain.example
> -3.0.0-SNAPSHOT-ExampleDomainEvents.jar does not exist
> Jul 04, 2012 11:45:29 PM npanday.PathUtil getDotNetArtifact
> WARNING:
> NPANDAY-1005-0001: Error copying dependency
> org.openengsb.domain:org.openengsb.domain.example:wsdl:ExampleDomainEvents:3.0.0-SNAPSHOT:compile
> File
> C:\Users\User\.m2\repository\org\openengsb\domain\org.openengsb.domain.example\3.0.0-SNAPSHOT\org.openengsb.domain.example
> -3.0.0-SNAPSHOT-ExampleDomainEvents.jar does not exist
> Jul 04, 2012 11:45:29 PM npanday.dao.impl.ProjectDaoImpl
> storeProjectAndResolveDependencies
> WARNING: NPANDAY-180-018: Not found in local repository, now retrieving
> artifact from
> wagon:org.openengsb.domain:org.openengsb.domain.example:wsdl:ExampleDomainEvents:3.0.0-SNAPSHOT,
> Failed Path Check =
> C:\Users\User\Projekts\Example\target\org.openengsb.domain.example.wsdl
> Jul 04, 2012 11:45:29 PM npanday.dao.ProjectFactory
> logAndVerifyProjectParameters
> WARNING: NPANDAY-180-003: Project Version is missing: Group Id =
> org.openengsb.labs.delegation, Artifact Id =
> org.openengsb.labs.delegation.service
> …
> The pom in the .m2 repo looks like the following:
> …
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> copy
> compile
>
> copy
>
>
>
>
> org.openengsb.domain
> org.openengsb.domain.example
> ExampleDomainEvents
> wsdl
> false
>
> ${project.build.directory}
> ExampleDomainEvents.wsdl
>
>
>
>
>
>
>
> org.openengsb.loom.csharp.common
> wsdltodll-maven-plugin
>
>
> ${project.build.directory}\ExampleDomainEvents.wsdl
> ExampleDomainEvents
>
>
>
> compile
>
> run
>
>
>
>
>
> org.codehaus.mojo
> build-helper-maven-plug
[jira] [Commented] (NPANDAY-615) Can't Build Library
[ https://issues.apache.org/jira/browse/NPANDAY-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045636#comment-14045636 ] Brett Porter commented on NPANDAY-615: -- I think we worked through this on the dev list - did you get it resolved? It seems to be that the extensions element is missing, but would need to check the whole POM to confirm > Can't Build Library > --- > > Key: NPANDAY-615 > URL: https://issues.apache.org/jira/browse/NPANDAY-615 > Project: NPanday > Issue Type: Bug > Components: Maven Plugins >Affects Versions: 1.5.0-incubating > Environment: Apache Maven 3.1.1 > (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 08:22:22-0700) > Maven home: D:\bin\Apache\apache-maven-3.1.1 > Java version: 1.7.0_51, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_51\jre > Default locale: en_US, platform encoding: utf-8 > OS name: "windows 8", version: "6.2", arch: "amd64", family: "windows" >Reporter: Eric Kolotyluk > Labels: newbie > > When I use the following in my pom.xml > net.kolotyluk.windows.elevate > elevate-common > 0.0.21-SNAPSHOT > dotnet-library > I get > [INFO] Scanning for projects... > [ERROR] The build could not read 1 project -> [Help 1] > [ERROR] > [ERROR] The project > net.kolotyluk.windows.elevate:elevate-common:0.0.21-SNAPSHOT > (D:\Users\Eric\Software\Project\Repositories\csharp-windows-elevate\elevate-common\pom.xml) > has 1 error > [ERROR] Unknown packaging: dotnet-library @ line 19, column 14 > Maybe this is a documentation problem, but I cannot figure out from the > documentation any way to correctly build a library. > Using dotnet-executable in my other project seems to > work fine, so I cannot understand what the problem is with dotnet-library -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NPANDAY-616) Newlines not stripped in AssemblyInfo.cs
[
https://issues.apache.org/jira/browse/NPANDAY-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045635#comment-14045635
]
Brett Porter commented on NPANDAY-616:
--
Thanks Eric. That should be a reasonably straightforward fix - are you
interested in putting together a patch or pull request?
> Newlines not stripped in AssemblyInfo.cs
>
>
> Key: NPANDAY-616
> URL: https://issues.apache.org/jira/browse/NPANDAY-616
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
>Affects Versions: 1.5.0-incubating
> Environment: Apache Maven 3.1.1
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 08:22:22-0700)
> Maven home: D:\bin\Apache\apache-maven-3.1.1
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_51\jre
> Default locale: en_US, platform encoding: utf-8
> OS name: "windows 8", version: "6.2", arch: "amd64", family: "windows"
>Reporter: Eric Kolotyluk
>
> When NPanday generates the AssemblyInfo.cs from the POM file, it injects
> text into AssemblyDescription("text"), including
> any newlines.
> While newlines are handled fine by other parts of Maven, .Net cannot handle
> them in AssemblyInfo.cs.
> The workaround is to remove the newlines from the POM, but this should not be
> necessary as it is unexpected behavior, and results in unnecessary
> troubleshooting.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (NPANDAY-619) Comments in pom.xml are removed when document is updated
[ https://issues.apache.org/jira/browse/NPANDAY-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045633#comment-14045633 ] Brett Porter commented on NPANDAY-619: -- Yes, that's a known issue with the tools used unfortunately. > Comments in pom.xml are removed when document is updated > > > Key: NPANDAY-619 > URL: https://issues.apache.org/jira/browse/NPANDAY-619 > Project: NPanday > Issue Type: Bug > Components: Visual Studio Add-in >Affects Versions: 1.5.0-incubating > Environment: VS 2013 >Reporter: Greg Domjan > Fix For: Backlog > > > Adding a Maven Artifact reference the pom.xml is updated and may be re > arranged heavily which is annoying, but losing comments is not > acceptable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (NPANDAY-619) Comments in pom.xml are removed when document is updated
[ https://issues.apache.org/jira/browse/NPANDAY-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated NPANDAY-619: - Fix Version/s: Backlog > Comments in pom.xml are removed when document is updated > > > Key: NPANDAY-619 > URL: https://issues.apache.org/jira/browse/NPANDAY-619 > Project: NPanday > Issue Type: Bug > Components: Visual Studio Add-in >Affects Versions: 1.5.0-incubating > Environment: VS 2013 >Reporter: Greg Domjan > Fix For: Backlog > > > Adding a Maven Artifact reference the pom.xml is updated and may be re > arranged heavily which is annoying, but losing comments is not > acceptable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NPANDAY-621) Add Maven Artifact window, provide options to filter and reduce local/remote list size
[ https://issues.apache.org/jira/browse/NPANDAY-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045628#comment-14045628 ] Brett Porter commented on NPANDAY-621: -- That makes sense. Are you interested in contributing to this? > Add Maven Artifact window, provide options to filter and reduce local/remote > list size > -- > > Key: NPANDAY-621 > URL: https://issues.apache.org/jira/browse/NPANDAY-621 > Project: NPanday > Issue Type: Improvement > Components: Visual Studio Add-in >Affects Versions: 1.5.0-incubating > Environment: VS 2013 >Reporter: Greg Domjan > Labels: UX > > It would be helpful for both local list and remote tree to be able to provide > a groupId or artifactId to filter the possible options listed. > It might also be helpful to be able to provide a version. -- This message was sent by Atlassian JIRA (v6.2#6252)
