[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=13257436#comment-13257436 ] Lars Corneliussen commented on NPANDAY-537: --- i don't think this should be a separate packaging. just a parameter... > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[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=13257437#comment-13257437 ] Lars Corneliussen commented on NPANDAY-537: --- both are windows executables > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[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=13257378#comment-13257378 ] Lars Corneliussen commented on NPANDAY-525: --- @John, would you like to test MAC/Linux compat for 1.5? > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-531) nunit must be on the path for test plugin to work
[ https://issues.apache.org/jira/browse/NPANDAY-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184847#comment-13184847 ] Lars Corneliussen commented on NPANDAY-531: --- we should allow wildcards for versions in then... > nunit must be on the path for test plugin to work > - > > Key: NPANDAY-531 > URL: https://issues.apache.org/jira/browse/NPANDAY-531 > Project: NPanday > Issue Type: Bug > Components: Maven Plugins >Reporter: Brett Porter > > we can easily locate NUnit on windows, as it is typically installed to > %PROGRAMFILES%\NUnit _version_\bin\net-2.0 > The test plugin should look at these (and use the best match for selected > version) instead of requiring it be on the PATH > (for mono, it will already be on the path) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-529) create internalsVisibleTo parameter list for the compiler plugin
[
https://issues.apache.org/jira/browse/NPANDAY-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183289#comment-13183289
]
Lars Corneliussen commented on NPANDAY-529:
---
I'm not sure how helpful that is. [assembly: *] can be i whatever file; you can
just add a file "InternalsVisibleTo.cs" and place them there...
Thing is, your solution is generic, but very limitted; what with multiple
parameters? bool/int/Enum-type parameters?
> create internalsVisibleTo parameter list for the compiler plugin
>
>
> Key: NPANDAY-529
> URL: https://issues.apache.org/jira/browse/NPANDAY-529
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
>Affects Versions: 1.4-incubating
>Reporter: Matthias Weßendorf
>Assignee: Matthias Weßendorf
> Attachments: NPANDAY-529, NPANDAY-529_appenedALL.patch
>
>
> Sometimes it is needed to "expose" internal interfaces (for mocking/testing)
> NMock is not allowing to create mocks out of internal interfaces:
> In order archive it, we need to have the following on the AssemblyInfo.cs file
> {code}
> [assembly: InternalsVisibleTo("Mocks")]
> [assembly: InternalsVisibleTo("MockObjects")]
> {code}
> However, since this is not always needed, it should be a parameter list in
> the pom.xml config section
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-528) The assemblyInfo parameter of the "generate-assembly-info" goal is not described
[
https://issues.apache.org/jira/browse/NPANDAY-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183198#comment-13183198
]
Lars Corneliussen commented on NPANDAY-528:
---
is "Adds a CustomStringAttribute for each key-value pair configured."
appropriate?
> The assemblyInfo parameter of the "generate-assembly-info" goal is not
> described
> -
>
> Key: NPANDAY-528
> URL: https://issues.apache.org/jira/browse/NPANDAY-528
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
>Affects Versions: 1.4-incubating
>Reporter: Matthias Weßendorf
>
> The "generate-assembly-info" goal has the following documentation:
> http://incubator.apache.org/npanday/docs/1.4.0-incubating/plugins/maven-compile-plugin/generate-assembly-info-mojo.html
> In there, there is no information about the "assemblyInfo" paramter.
> It should contain an example that using the following, inside a pom.xml:
> {code}
>
> ...
>
> FOO
> FOO
>
> ...
>
> {code}
> results into the following in the generated pom.xml file:
> {code}
> ...
> [assembly: CustomStringAttribute("key1", "FOO")]
> [assembly: CustomStringAttribute("key2", "FOO")]
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-529) create internalsVisibleTo parameter list for the compiler plugin
[
https://issues.apache.org/jira/browse/NPANDAY-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183195#comment-13183195
]
Lars Corneliussen commented on NPANDAY-529:
---
Should that be generically solved, or rather a specific parameter?
> create internalsVisibleTo parameter list for the compiler plugin
>
>
> Key: NPANDAY-529
> URL: https://issues.apache.org/jira/browse/NPANDAY-529
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
>Affects Versions: 1.4-incubating
>Reporter: Matthias Weßendorf
>Assignee: Matthias Weßendorf
>
> Sometimes it is needed to "expose" internal interfaces (for mocking/testing)
> NMock is not allowing to create mocks out of internal interfaces:
> In order archive it, we need to have the following on the AssemblyInfo.cs file
> {code}
> [assembly: InternalsVisibleTo("Mocks")]
> [assembly: InternalsVisibleTo("MockObjects")]
> {code}
> However, since this is not always needed, it should be a parameter list in
> the pom.xml config section
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-493) Xml Document Transform (XDT) support for web and application packaging
[
https://issues.apache.org/jira/browse/NPANDAY-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180664#comment-13180664
]
Lars Corneliussen commented on NPANDAY-493:
---
{quote}
A free implementation of the Microsoft XDT language.
http://petemontgomery.wordpress.com/2010/09/20/microsoft-xdt-language/
Lars Corneliussen: We want to integrate XDT in Apache NPanday (Maven for .NET)
https://issues.apache.org/jira/browse/NPANDAY-493 We think of using your
version because it could possibly also run on Mono (if not we could make it
run). I’m not sure if we can redistribute LGPL-stuff; would you consider also
providing XDT under the Apache license?
Pete Montgomery: Hi Lars, yes of course. Apache licence is fine; let me know if
I need to send you anything. Pete.
{quote}
> Xml Document Transform (XDT) support for web and application packaging
> --
>
> Key: NPANDAY-493
> URL: https://issues.apache.org/jira/browse/NPANDAY-493
> Project: NPanday
> Issue Type: New Feature
> Components: Maven Plugins, Visual Studio Add-in
>Reporter: Lars Corneliussen
>Assignee: Lars Corneliussen
> Fix For: Backlog
>
>
> Currently NPanday expects a copy of web/app.config, named
> web/app.package.config; It would be better, if the files named *.package.*
> would just use XDT to transform the "underlying" *.* files.
> That could be done through MSBuild, using the Task "XmlDocumentTransform", or
> through a third party implementation, available here:
> http://code.google.com/p/xdt/ (LGPL!)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-452) Support Silverlight Applications
[ https://issues.apache.org/jira/browse/NPANDAY-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180315#comment-13180315 ] Lars Corneliussen commented on NPANDAY-452: --- John, what version of Silverlight do you use? Still current? > Support Silverlight Applications > > > Key: NPANDAY-452 > URL: https://issues.apache.org/jira/browse/NPANDAY-452 > Project: NPanday > Issue Type: New Feature > Components: Maven Plugins >Affects Versions: 1.4-incubating > Environment: >mvn -v > Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_24 > Java home: C:\Progra~1\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows" >Reporter: John R. Fallows >Assignee: Lars Corneliussen > Fix For: 1.5.0-incubating > > > Silverlight applications are delivered as .xap files and may also use xaml to > define the user interface declaratively. > We need a custom packaging, such as "silverlight-application", that will > create the corresponding .xap file with NPanday. This will involve writing > additional plugins for any new executables, and then bind the corresponding > goals to the "silverlight-application" lifecycle accordingly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-500) potential compilation failures if path contains a space
[
https://issues.apache.org/jira/browse/NPANDAY-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179858#comment-13179858
]
Lars Corneliussen commented on NPANDAY-500:
---
Both trunk and its now pass when their location contains a space.
> potential compilation failures if path contains a space
> ---
>
> Key: NPANDAY-500
> URL: https://issues.apache.org/jira/browse/NPANDAY-500
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
>Affects Versions: 1.4-incubating
>Reporter: Brett Porter
>Assignee: Lars Corneliussen
> Fix For: 1.5.0-incubating
>
>
> While I don't think this always happens, I had this problem on the CI build:
> https://builds.apache.org/job/NPanday/26/console
> {code}
> [INFO] --- maven-compile-plugin:1.4.0-incubating:compile (default-compile) @
> NPanday.Model.Pom ---
> [INFO] NPANDAY-066-013: Found Vendor = Vendor = MICROSOFT, Vendor Version =
> 2.0.50727, Framework Version = 2.0.50727, Executable Paths =
> [INFO] NPANDAY-068-003: Compiling Artifact: Vendor = MICROSOFT, Language =
> MICROSOFT, Assembly Name = F:\hudson\hudson-slave\workspace\NPanday
> trunk\dotnet\assemblies\NPanday.Model.Pom\target\NPanday.Model.Pom.dll
> [WARNING] NPANDAY-068-006: Did not find path for csc in []
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(87,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Model.Model()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(418,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Parent.Parent()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(584,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.DeploymentRepository.DeploymentRepository()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(771,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Dependency.Dependency()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(919,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.ReportSet.ReportSet()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1008,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.ReportPlugin.ReportPlugin()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Reporting.Reporting()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1162,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.RepositoryPolicy.RepositoryPolicy()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1218,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Repository.Repository()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1411,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Resource.Resource()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1517,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Plugin.Plugin()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1635,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.PluginExecution.PluginExecution()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1899,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Activation.Activation()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(2432,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Scm.Scm()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(2907,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Notifier.Notifier()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(3102,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Prerequisites.Prerequisites()'
> error CS1566: Error reading resource file
> 'f:\hudson\hudson-slave\workspace\NPanday
> trunk\dotnet\assemblies\NPanday.Model.Pom\target\assembly-resources\resource\META-INF\DEPENDENCIES,NPanday.Model.Pom.META-INF.DEPENDENCIES'
> -- 'The system cannot find the file specified. '
> error CS1566: Error reading resource file
> 'f:\huds
[jira] [Commented] (NPANDAY-500) potential compilation failures if path contains a space
[
https://issues.apache.org/jira/browse/NPANDAY-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179857#comment-13179857
]
Lars Corneliussen commented on NPANDAY-500:
---
Odd. "/resource:," works, /resource:"," doesn't,
/resource:"\"\"," neither.
Now configured an exception for /resource, because it can't be unified with all
the other behaviour. /define has different behaviour, for example.
it is then not recognized as switch, but just quoted as a whole.
> potential compilation failures if path contains a space
> ---
>
> Key: NPANDAY-500
> URL: https://issues.apache.org/jira/browse/NPANDAY-500
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
>Affects Versions: 1.4-incubating
>Reporter: Brett Porter
>Assignee: Lars Corneliussen
> Fix For: 1.5.0-incubating
>
>
> While I don't think this always happens, I had this problem on the CI build:
> https://builds.apache.org/job/NPanday/26/console
> {code}
> [INFO] --- maven-compile-plugin:1.4.0-incubating:compile (default-compile) @
> NPanday.Model.Pom ---
> [INFO] NPANDAY-066-013: Found Vendor = Vendor = MICROSOFT, Vendor Version =
> 2.0.50727, Framework Version = 2.0.50727, Executable Paths =
> [INFO] NPANDAY-068-003: Compiling Artifact: Vendor = MICROSOFT, Language =
> MICROSOFT, Assembly Name = F:\hudson\hudson-slave\workspace\NPanday
> trunk\dotnet\assemblies\NPanday.Model.Pom\target\NPanday.Model.Pom.dll
> [WARNING] NPANDAY-068-006: Did not find path for csc in []
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(87,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Model.Model()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(418,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Parent.Parent()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(584,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.DeploymentRepository.DeploymentRepository()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(771,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Dependency.Dependency()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(919,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.ReportSet.ReportSet()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1008,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.ReportPlugin.ReportPlugin()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Reporting.Reporting()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1162,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.RepositoryPolicy.RepositoryPolicy()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1218,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Repository.Repository()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1411,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Resource.Resource()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1517,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Plugin.Plugin()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1635,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.PluginExecution.PluginExecution()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(1899,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Activation.Activation()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(2432,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Scm.Scm()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(2907,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Notifier.Notifier()'
> dotnet\assemblies\NPanday.Model.Pom\target\build-sources\Pom.cs(3102,16):
> warning CS1591: Missing XML comment for publicly visible type or member
> 'NPanday.Model.Pom.Prerequisites.Prerequisites()'
> error CS1566: Error reading resource file
> 'f:\hudson\hudson-slave\workspace\NPanday
> trunk\dotnet\assemblie
[jira] [Commented] (NPANDAY-510) Allow wix-maven-plugin to configure wix home
[ https://issues.apache.org/jira/browse/NPANDAY-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174994#comment-13174994 ] Lars Corneliussen commented on NPANDAY-510: --- Also by default we could try finding wix on %WIX%; but that is also version-independent. BTW, maybe this is interesting for you: https://issues.apache.org/jira/browse/NPANDAY-499 > Allow wix-maven-plugin to configure wix home > > > Key: NPANDAY-510 > URL: https://issues.apache.org/jira/browse/NPANDAY-510 > Project: NPanday > Issue Type: Improvement > Components: Maven Plugins >Affects Versions: 1.4-incubating >Reporter: Adrián Boimvaser > Fix For: 1.4.1-incubating, 1.5.0-incubating > > Attachments: wixHome.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > At this moment wix-maven-plugin expects candle.exe and light.exe to be on the > path. > it would be nice to be able to specify the location of the wix installation > via a configuration parameter > > C:\wix > ... > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-510) Allow wix-maven-plugin to configure wix home
[ https://issues.apache.org/jira/browse/NPANDAY-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174989#comment-13174989 ] Lars Corneliussen commented on NPANDAY-510: --- I'd like to discuss "%PATH%" with you :) I really don't like that NPanday requires things to be on the path. Instead I'd like a standard way to specify paths for executables - theese should also work with multiple versions and OS per se; but maybe it is overkill for those just building one version on one environmen anyway? Also wix-plugin doesn't make use of the standard executable facilities in NPanday (look at msdeploy/azure plugins) - which i did refactor a lot in 1.5.0-incubating-SNAPSHOT. There we have support for versioning, default probing paths, ++; > Allow wix-maven-plugin to configure wix home > > > Key: NPANDAY-510 > URL: https://issues.apache.org/jira/browse/NPANDAY-510 > Project: NPanday > Issue Type: Improvement > Components: Maven Plugins >Affects Versions: 1.4-incubating >Reporter: Adrián Boimvaser > Fix For: 1.4.1-incubating, 1.5.0-incubating > > Attachments: wixHome.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > At this moment wix-maven-plugin expects candle.exe and light.exe to be on the > path. > it would be nice to be able to specify the location of the wix installation > via a configuration parameter > > C:\wix > ... > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-486) Implement integrated XBuild/MSBuild lifecycle (superseeds current MSBuild integration)
[
https://issues.apache.org/jira/browse/NPANDAY-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174075#comment-13174075
]
Lars Corneliussen commented on NPANDAY-486:
---
> resources
OK
> both lifecycles
I'd do that whenever we exactly know what to implement and when.
> Implement integrated XBuild/MSBuild lifecycle (superseeds current MSBuild
> integration)
> --
>
> Key: NPANDAY-486
> URL: https://issues.apache.org/jira/browse/NPANDAY-486
> Project: NPanday
> Issue Type: New Feature
> Components: Maven Plugins
>Affects Versions: 1.4-incubating
> Environment: Windows/.NET: MSBuild; Mono: Xbuild
>Reporter: Lars Corneliussen
>Assignee: Lars Corneliussen
> Fix For: 1.5.0-incubating
>
>
> The current MSBuild integration is a hack initially implemented to support
> WPF projects (XAML code- and resources-generation)
> It was initially implemented as a dotnet-maven-plugin, but now also the Java
> binding has been forked from the originally generated source. Also, currently
> sources are compiled twice; once via MSBuild and then later through NPanday.
> h2. Functional Requirements (high-level)
> * It must be possible to compile WPF-projects (with Xaml-files)
> * It must be extensible though custom MSBuild
> * any more?
> h2. Conditions / Design Decisions
> * The Maven principle of reproducible builds must be met.
> * Dependencies from pom must override those specified in the build file
> * Correct versions of dependencies must be ensured
> * Project-references must be resolved inside the reactor, if possible.
> * Generated code or resource must automatically be added to the POM
> (in-memory?)
> * MSBuild targets should run in the most appropriate maven phase
> * MSBuild errors must be correctly reported
> * (on) MSBuild-shadowing should be extensible (wildcard-include), means:
> {{{target/msbuild/build.xml}}}, importing:
> ** {{{use-generated-assembly-info.targets}}}
> ** {{{override-output-paths.targets}}}
> ** ...
> * (on) We could suppress the actual C#/VB-compilation and all following
> steps; then run msbuild in process-sources
> ** hence: {{{skip-CoreCompile-and-following.targets}}}
> h2. Two MSBuild Lifecycles
> Trying to figure out, how MSBuild can be integrated with the standard Maven
> lifecycle.
> {color:red}red: changes to maven-compile-plugin lifecycle{color}
> {color:green}green: msbuild concern{color}
> h3. Integrated MSBuild Lifecycle Draft
> This would run MSBuild up until short before compilation (CSC/VBC).
> Generation of the final artifacts are then still left to NPanday.
> Means more control, but could mean less compatibility.
> *validate*
> - NPanday Plugins : maven-compile-plugin : initialize
> {color:red}Necessary?: runs {{{assemblyResolver.resolveTransitivelyFor}}} and
> {{{assemblerContext.init}}}{color}
> - NPanday Plugins : maven-resolver-plugin : resolve
> - NPanday Plugins : NPanday.Plugin.Settings.JavaBinding : generate-settings
> - {color:green}NPanday Plugins : msbuild-maven-plugin : initialize (finds
> the MSBuild file and validates that msbuild is available?){color}
> *on generate-sources*
> - {color:green}NPanday Plugins : msbuild-maven-plugin : *shaddow* (creates
> msbuild-file, figures out parametrization){color}
> -- {color:green}Should find 'integrated' contributors (through plexus) and
> execute all of them{color}
> -- {color:green}Replace {{{CoreCompile}}} target and skip following
> targets{color}
> -- ??
> - {color:green}NPanday Plugins : msbuild-maven-plugin :
> *run-integrated*{color}
> -- {color:green}Runs all MSBuild targets up to CoreCompile{color}
> -- {color:green}Includes dynamically added sources from @(Compile) to
> build/sources (apply excludes afterwards!){color}
> -- {color:green}Includes dynamically added resources from @(Compile) to
> build/resources (apply excludes afterwards!){color}
> - NPanday Plugins : maven-compile-plugin : generate-assembly-info
> *on process-sources*
> - NPanday Plugins : maven-compile-plugin : process-sources
> - NPanday Plugins : maven-compile-plugin : process-test-sources
> - {color:green}NPanday Plugins : msbuild-maven-plugin :
> *shadow-assembly-info* (should share code with generate-assembly-info){color}
> *on process-resources*
> - NPanday Plugins : maven-resgen-plugin : copy-resources
> - NPanday Plugins : maven-resgen-plugin : generate
> - NPanday Plugins : maven-resgen-plugin : generate-existing-resx-to-resource
> *on compile*
> - NPanday Plugins : maven-compile-plugin : compile
> *on test-compile*
> - NPanday Plugins : maven-compile-plugin : testCompile
> *on test*
> - NPanday Plugins : maven-test-plugin : test
> *on install*
> - NPanday Plugins : maven-repo
[jira] [Commented] (NPANDAY-213) ASP.NET projects fail to compile on .NET 2.0 toolchain
[ https://issues.apache.org/jira/browse/NPANDAY-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160141#comment-13160141 ] Lars Corneliussen commented on NPANDAY-213: --- It then rather seems, that the web.config beeing tested uses things from .NET 3.5?? > ASP.NET projects fail to compile on .NET 2.0 toolchain > -- > > Key: NPANDAY-213 > URL: https://issues.apache.org/jira/browse/NPANDAY-213 > Project: NPanday > Issue Type: Bug >Reporter: Brett Porter >Priority: Minor > Fix For: Backlog > > > The WebAppInstallTest fails without a 3.5 SDK installed, with the following > error: > ...\target\test-classes\WebAppExample\web.config(83): error ASPCONFIG: Child > nodes not allowed. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] NPANDAY-900-006: Unable to Compile: Language = ASP, Vendor = null, > ArtifactType = asp, Source Directory = ...\target\test-classes\WebAppExample > Embedded error: NPANDAY-040-001: Could not execute: Command = CMD.EXE /X /C > aspnet_compiler -v /WebAppExample -p "...\target\test-classes\WebAppExample" > -u -f C:\...\LOCALS~1\Temp\maven-aspx-plugin-6742479769207709591 -nologo > -fixednames, Result = 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-405) Allow to build multiple configurations in one build (Multi-targeting)
[
https://issues.apache.org/jira/browse/NPANDAY-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155812#comment-13155812
]
Lars Corneliussen commented on NPANDAY-405:
---
We should consider using the same abbreviations as NuGet:
http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#Grouping_Assemblies_by_Framework_Version
> Allow to build multiple configurations in one build (Multi-targeting)
> -
>
> Key: NPANDAY-405
> URL: https://issues.apache.org/jira/browse/NPANDAY-405
> Project: NPanday
> Issue Type: New Feature
> Components: Maven Plugins
>Reporter: Lars Corneliussen
> Fix For: Backlog
>
>
> It would be great, if 'mvn compile' just compiled different configuration
> combinations in one build.
> Just as an example, look at the log4net-distribution. How would we produce
> that using NPanday today?
> {code}
> log4net-1.2.10/bin
> log4net-1.2.10/bin/cli
> log4net-1.2.10/bin/cli/1.0
> log4net-1.2.10/bin/cli/1.0/release
> log4net-1.2.10/bin/cli/1.0/release/log4net.dll
> log4net-1.2.10/bin/cli/1.0/release/log4net.xml
> log4net-1.2.10/bin/mono
> log4net-1.2.10/bin/mono/1.0
> log4net-1.2.10/bin/mono/1.0/debug
> log4net-1.2.10/bin/mono/1.0/debug/log4net.dll
> log4net-1.2.10/bin/mono/1.0/debug/log4net.dll.mdb
> log4net-1.2.10/bin/mono/1.0/debug/log4net.xml
> log4net-1.2.10/bin/mono/1.0/release
> log4net-1.2.10/bin/mono/1.0/release/log4net.dll
> log4net-1.2.10/bin/mono/1.0/release/log4net.xml
> log4net-1.2.10/bin/mono/2.0
> log4net-1.2.10/bin/mono/2.0/debug
> log4net-1.2.10/bin/mono/2.0/debug/log4net.dll
> log4net-1.2.10/bin/mono/2.0/debug/log4net.dll.mdb
> log4net-1.2.10/bin/mono/2.0/debug/log4net.xml
> log4net-1.2.10/bin/mono/2.0/release
> log4net-1.2.10/bin/mono/2.0/release/log4net.dll
> log4net-1.2.10/bin/mono/2.0/release/log4net.xml
> log4net-1.2.10/bin/net
> log4net-1.2.10/bin/net/1.0
> log4net-1.2.10/bin/net/1.0/debug
> log4net-1.2.10/bin/net/1.0/debug/log4net.dll
> log4net-1.2.10/bin/net/1.0/debug/log4net.pdb
> log4net-1.2.10/bin/net/1.0/debug/log4net.xml
> log4net-1.2.10/bin/net/1.0/release
> log4net-1.2.10/bin/net/1.0/release/log4net.dll
> log4net-1.2.10/bin/net/1.0/release/log4net.xml
> log4net-1.2.10/bin/net/1.1
> log4net-1.2.10/bin/net/1.1/debug
> log4net-1.2.10/bin/net/1.1/debug/log4net.dll
> log4net-1.2.10/bin/net/1.1/debug/log4net.pdb
> log4net-1.2.10/bin/net/1.1/debug/log4net.xml
> log4net-1.2.10/bin/net/1.1/release
> log4net-1.2.10/bin/net/1.1/release/log4net.dll
> log4net-1.2.10/bin/net/1.1/release/log4net.xml
> log4net-1.2.10/bin/net/2.0
> log4net-1.2.10/bin/net/2.0/debug
> log4net-1.2.10/bin/net/2.0/debug/log4net.dll
> log4net-1.2.10/bin/net/2.0/debug/log4net.pdb
> log4net-1.2.10/bin/net/2.0/debug/log4net.xml
> log4net-1.2.10/bin/net/2.0/release
> log4net-1.2.10/bin/net/2.0/release/log4net.dll
> log4net-1.2.10/bin/net/2.0/release/log4net.xml
> log4net-1.2.10/bin/netcf
> log4net-1.2.10/bin/netcf/1.0
> log4net-1.2.10/bin/netcf/1.0/debug
> log4net-1.2.10/bin/netcf/1.0/debug/log4net.dll
> log4net-1.2.10/bin/netcf/1.0/debug/log4net.pdb
> log4net-1.2.10/bin/netcf/1.0/debug/log4net.xml
> log4net-1.2.10/bin/netcf/1.0/release
> log4net-1.2.10/bin/netcf/1.0/release/log4net.dll
> log4net-1.2.10/bin/netcf/1.0/release/log4net.xml
> log4net-1.2.10/bin/sscli
> log4net-1.2.10/bin/sscli/1.0
> log4net-1.2.10/bin/sscli/1.0/debug
> log4net-1.2.10/bin/sscli/1.0/debug/log4net.dll
> log4net-1.2.10/bin/sscli/1.0/debug/log4net.ildb
> log4net-1.2.10/bin/sscli/1.0/release
> log4net-1.2.10/bin/sscli/1.0/release/log4net.dll
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-426) unhandled exception when attempting to execute NPanday.Plugin.Loader.exe
[
https://issues.apache.org/jira/browse/NPANDAY-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154956#comment-13154956
]
Lars Corneliussen commented on NPANDAY-426:
---
It should just regenerate the npanday-settings.xml, that is, what fails.
I still was not able to reproduce this error in a sandbox :(
> unhandled exception when attempting to execute NPanday.Plugin.Loader.exe
>
>
> Key: NPANDAY-426
> URL: https://issues.apache.org/jira/browse/NPANDAY-426
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
>Affects Versions: 1.4-incubating
> Environment: Maven 2.2.1, Windows 7 64 bit, Java 1.6_23, Npanday
> 1.3-incubating
>Reporter: Khai Do
>Priority: Critical
> Labels: maven
> Fix For: 1.4.1-incubating
>
> Attachments: NPANDAY_426.zip, npanday-settings.xml,
> testWpfControlLibrary.zip
>
>
> I get an unhandled exception when attempting to execute
> NPanday.Plugin.Loader.exe. I've found that I get this exception when
> npanday-settings.xml is missing from C:\Documents and Settings\\.m2
> folder. The fialure goes away when the file is present. The
> Npanday-1.3-incubating.msi doesn't install this file. I've already posted
> this issue on the npanday mailing list:
> http://markmail.org/message/vw4dsxlbchcknbbz
> Here is the error..
> [INFO] [NPanday.Plugin.Settings.JavaBinding:generate-settings {execution:
> default-generate-settings}] NPanday: Start Process = 4/14/2011 2:47:26 PM
> "parameterFile=C:\Users\ADMINI~1\AppData\Local\Temp\Plugin2180957865136058399.xml"
> "assemblyFile=C:\source\DashboardSample\target\NPanday.Plugin.Settings.dll"
> "mojoName=NPanday.Plugin.Settings.Setting sGeneratorMojo"
> "startProcessAssembly=C:\source\DashboardSample\target\NPanday.Plugin.Loader.exe"
> [INFO] [INFO] Unhandled Exception: System.TypeLoadException: The domain
> manager
> specified by the host could not be instantiated. [INFO] at
> System.AppDomain.CreateDomainManager(String
> domainManagerAssemblyName, String domainManagerTypeName) [INFO] at
> System.AppDomain.SetDomainManager(Evidence providedSecurityInfo,
> Evidence creatorsSecurityInfo, IntPtr parentSecurityDescriptor, Boolean
> publishAppDomain) [INFO] at System.AppDomain.SetDefaultDomainManager(String
> fullName, String[]
> manifestPaths, String[] activationData) NPanday: End Process = 4/14/2011
> 2:47:30 PM; exit code = -532459699 [INFO]
>
> [ERROR] BUILD ERROR [INFO]
>
> [INFO] NPANDAY-xxx-000
> Embedded error: NPANDAY-063-000: Execution Path =
> C:\source\DashboardSample\target, Command =
> [parameterFile=C:\Users\ADMINI~1\AppData\Local\Temp\Plugin2180957865136058399.xml,
> assemblyFile=C:\source\ DashboardSample\target\NPanday.Plugin.Settings.dll,
> mojoName=NPanday.Plugin.Settings.SettingsGeneratorMojo,
> startProcessAssembly=C:\source\DashboardSample\target\NPanday.Plugin.Loader.exe]
> NPANDAY-040-001: Could not execute: Command = CMD.EXE /X /C
> NPanday.Plugin.Runner.exe
> parameterFile=C:\Users\ADMINI~1\AppData\Local\Temp\Plugin2180957865136058399.xml
> assemblyFile=C:\source\DashboardS ample\target\NPanday.Plugin.Settings.dll
> mojoName=NPanday.Plugin.Settings.SettingsGeneratorMojo
> startProcessAssembly=C:\source\DashboardSample\target\NPanday.Plugin.Loader.exe,
> Result = -532459699
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-484) Remove NPanday.Plugin.Addin as it is outdated and unused
[ https://issues.apache.org/jira/browse/NPANDAY-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154133#comment-13154133 ] Lars Corneliussen commented on NPANDAY-484: --- We can then also remove NPanday.Model.AutomationExtensibility. > Remove NPanday.Plugin.Addin as it is outdated and unused > > > Key: NPANDAY-484 > URL: https://issues.apache.org/jira/browse/NPANDAY-484 > Project: NPanday > Issue Type: Wish > Components: Maven Plugins >Affects Versions: 1.4-incubating >Reporter: Lars Corneliussen > > It it one of three sources for the *.Addin-file (we also have wix and > maven-vsinstaller-plugin. > It only supports VS 2005 and seems to be quite outdated. I think people > should rather create theese manually and then filter in properties from the > pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-372) Integrate with NuGet and NuGet Gallery (nuget.org)
[ https://issues.apache.org/jira/browse/NPANDAY-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152012#comment-13152012 ] Lars Corneliussen commented on NPANDAY-372: --- We should also support private nuget-feeds: http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds This is interesting both for resolve and deploy. Integration with symbolsource.com would also be great! http://www.symbolsource.org/Public/Blog/View/25 > Integrate with NuGet and NuGet Gallery (nuget.org) > -- > > Key: NPANDAY-372 > URL: https://issues.apache.org/jira/browse/NPANDAY-372 > Project: NPanday > Issue Type: New Feature > Components: Maven Plugins >Reporter: Lars Corneliussen >Assignee: Lars Corneliussen > Fix For: 2.0 > > > Dependency Management has come to .NET - and Microsoft has taken care of it. > That means, to be successful we have to integrate. > NuGet is for dependency management, and the nuget gallery has a couple of > hundred OS packages online already. > -I think it should be fairly easy to create a repository layout for those and > integrated it with maven.- > *Nothing is easy. :-)* > h4. Prioritized Requirements > For a first release, we should at least support following scenarios: > # *Resolve library dependencies from nuget repositories / nuget.org* (this > will be a huge benefit!, right away.) >(!) How should we do this? Wagon, repository layout? I do not know enough > about maven yet. >(!) Also, which portions of a *.npkg should we support? It has some > conventions, but supports very much any content you can put in a zip. It also > has visual-studio-specific things in it. Have to investigate more here. >(!) How do we talk to nuget.org? Via Nuget.Core? > # *Generate nuspec-file from pom, or if it exsits, patch it* >This will make it easier to pack and push nuget packages, even if this is > not automated yet. > # *Create a '\*.npkg' on 'package' and attach as 'nuget-package'* >We need to add a new type != dotnet-*. Should this be part of npanday? > # *Install \*.npgkg to local nuget repository on 'install'* >(?) Is there any standard for this? (!) If not, will we invent one? > # *Push \*.npkg to nuget.org on 'deploy'* >That shouldn't be to hard. > > h4. Unique Selling Proposition > * Nuget-Packages for VS 2005 and 2008 > * Nuget outside of Visual Studio (currently the cmd-line tool does not do > more than download and unzip) > h4. Nice to have > * Minimod support > * further ideas? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-369) Explicit 64bit-Support (NPanday now doesn't distinguish)
[ https://issues.apache.org/jira/browse/NPANDAY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152007#comment-13152007 ] Lars Corneliussen commented on NPANDAY-369: --- Why reinvent the wheel? :-) http://msdn.microsoft.com/en-us/library/microsoft.build.utilities.toollocationhelper.aspx > Explicit 64bit-Support (NPanday now doesn't distinguish) > > > Key: NPANDAY-369 > URL: https://issues.apache.org/jira/browse/NPANDAY-369 > Project: NPanday > Issue Type: Bug > Components: Development Setup >Affects Versions: 1.4-incubating > Environment: Win 7, x64, VS 2010 only >Reporter: Lars Corneliussen >Assignee: Lars Corneliussen > Labels: build, nunit, test, x64, x86 > Fix For: 2.0 > > > Building NPanday from source (including tests) on 64bit windows fails. > The problem is, that all resources are built with the 64-bit version of the > .NET Framework tools. Also then, the nunit-console runs everything (including > MSBUILD) in 64 bit. > NPanday itself should allways be built using x86. It should furthermore have > strong support for building both 32bit and 64bit apps on 64bit systems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-452) Support Silverlight Applications
[
https://issues.apache.org/jira/browse/NPANDAY-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152006#comment-13152006
]
Lars Corneliussen commented on NPANDAY-452:
---
Just something I found in Microsoft.Common.targets.
Should help us to find proper naming.
{code}
.NETFramework
v4.0
..
$(TargetFrameworkIdentifier),Version=$(TargetFrameworkVersion),Profile=$(TargetFrameworkProfile)
$(TargetFrameworkIdentifier),Version=$(TargetFrameworkVersion)
{code}
> Support Silverlight Applications
>
>
> Key: NPANDAY-452
> URL: https://issues.apache.org/jira/browse/NPANDAY-452
> Project: NPanday
> Issue Type: New Feature
> Components: Maven Plugins
>Affects Versions: 1.4-incubating
> Environment: >mvn -v
> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
> Java version: 1.6.0_24
> Java home: C:\Progra~1\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: John R. Fallows
>
> Silverlight applications are delivered as .xap files and may also use xaml to
> define the user interface declaratively.
> We need a custom packaging, such as "silverlight-application", that will
> create the corresponding .xap file with NPanday. This will involve writing
> additional plugins for any new executables, and then bind the corresponding
> goals to the "silverlight-application" lifecycle accordingly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-369) Explicit 64bit-Support (NPanday now doesn't distinguish)
[
https://issues.apache.org/jira/browse/NPANDAY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152003#comment-13152003
]
Lars Corneliussen commented on NPANDAY-369:
---
h2. Hints I found in Microsoft.Common.targets
Maybe that helps us to find the correct names.
{code}
msil
amd64
ia64
x86
{code}
> Explicit 64bit-Support (NPanday now doesn't distinguish)
>
>
> Key: NPANDAY-369
> URL: https://issues.apache.org/jira/browse/NPANDAY-369
> Project: NPanday
> Issue Type: Bug
> Components: Development Setup
>Affects Versions: 1.4-incubating
> Environment: Win 7, x64, VS 2010 only
>Reporter: Lars Corneliussen
>Assignee: Lars Corneliussen
> Labels: build, nunit, test, x64, x86
> Fix For: 2.0
>
>
> Building NPanday from source (including tests) on 64bit windows fails.
> The problem is, that all resources are built with the 64-bit version of the
> .NET Framework tools. Also then, the nunit-console runs everything (including
> MSBUILD) in 64 bit.
> NPanday itself should allways be built using x86. It should furthermore have
> strong support for building both 32bit and 64bit apps on 64bit systems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-473) compatibilty with maven 3
[
https://issues.apache.org/jira/browse/NPANDAY-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151299#comment-13151299
]
Lars Corneliussen commented on NPANDAY-473:
---
As i see it 'artifactMapByVersionlessId' exists in all versions, and does the
same.
> compatibilty with maven 3
> -
>
> Key: NPANDAY-473
> URL: https://issues.apache.org/jira/browse/NPANDAY-473
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
>Affects Versions: 1.4.1-incubating
> Environment: maven 3, 64 bit windows 7, jre 1.6.0.22
>Reporter: sergio rupena
>
> I get this error when I run maven 3 with npanday:
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.npanday.plugins:maven-compile-plugin:1.4.1-incubating-SNAPSHOT:initialize
> (default-initialize) on project TestDll: Execution default-initialize of
> goal
> org.apache.npanday.plugins:maven-compile-plugin:1.4.1-incubating-SNAPSHOT:initialize
> failed: An API incompatibility was encountered while executing
> org.apache.npanday.plugins:maven-
> compile-plugin:1.4.1-incubating-SNAPSHOT:initialize:
> java.lang.NoSuchMethodError:
> org.apache.maven.artifact.ArtifactUtils.artifactMapByArtifactId(Ljava/util/Collection;)Ljava/util/Map;
> [ERROR] -
> [ERROR] realm =
> plugin>org.apache.npanday.plugins:maven-compile-plugin:1.4.1-incubating-SNAPSHOT
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/C:/Users/sr/.m2/repository/org/apache/npanday/plugins/maven-compile-plugin/1.4.1-incubating-SNAPSHOT/maven-compile-plugin-1.4.1-incubating-SNAPSHOT.jar
> [ERROR] urls[1] =
> file:/C:/Users/sr/.m2/repository/org/apache/npanday/dotnet-registry/1.4.1-incubating-SNAPSHOT/dotnet-registry-1.4.1-incubating-SNAPSHOT.jar
> [ERROR] urls[2] =
> file:/C:/Users/sr/.m2/repository/net/sf/kxml/kxml2/2.1.8/kxml2-2.1.8.jar
> [ERROR] urls[3] =
> file:/C:/Users/sr/.m2/repository/xmlpull/xmlpull/1.1.3.4a/xmlpull-1.1.3.4a.jar
> [ERROR] urls[4] =
> file:/C:/Users/sr/.m2/repository/org/openrdf/openrdf-repository-api/2.0-beta5/openrdf-repository-api-2.0-beta5.jar
> [ERROR] urls[5] =
> file:/C:/Users/sr/.m2/repository/org/openrdf/openrdf-query/2.0-beta5/openrdf-query-2.0-beta5.jar
> [ERROR] urls[6] =
> file:/C:/Users/sr/.m2/repository/org/openrdf/openrdf-sail-api/2.0-beta5/openrdf-sail-api-2.0-beta5.jar
> [ERROR] urls[7] =
> file:/C:/Users/sr/.m2/repository/org/openrdf/openrdf-queryresultio-api/2.0-beta5/openrdf-queryresultio-api-2.0-beta5.jar
> [ERROR] urls[8] =
> file:/C:/Users/sr/.m2/repository/org/openrdf/openrdf-rio-api/2.0-beta5/openrdf-rio-api-2.0-beta5.jar
> [ERROR] urls[9] =
> file:/C:/Users/sr/.m2/repository/info/aduna/aduna-xml/1.2/aduna-xml-1.2.jar
> [ERROR] urls[10] =
> file:/C:/Users/sr/.m2/repository/info/aduna/aduna-lang/1.3/aduna-lang-1.3.jar
> It looks like the java class AssemblyResolverImpl.java. (from the
> dotnet-artifact project) can only use the maven 2 API.
> I tried the following workaround just to see if I could get it work with
> maven 3. I post it here as hack, as it's using reflection to fallback to the
> maven 3 api.
> {code}
> private Map
> artifactMapByArtifactId(java.util.Collection artifacts){
> try{
> for(java.lang.reflect.Method method :
> ArtifactUtils.class.getDeclaredMethods()){
> if (method.getName() == "artifactMapByVersionlessId"){
> return (Map Artifact>)method.invoke(null, new Object[]{artifacts});
> }
> }
> } catch(java.lang.IllegalAccessException e){
> throw new RuntimeException("failed to map artifacts using
> ArtifactUtils class", e);
> }catch(java.lang.reflect.InvocationTargetException e){
> throw new RuntimeException("failed to map artifacts using
> ArtifactUtils class", e);
> }
> return ArtifactUtils.artifactMapByArtifactId( Collections.singleton(
> artifacts )) ;
> }
> public void resolve(Artifact artifact, List remoteRepositories,
> ArtifactRepository localRepository) throws ArtifactResolutionException,
> ArtifactNotFoundException
> {
>
> String mavenProjectRefId = artifact.getGroupId() + ":" +
> artifact.getArtifactId() + ":" + artifact.getVersion();
> MavenProject mavenProjectRef = (MavenProject) mavenProjectRefs.get(
> mavenProjectRefId );
> if ( mavenProjectRef != null )
> {
> if ( "pom".equals( artifact.getType() ) )
> {
> artifact.setFile( mavenProjectRef.getFile() );
> return;
> }
> else
> {
>
[jira] [Commented] (NPANDAY-473) compatibilty with maven 3
[
https://issues.apache.org/jira/browse/NPANDAY-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151289#comment-13151289
]
Lars Corneliussen commented on NPANDAY-473:
---
Hi. Encountering the same error and would like to fix it! Seems like it got
introduced with mvn 3.0.3, since I already successfully built with 3.0.0-alpha
or so..
But I might be wrong.
Did you check, if there is any solution without using reflection?
> compatibilty with maven 3
> -
>
> Key: NPANDAY-473
> URL: https://issues.apache.org/jira/browse/NPANDAY-473
> Project: NPanday
> Issue Type: Bug
> Components: Maven Plugins
>Affects Versions: 1.4.1-incubating
> Environment: maven 3, 64 bit windows 7, jre 1.6.0.22
>Reporter: sergio rupena
>
> I get this error when I run maven 3 with npanday:
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.npanday.plugins:maven-compile-plugin:1.4.1-incubating-SNAPSHOT:initialize
> (default-initialize) on project TestDll: Execution default-initialize of
> goal
> org.apache.npanday.plugins:maven-compile-plugin:1.4.1-incubating-SNAPSHOT:initialize
> failed: An API incompatibility was encountered while executing
> org.apache.npanday.plugins:maven-
> compile-plugin:1.4.1-incubating-SNAPSHOT:initialize:
> java.lang.NoSuchMethodError:
> org.apache.maven.artifact.ArtifactUtils.artifactMapByArtifactId(Ljava/util/Collection;)Ljava/util/Map;
> [ERROR] -
> [ERROR] realm =
> plugin>org.apache.npanday.plugins:maven-compile-plugin:1.4.1-incubating-SNAPSHOT
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/C:/Users/sr/.m2/repository/org/apache/npanday/plugins/maven-compile-plugin/1.4.1-incubating-SNAPSHOT/maven-compile-plugin-1.4.1-incubating-SNAPSHOT.jar
> [ERROR] urls[1] =
> file:/C:/Users/sr/.m2/repository/org/apache/npanday/dotnet-registry/1.4.1-incubating-SNAPSHOT/dotnet-registry-1.4.1-incubating-SNAPSHOT.jar
> [ERROR] urls[2] =
> file:/C:/Users/sr/.m2/repository/net/sf/kxml/kxml2/2.1.8/kxml2-2.1.8.jar
> [ERROR] urls[3] =
> file:/C:/Users/sr/.m2/repository/xmlpull/xmlpull/1.1.3.4a/xmlpull-1.1.3.4a.jar
> [ERROR] urls[4] =
> file:/C:/Users/sr/.m2/repository/org/openrdf/openrdf-repository-api/2.0-beta5/openrdf-repository-api-2.0-beta5.jar
> [ERROR] urls[5] =
> file:/C:/Users/sr/.m2/repository/org/openrdf/openrdf-query/2.0-beta5/openrdf-query-2.0-beta5.jar
> [ERROR] urls[6] =
> file:/C:/Users/sr/.m2/repository/org/openrdf/openrdf-sail-api/2.0-beta5/openrdf-sail-api-2.0-beta5.jar
> [ERROR] urls[7] =
> file:/C:/Users/sr/.m2/repository/org/openrdf/openrdf-queryresultio-api/2.0-beta5/openrdf-queryresultio-api-2.0-beta5.jar
> [ERROR] urls[8] =
> file:/C:/Users/sr/.m2/repository/org/openrdf/openrdf-rio-api/2.0-beta5/openrdf-rio-api-2.0-beta5.jar
> [ERROR] urls[9] =
> file:/C:/Users/sr/.m2/repository/info/aduna/aduna-xml/1.2/aduna-xml-1.2.jar
> [ERROR] urls[10] =
> file:/C:/Users/sr/.m2/repository/info/aduna/aduna-lang/1.3/aduna-lang-1.3.jar
> It looks like the java class AssemblyResolverImpl.java. (from the
> dotnet-artifact project) can only use the maven 2 API.
> I tried the following workaround just to see if I could get it work with
> maven 3. I post it here as hack, as it's using reflection to fallback to the
> maven 3 api.
> {code}
> private Map
> artifactMapByArtifactId(java.util.Collection artifacts){
> try{
> for(java.lang.reflect.Method method :
> ArtifactUtils.class.getDeclaredMethods()){
> if (method.getName() == "artifactMapByVersionlessId"){
> return (Map Artifact>)method.invoke(null, new Object[]{artifacts});
> }
> }
> } catch(java.lang.IllegalAccessException e){
> throw new RuntimeException("failed to map artifacts using
> ArtifactUtils class", e);
> }catch(java.lang.reflect.InvocationTargetException e){
> throw new RuntimeException("failed to map artifacts using
> ArtifactUtils class", e);
> }
> return ArtifactUtils.artifactMapByArtifactId( Collections.singleton(
> artifacts )) ;
> }
> public void resolve(Artifact artifact, List remoteRepositories,
> ArtifactRepository localRepository) throws ArtifactResolutionException,
> ArtifactNotFoundException
> {
>
> String mavenProjectRefId = artifact.getGroupId() + ":" +
> artifact.getArtifactId() + ":" + artifact.getVersion();
> MavenProject mavenProjectRef = (MavenProject) mavenProjectRefs.get(
> mavenProjectRefId );
> if ( mavenProjectRef != null )
> {
> if ( "pom".equals( artifact.getType() ) )
> {
>
[jira] [Commented] (NPANDAY-476) Add "Resync references from local repository" in VS addin
[ https://issues.apache.org/jira/browse/NPANDAY-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145599#comment-13145599 ] Lars Corneliussen commented on NPANDAY-476: --- Should this command be explicitely "OFFLINE", hence never try to download the artifact, even if it exists in some remote repo? I think so. > Add "Resync references from local repository" in VS addin > - > > Key: NPANDAY-476 > URL: https://issues.apache.org/jira/browse/NPANDAY-476 > Project: NPanday > Issue Type: New Feature > Components: Visual Studio Add-in >Affects Versions: 1.4-incubating >Reporter: Stoyan Damov >Assignee: Lars Corneliussen >Priority: Minor > Labels: addin, feature, local, references, repository, resync, > vs2010 > Fix For: 1.4.1-incubating > > > *Patch is attached to NPANDAY-322* > As a developer of new modules, I'd like to be able to test & debug & refactor > away the modules before I commit/push them to VCS and get these deployed into > the remote repository by the build server. > This is currently not possible. > I'm working on X and Y (Y depends on X). > I think I'm done on X and install X-1.0-SNAPSHOT in my local repo. > I then add a dependency on X-1.0-SNAPSHOT in Y. > Now, if I make a change in X, I'd like to re-install it in the local repo and > use the updated X-1.0-SNAPSHOT in Y but I don't want to deploy X-1.0-SNAPSHOT > in the remote repo. > However, if I resync the references I'd currently hit NPANDAY-322, or in the > best case I could get someone else's X-1.0-SNAPSHOT (which could have been > updated in the remote repo while I'm working on X as well). However, I want > to get the local repo's X, not the remote one's. > I don't want to push X's changes and wait on the build server to deploy the > new snapshot because I don't want to "hurt" the rest of the developers with > something which might still have bugs in it, and I also don't want to get > other devs's X-1.0-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-322) Resync Reference doesn't update SNAPSHOT artifact from local repository that already exist in .references folder
[ https://issues.apache.org/jira/browse/NPANDAY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145541#comment-13145541 ] Lars Corneliussen commented on NPANDAY-322: --- Hi. My fault. I have no profile in my setting, which makes NPanday complain. I created NPANDAY-478 and fixed it locally. Find my on Skype "lcorneliussen" or on webchat.freenode.net in the #npanday channel > Resync Reference doesn't update SNAPSHOT artifact from local repository that > already exist in .references folder > > > Key: NPANDAY-322 > URL: https://issues.apache.org/jira/browse/NPANDAY-322 > Project: NPanday > Issue Type: Bug > Components: Visual Studio Add-in >Affects Versions: 1.4-incubating >Reporter: Dmitry L >Assignee: Lars Corneliussen >Priority: Minor > Fix For: 1.2.1, 1.4.1-incubating > > Attachments: ArtifactUtils.cs, Connect.cs, > NPANDAY-322_and_NPANDAY-476.diff, ReferenceManager.cs, > TEST-npanday.its.IntegrationTestSuite.xml, > npanday.its.IntegrationTestSuite.txt > > > Steps: > 1. Install Library1 into local maven repo > 2. Add Library1 as dependency using Resync Reference to ProjectA (it will be > copied into .references folder) > 3. Update and reinstall Library1 into local maven repo > 4. Invoke Resync Reference for ProjectA > 5. Error: Library1 won't be updated in .references folder > Expected: newer version (in terms of file timestamp) of Library1 (if any) > should be copied into .references folder from local maven repo during Resync > Reference > Issue exist in trunk r59731 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-322) Resync Reference doesn't update SNAPSHOT artifact from local repository that already exist in .references folder
[ https://issues.apache.org/jira/browse/NPANDAY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145503#comment-13145503 ] Lars Corneliussen commented on NPANDAY-322: --- I still get an exception, if the artifact is not deployed to any of the remote repositories. That's not correct, is it? Both Resync and Resync from Local Repo should work in that case, right? Just that Resync from Local Repo should give local snapshots precedence over remote ones, even if the remote ones are newer. Right, too? > Resync Reference doesn't update SNAPSHOT artifact from local repository that > already exist in .references folder > > > Key: NPANDAY-322 > URL: https://issues.apache.org/jira/browse/NPANDAY-322 > Project: NPanday > Issue Type: Bug > Components: Visual Studio Add-in >Affects Versions: 1.4-incubating >Reporter: Dmitry L >Assignee: Lars Corneliussen >Priority: Minor > Fix For: 1.2.1, 1.4.1-incubating > > Attachments: ArtifactUtils.cs, Connect.cs, > NPANDAY-322_and_NPANDAY-476.diff, ReferenceManager.cs, > TEST-npanday.its.IntegrationTestSuite.xml, > npanday.its.IntegrationTestSuite.txt > > > Steps: > 1. Install Library1 into local maven repo > 2. Add Library1 as dependency using Resync Reference to ProjectA (it will be > copied into .references folder) > 3. Update and reinstall Library1 into local maven repo > 4. Invoke Resync Reference for ProjectA > 5. Error: Library1 won't be updated in .references folder > Expected: newer version (in terms of file timestamp) of Library1 (if any) > should be copied into .references folder from local maven repo during Resync > Reference > Issue exist in trunk r59731 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-322) Resync Reference doesn't update SNAPSHOT artifact from local repository that already exist in .references folder
[ https://issues.apache.org/jira/browse/NPANDAY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144141#comment-13144141 ] Lars Corneliussen commented on NPANDAY-322: --- I have committed the fix without changes. I'll test if it works on my machine next week. > Resync Reference doesn't update SNAPSHOT artifact from local repository that > already exist in .references folder > > > Key: NPANDAY-322 > URL: https://issues.apache.org/jira/browse/NPANDAY-322 > Project: NPanday > Issue Type: Bug > Components: Visual Studio Add-in >Affects Versions: 1.4-incubating >Reporter: Dmitry L >Assignee: Lars Corneliussen >Priority: Minor > Fix For: 1.2.1, 1.4.1-incubating > > Attachments: ArtifactUtils.cs, Connect.cs, > NPANDAY-322_and_NPANDAY-476.diff, ReferenceManager.cs, > TEST-npanday.its.IntegrationTestSuite.xml, > npanday.its.IntegrationTestSuite.txt > > > Steps: > 1. Install Library1 into local maven repo > 2. Add Library1 as dependency using Resync Reference to ProjectA (it will be > copied into .references folder) > 3. Update and reinstall Library1 into local maven repo > 4. Invoke Resync Reference for ProjectA > 5. Error: Library1 won't be updated in .references folder > Expected: newer version (in terms of file timestamp) of Library1 (if any) > should be copied into .references folder from local maven repo during Resync > Reference > Issue exist in trunk r59731 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-322) Resync Reference doesn't update SNAPSHOT artifact from local repository that already exist in .references folder
[ https://issues.apache.org/jira/browse/NPANDAY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143111#comment-13143111 ] Lars Corneliussen commented on NPANDAY-322: --- Sure, comments would be fine. Also, have you run the integration tests locally? I'll test your patch locally tomorrow, and commit it, if it's fine. > Resync Reference doesn't update SNAPSHOT artifact from local repository that > already exist in .references folder > > > Key: NPANDAY-322 > URL: https://issues.apache.org/jira/browse/NPANDAY-322 > Project: NPanday > Issue Type: Bug > Components: Visual Studio Add-in >Affects Versions: 1.4-incubating >Reporter: Dmitry L >Priority: Minor > Fix For: 1.2.1 > > Attachments: ArtifactUtils.cs, Connect.cs, > NPANDAY-322_and_NPANDAY-476.diff, ReferenceManager.cs > > > Steps: > 1. Install Library1 into local maven repo > 2. Add Library1 as dependency using Resync Reference to ProjectA (it will be > copied into .references folder) > 3. Update and reinstall Library1 into local maven repo > 4. Invoke Resync Reference for ProjectA > 5. Error: Library1 won't be updated in .references folder > Expected: newer version (in terms of file timestamp) of Library1 (if any) > should be copied into .references folder from local maven repo during Resync > Reference > Issue exist in trunk r59731 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-322) Resync Reference doesn't update SNAPSHOT artifact from local repository that already exist in .references folder
[ https://issues.apache.org/jira/browse/NPANDAY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143057#comment-13143057 ] Lars Corneliussen commented on NPANDAY-322: --- I can't see, why File.Copy has been changed.. Who made the change? Ask the committer why he made this change.. Also I really, sorry, hate the silent-catches all over NPanday. This is an error - not showing it, doesn't make it any better. > Resync Reference doesn't update SNAPSHOT artifact from local repository that > already exist in .references folder > > > Key: NPANDAY-322 > URL: https://issues.apache.org/jira/browse/NPANDAY-322 > Project: NPanday > Issue Type: Bug > Components: Visual Studio Add-in >Affects Versions: 1.4-incubating >Reporter: Dmitry L >Priority: Minor > Fix For: 1.2.1 > > > Steps: > 1. Install Library1 into local maven repo > 2. Add Library1 as dependency using Resync Reference to ProjectA (it will be > copied into .references folder) > 3. Update and reinstall Library1 into local maven repo > 4. Invoke Resync Reference for ProjectA > 5. Error: Library1 won't be updated in .references folder > Expected: newer version (in terms of file timestamp) of Library1 (if any) > should be copied into .references folder from local maven repo during Resync > Reference > Issue exist in trunk r59731 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-476) Add "Resync references from local repository" in VS addin
[ https://issues.apache.org/jira/browse/NPANDAY-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141983#comment-13141983 ] Lars Corneliussen commented on NPANDAY-476: --- Same here, if you'd like to submit a patch, we'll be happy to apply it. > Add "Resync references from local repository" in VS addin > - > > Key: NPANDAY-476 > URL: https://issues.apache.org/jira/browse/NPANDAY-476 > Project: NPanday > Issue Type: New Feature > Components: Visual Studio Add-in >Affects Versions: 1.4-incubating >Reporter: Stoyan Damov >Priority: Minor > Labels: addin, feature, local, references, repository, resync, > vs2010 > > As a developer of new modules, I'd like to be able to test & debug & refactor > away the modules before I commit/push them to VCS and get these deployed into > the remote repository by the build server. > This is currently not possible. > I'm working on X and Y (Y depends on X). > I think I'm done on X and install X-1.0-SNAPSHOT in my local repo. > I then add a dependency on X-1.0-SNAPSHOT in Y. > Now, if I make a change in X, I'd like to re-install it in the local repo and > use the updated X-1.0-SNAPSHOT in Y but I don't want to deploy X-1.0-SNAPSHOT > in the remote repo. > However, if I resync the references I'd currently hit NPANDAY-322, or in the > best case I could get someone else's X-1.0-SNAPSHOT (which could have been > updated in the remote repo while I'm working on X as well). However, I want > to get the local repo's X, not the remote one's. > I don't want to push X's changes and wait on the build server to deploy the > new snapshot because I don't want to "hurt" the rest of the developers with > something which might still have bugs in it, and I also don't want to get > other devs's X-1.0-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-322) Resync Reference doesn't update SNAPSHOT artifact from local repository that already exist in .references folder
[ https://issues.apache.org/jira/browse/NPANDAY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141980#comment-13141980 ] Lars Corneliussen commented on NPANDAY-322: --- I agree; I even stumbled upon the same problem just a couple of days ago. Would you consider submitting a patch we could then apply? > Resync Reference doesn't update SNAPSHOT artifact from local repository that > already exist in .references folder > > > Key: NPANDAY-322 > URL: https://issues.apache.org/jira/browse/NPANDAY-322 > Project: NPanday > Issue Type: Bug > Components: Visual Studio Add-in >Affects Versions: 1.4-incubating >Reporter: Dmitry L >Priority: Minor > Fix For: 1.2.1 > > > Steps: > 1. Install Library1 into local maven repo > 2. Add Library1 as dependency using Resync Reference to ProjectA (it will be > copied into .references folder) > 3. Update and reinstall Library1 into local maven repo > 4. Invoke Resync Reference for ProjectA > 5. Error: Library1 won't be updated in .references folder > Expected: newer version (in terms of file timestamp) of Library1 (if any) > should be copied into .references folder from local maven repo during Resync > Reference > Issue exist in trunk r59731 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
