svn commit: r1095320 - /incubator/npanday/npanday-its/trunk/src/test/resources/NPandayIT0011SnapshotResolutionTest/test-repo/
Author: lcorneliussen Date: Wed Apr 20 08:33:06 2011 New Revision: 1095320 URL: http://svn.apache.org/viewvc?rev=1095320view=rev Log: Hm. Should have been committed earlier. Removed: incubator/npanday/npanday-its/trunk/src/test/resources/NPandayIT0011SnapshotResolutionTest/test-repo/
[jira] [Resolved] (NPANDAY-401) Mono compiler does not support explicit frameworkVersion 3.5
[ https://issues.apache.org/jira/browse/NPANDAY-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Corneliussen resolved NPANDAY-401. --- Resolution: Fixed Applied the submitted patch. Thanks John! Mono compiler does not support explicit frameworkVersion 3.5 Key: NPANDAY-401 URL: https://issues.apache.org/jira/browse/NPANDAY-401 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.3.1-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 Fix For: 1.3.1-incubating Attachments: mono-compiler-frameworks.diff In 1.3.1-incubating SNAPSHOT on trunk, the logic to locate executables based on frameworkVersion is more strict, and more correct. As a result, with a default frameworkVersion of 2.0.50707 in C:\Users\username\.m2\npanday-settings.xml, any project with code requiring the .Net 3.5 compiler now fails to compile because the 2.0 csc.exe is correctly selected, even though the 3.5 csc.exe may be first on the PATH. Therefore, the frameworkVersion configuration is now required to be specified on the compile plugin, with the value 3.5 in this example. This allows the code to compile correctly as desired on .Net. On Mono, an explicit frameworkVersion of 3.5 fails to match any compiler entry in compiler-plugins.xml. Specifying the additional frameworkVersions for the MONO-CS-2 compiler would allow the Mono compiler to be selected and compile the code correctly. Without this fix, the build fails on Mono with an unsupported platform error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (NPANDAY-398) MojoGenerator can't generate .NET-Mojos referencing a newer NPanday.Plugin.dll
[
https://issues.apache.org/jira/browse/NPANDAY-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Ocaba reassigned NPANDAY-398:
-
Assignee: Joe Ocaba
MojoGenerator can't generate .NET-Mojos referencing a newer NPanday.Plugin.dll
--
Key: NPANDAY-398
URL: https://issues.apache.org/jira/browse/NPANDAY-398
Project: NPanday
Issue Type: Bug
Components: Maven Plugins
Affects Versions: 1.3.1-incubating
Reporter: Lars Corneliussen
Assignee: Joe Ocaba
Fix For: 1.3.1-incubating
When building NPanday against a released version (e.g. trunk -
1.3-incubating), there is a problem generating Mojos.
The .NET-based Plugins we release should reference NPanday.Plugin.dll from
the reactor using ${project.version} - in the current case
1.3.1-incubating-SNAPSHOT. But then the MojoGenerator is used from the
bootstrap-version (1.3-incubating). This one also references (is compiled
against) NPanday.Plugin of 1.3-incubating.
Now, since NPanday.Plugin is strong-named the old MojoGenerator reflects on
the new .NET-based Mojos and runs into a version conflict.
In order to fix this, we have to relax the versioning in MojoGenerator by
listening to AppDomain.AssemblyResolve event and help finding the right
version.
I'm not sure if we can downgrade the version for the Plugin reference, or
if we need to load the newer NPanday.Plugin into the AppDomain and use that
instead.
{code}
NPanday: Start Process = 12.04.2011 09:38:38
targetAssemblyFile=C:\Workbench\NPanday\svn-trunk\plugins\netplugins\NPanday.Plugin.Addin\target\NPanday.Plugin.Addin.dll
outputDirectory=C:\Workbench\NPanday\svn-trunk\plugins\netplugins\NPanday.Plugin.Addin
groupId=npanday.plugin artifactId=NPanday.Plugin.Addin
artifactVersion=1.3.1-incubating-SNAPSHOT
startProcessAssembly=C:\Workbench\NPanday\svn-trunk\target\NPanday.Plugin.MojoGenerator.exe
pluginArtifactPath=C:\Workbench\NPanday\svn-trunk\target\NPanday.Plugin.dll
Creating Plugin Domain Manager
Loading Generator:
C:\Workbench\NPanday\svn-trunk\plugins\netplugins\NPanday.Plugin.Addin\target
Creating Plugin Domain Manager
Assembly :mscorlib
Assembly :NPanday.Plugin
Assembly :NPanday.Plugin.Addin
[INFO]
[INFO] Unhandled Exception: System.InvalidCastException: Unable to cast
object of type 'NPanday.Plugin.FieldAttribute' to type
'NPanday.Plugin.FieldAttribute'.
[INFO]at NPanday.Plugin.Generator.JavaClassUnmarshaller.convert(Type
abstractMojoType, String groupId)
[INFO]at
NPanday.Plugin.Generator.JavaClassUnmarshaller.GetMojosFor(String
assemblyName, String groupId)
[INFO]at
NPanday.Plugin.Generator.JavaClassUnmarshaller.GetMojosFor(String
assemblyName, String groupId)
[INFO]at
NPanday.Plugin.MojoGenerator.Generator.BuildPluginProject(AppDomain
applicationDomain, FileInfo pluginArtifact, FileInfo outputDirectory, String
groupId, String artifactId, String version)
[INFO]at NPanday.Plugin.MojoGenerator.Generator.Main(String[] args)
NPanday: End Process = 12.04.2011 09:38:57; exit code = -532459699
[INFO]
[ERROR] BUILD ERROR
[INFO]
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (NPANDAY-387) Improve the checking of the mirror repos in Reference.cs for artifact resync
[
https://issues.apache.org/jira/browse/NPANDAY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Ocaba reassigned NPANDAY-387:
-
Assignee: Joe Ocaba
Improve the checking of the mirror repos in Reference.cs for artifact resync
Key: NPANDAY-387
URL: https://issues.apache.org/jira/browse/NPANDAY-387
Project: NPanday
Issue Type: Improvement
Components: Project Importer
Affects Versions: 1.2.1
Reporter: Joe Ocaba
Assignee: Joe Ocaba
Fix For: 1.3.1-incubating
foreach (Mirror mirror in settings.mirrors)
{
string id = mirror.mirrorOf;
- if (id == external:*)
id = *;
// TODO: support '!' syntax
mirrors.Add(id, mirror.url);
}
change the condition to start of instead of exact match
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-412) Execuable path for Windows 7 SDK is not auto-detected when npanday-settings.xml is generated, resgen.exe not found
[
https://issues.apache.org/jira/browse/NPANDAY-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022042#comment-13022042
]
Lars Corneliussen commented on NPANDAY-412:
---
On my machine this specific portion looks like this:
{code}
vendor
vendorNameMICROSOFT/vendorName
vendorVersion2.0.50727/vendorVersion
frameworks
framework
frameworkVersion2.0.50727/frameworkVersion
installRootC:\Windows\Microsoft.NET\Framework64\v2.0.50727/installRoot
sdkInstallRootC:\Program Files\Microsoft.NET\SDK\v2.0
64bit\/sdkInstallRoot
executablePaths
executablePathC:\Program Files\Microsoft.NET\SDK\v2.0
64bit\bin/executablePath
/executablePaths
/framework
/frameworks
/vendor
{code}
But how is that related to Windows 7 SDK? Windows 7 SDK only installs .NET SDK
3.5 + 4.0 (in my case 7.0a)
{code}
vendor
vendorNameMICROSOFT/vendorName
vendorVersion3.5/vendorVersion
frameworks
framework
frameworkVersion3.5/frameworkVersion
installRootC:\Windows\Microsoft.NET\Framework64\v3.5/installRoot
sdkInstallRootC:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Bin\/sdkInstallRoot
/framework
/frameworks
/vendor
vendor
vendorNameMICROSOFT/vendorName
vendorVersion4.0/vendorVersion
frameworks
framework
frameworkVersion4.0/frameworkVersion
installRootC:\Windows\Microsoft.NET\Framework64\v4.0.30319/installRoot
sdkInstallRootC:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\/sdkInstallRoot
/framework
/frameworks
/vendor
{code}
These are the paths we look up for .NET 2.0 in the registry. Can you check out
where your key is located in the registry?
{code:title=DotnetSdkLocator.cs}
SOFTWARE\Microsoft\.NETFramework\sdkInstallRootv2.0
SOFTWARE\Microsoft\SDKs\.NETFramework\v2.0\InstallationFolder)
{code}
Codefile:
https://svn.apache.org/repos/asf/incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/src/main/csharp/NPanday/Plugin/Settings/DotnetSdkLocator.cs
Execuable path for Windows 7 SDK is not auto-detected when
npanday-settings.xml is generated, resgen.exe not found
--
Key: NPANDAY-412
URL: https://issues.apache.org/jira/browse/NPANDAY-412
Project: NPanday
Issue Type: Bug
Components: Maven Plugins
Affects Versions: 1.3.1-incubating
Environment: C:\Users\jfallowsmvn -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
The executable paths in npanday-settings.xml make it unnecessary to manually
modify the command shell path for executables such as mcs.exe, xsd.exe, etc.
However, resgen.exe is also needed during the NPanday project lifecycle, but
is distributed with Windows SDK rather than .Net SDK. To address this, the
executable path can be updated for each vendor entry to include a reference
to the Window SDK location such that resgen.exe can be found via
executablePath at runtime.
When npanday-settings.xml is generated, these executablePath entries are not
present, causing issues when resgen.exe cannot be located, while all the
other executables can be located successfully.
See below for an example:
{code}
?xml version=1.0 encoding=utf-8?
npandaySettings xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
operatingSystemMicrosoft Windows NT 6.1.7600.0/operatingSystem
defaultSetup
vendorNameMICROSOFT/vendorName
vendorVersion2.0.50727/vendorVersion
frameworkVersion2.0.50727/frameworkVersion
/defaultSetup
vendors
vendor
vendorNameMICROSOFT/vendorName
vendorVersion2.0.50727/vendorVersion
frameworks
framework
frameworkVersion2.0.50727/frameworkVersion
installRootC:\Windows\Microsoft.NET\Framework64\v2.0.50727/installRoot
executablePaths
executablePathC:\Program Files\\Microsoft
SDKs\Windows\v6.0A\bin/executablePath
/executablePaths
/framework
/frameworks
/vendor
...
/vendors
/npandaySettings
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NPANDAY-412) Execuable path for Windows 7 SDK is not auto-detected when npanday-settings.xml is generated, resgen.exe not found
[
https://issues.apache.org/jira/browse/NPANDAY-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Corneliussen updated NPANDAY-412:
--
Fix Version/s: 1.3.1-incubating
Assignee: Lars Corneliussen
Execuable path for Windows 7 SDK is not auto-detected when
npanday-settings.xml is generated, resgen.exe not found
--
Key: NPANDAY-412
URL: https://issues.apache.org/jira/browse/NPANDAY-412
Project: NPanday
Issue Type: Bug
Components: Maven Plugins
Affects Versions: 1.3.1-incubating
Environment: C:\Users\jfallowsmvn -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.3.1-incubating
The executable paths in npanday-settings.xml make it unnecessary to manually
modify the command shell path for executables such as mcs.exe, xsd.exe, etc.
However, resgen.exe is also needed during the NPanday project lifecycle, but
is distributed with Windows SDK rather than .Net SDK. To address this, the
executable path can be updated for each vendor entry to include a reference
to the Window SDK location such that resgen.exe can be found via
executablePath at runtime.
When npanday-settings.xml is generated, these executablePath entries are not
present, causing issues when resgen.exe cannot be located, while all the
other executables can be located successfully.
See below for an example:
{code}
?xml version=1.0 encoding=utf-8?
npandaySettings xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
operatingSystemMicrosoft Windows NT 6.1.7600.0/operatingSystem
defaultSetup
vendorNameMICROSOFT/vendorName
vendorVersion2.0.50727/vendorVersion
frameworkVersion2.0.50727/frameworkVersion
/defaultSetup
vendors
vendor
vendorNameMICROSOFT/vendorName
vendorVersion2.0.50727/vendorVersion
frameworks
framework
frameworkVersion2.0.50727/frameworkVersion
installRootC:\Windows\Microsoft.NET\Framework64\v2.0.50727/installRoot
executablePaths
executablePathC:\Program Files\\Microsoft
SDKs\Windows\v6.0A\bin/executablePath
/executablePaths
/framework
/frameworks
/vendor
...
/vendors
/npandaySettings
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NPANDAY-407) Wrong Unit test (on Mac) for status return from command not found
[ https://issues.apache.org/jira/browse/NPANDAY-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Corneliussen resolved NPANDAY-407. --- Resolution: Fixed Fix Version/s: 1.3.1-incubating patch applied in trunk Wrong Unit test (on Mac) for status return from command not found --- Key: NPANDAY-407 URL: https://issues.apache.org/jira/browse/NPANDAY-407 Project: NPanday Issue Type: Bug Components: Development Setup Affects Versions: 1.3.1-incubating Reporter: Matthias Weßendorf Fix For: 1.3.1-incubating Attachments: NPANDAY-407.diff, NPANDAY-407_NEW.diff Running the testTooLongCommandName() test on Mac fails. The reson is that Mac (bash gnu) returns code 127 (command not found). The generated command is this: /bin/bash -c and since the x is not available - the test fails. Looks like on Windows this is return code 1 (I was expecting that on Ubuntu this fails as well - perhaps has not been tested?) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-400) Mono missing system libraries references during compilation
[ https://issues.apache.org/jira/browse/NPANDAY-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022136#comment-13022136 ] Lars Corneliussen commented on NPANDAY-400: --- As you are a committer now, would you apply the patches yourself? Or should I? Mono missing system libraries references during compilation --- Key: NPANDAY-400 URL: https://issues.apache.org/jira/browse/NPANDAY-400 Project: NPanday Issue Type: Bug Components: Maven Plugins Affects Versions: 1.3.1-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 Attachments: mono-system-references.diff CSharpCompilerForProfile used by MICROSOFT 3.5 compiler automatically adds system library references during compilation, so code using System libraries will compile as desired on .Net. DefaultCompiler used by MONO compiler does not add any system library references during compilation, so code using System libraries fails to compile on Mono. Fix discussed on IRC would add the Mono system libraries in DefaultCompiler to get consistent behavior with Mono and .Net. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NPANDAY-411) Transitive dependency resolution requires explicit version in a dependent child pom
[
https://issues.apache.org/jira/browse/NPANDAY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022165#comment-13022165
]
Brett Porter commented on NPANDAY-411:
--
The original issue was worked around, but the root issue is that NPanday
doesn't use Maven's POM construction and resolution, but reproduces much of it
it imperfectly. We're in a long process of removing that.
Transitive dependency resolution requires explicit version in a dependent
child pom
---
Key: NPANDAY-411
URL: https://issues.apache.org/jira/browse/NPANDAY-411
Project: NPanday
Issue Type: Bug
Components: Maven Plugins
Affects Versions: 1.3.1-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
In the past, NPanday required the version of a dependency in pom.xml to be
explicit, whereas now that has been fixed so that a parent pom.xml can
specify the version in the dependencyManagement section instead.
Suppose we have 3 projects called Parent, Library and Executable. The Parent
pom refers to both Library and Executable projects as modules, and also acts
as the super pom for both Library and Executable projects. The Executable
project depends on the Library project. The Parent project defaults the
version of another dotnet-library (let's say ThirdParty) used by the Library
project in the Parent's dependencyManagement section.
The Library project builds successfully. However, when attempting to build
the Executable project, it complains during dependency resolution that the
version is missing from ThirdParty and the build fails. Now, while the
version is physically missing from the Library pom.xml file, it is not
missing from the effective pom for the Library and should therefore not give
any error, just as no error is given when the Library project builds.
{code}
WARNING: NPANDAY-180-003: Project Version is missing: Group Id = NUnit,
Artifact Id = NUnit.Framework
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at npanday.dao.Project.hashCode(Project.java:329)
at java.util.HashMap.put(HashMap.java:372)
at java.util.HashSet.add(HashSet.java:200)
at npanday.dao.Project.addProjectDependency(Project.java:204)
at npanday.dao.ProjectFactory.createProjectFrom(ProjectFactory.java:147)
at
npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:866)
at
npanday.dao.impl.ProjectDaoImpl.storeProjectAndResolveDependencies(ProjectDaoImpl.java:414)
at
npanday.artifact.impl.AssemblyResolverImpl.resolveTransitivelyFor(AssemblyResolverImpl.java:131)
at
npanday.plugin.compile.ComponentInitializerMojo.execute(ComponentInitializerMojo.java:86)
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
[jira] [Commented] (NPANDAY-416) Tests in projects whose paths contains spaces fails: Reason: maven-test-plugin resolves to plexus-utils:1.1
[
https://issues.apache.org/jira/browse/NPANDAY-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1306#comment-1306
]
Lars Corneliussen commented on NPANDAY-416:
---
Making the dependency explicit on dotnet-executable does not help.
Specifying it directly on the maven-test-plugin does help. On the parent is
neither enough. So what to do?
Tests in projects whose paths contains spaces fails: Reason:
maven-test-plugin resolves to plexus-utils:1.1
Key: NPANDAY-416
URL: https://issues.apache.org/jira/browse/NPANDAY-416
Project: NPanday
Issue Type: Bug
Components: Maven Plugins
Affects Versions: 1.3.1-incubating
Reporter: Lars Corneliussen
Fix For: 1.3.1-incubating
Again I found a problem in the handling of quotes and whitespaces. It occurs,
when I try to run tests on a project that has Spaces in the path.
{code:title=As executed by NPanday}
CMD.EXE /X /C nunit-console L:\Writing\dotnetpro\NPanday\hello-npanday-vs
(Plus
Tests)\HelloNPanday\HelloNPanday.Logic.Test\target/test-assemblies\HelloNPanday.Logic.Test-test.dll
/xml:L:\Writing\dotnetpro\NPanday\hello-npanday-vs (Plus
Tests)\HelloNPanday\HelloNPanday.Logic.Test\target\nunit-reports\TEST-HelloNPanday.Logic.Test-1.0-SNAPSHOT.xml
/output:L:\Writing\dotnetpro\NPanday\hello-npanday-vs (Plus
Tests)\HelloNPanday\HelloNPanday.Logic.Test\target\nunit-reports\TEST-HelloNPanday.Logic.Test-1.0-SNAPSHOT-RESULTS.txt
/err:L:\Writing\dotnetpro\NPanday\hello-npanday-vs (Plus
Tests)\HelloNPanday\HelloNPanday.Logic.Test\target\nunit-reports\TEST-HelloNPanday.Logic.Test-1.0-SNAPSHOT-ERROR.txt
/labels
{code}
{code:title=As it should be}
CMD.EXE /X /C nunit-console L:\Writing\dotnetpro\NPanday\hello-npanday-vs
(Plus
Tests)\HelloNPanday\HelloNPanday.Logic.Test\target/test-assemblies\HelloNPanday.Logic.Test-test.dll
/xml:L:\Writing\dotnetpro\NPanday\hello-npanday-vs (Plus
Tests)\HelloNPanday\HelloNPanday.Logic.Test\target\nunit-reports\TEST-HelloNPanday.Logic.Test-1.0-SNAPSHOT.xml
/output:L:\Writing\dotnetpro\NPanday\hello-npanday-vs (Plus
Tests)\HelloNPanday\HelloNPanday.Logic.Test\target\nunit-reports\TEST-HelloNPanday.Logic.Test-1.0-SNAPSHOT-RESULTS.txt
/err:L:\Writing\dotnetpro\NPanday\hello-npanday-vs (Plus
Tests)\HelloNPanday\HelloNPanday.Logic.Test\target\nunit-reports\TEST-HelloNPanday.Logic.Test-1.0-SNAPSHOT-ERROR.txt
/labels
{code}
Crap, crap, crap. I just found out, that the problem is because at runtime,
the wrong plexus-utils version is resolved :((
Different versions used are:
* 1.0.4 - fails with MethodMissing
* 1.1 - seems to be used
* 1.4.1 - from here would be ok
* 1.4.5
* 1.5.1
* 1.5.5
Even if the test-plugin should resolve to 1.4.5:
{code}
[DEBUG] maven-test-plugin: using locally installed snapshot
[DEBUG] Adding managed dependencies for unknown:maven-test-plugin
[DEBUG] npanday:dotnet-assembler:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-dao-project:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-executable:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-artifact:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-plugin:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-registry:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-repository:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-core:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-vendor:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-model-netdependency:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-model-assembly-plugins:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-model-compiler-plugins:jar:1.3.1-incubating-SNAPSHOT
[DEBUG]
npanday:dotnet-model-executable-plugins:jar:1.3.1-incubating-SNAPSHOT
[DEBUG]
npanday:dotnet-model-configuration-appenders:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] npanday:dotnet-model-settings:jar:1.3.1-incubating-SNAPSHOT
[DEBUG] org.apache.maven:maven-core:jar:2.0.9
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.9
[DEBUG] org.apache.maven:maven-project:jar:2.0.9
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.9
[DEBUG] net.sf.kxml:kxml2:jar:2.1.8
[DEBUG] xmlpull:xmlpull:jar:1.1.3.4a
[DEBUG] org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-9
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.4.5
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-32
[DEBUG] org.codehaus.plexus:plexus-component-api:jar:1.0-alpha-32
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:1.2-alpha-10
[DEBUG] org.slf4j:slf4j-jdk14:jar:1.5.11
[DEBUG] org.slf4j:slf4j-api:jar:1.5.11
{code}
Finding this in many places in the log. Which rule makes 1.1 override 1.4.5?
{code}
svn propchange: r1094846 - svn:log
Author: apadilla Revision: 1094846 Modified property: svn:log Modified: svn:log at Thu Apr 21 03:14:28 2011 -- --- svn:log (original) +++ svn:log Thu Apr 21 03:14:28 2011 @@ -1 +1,3 @@ -[NPANDAY-397] - updated fix and added unit tests +[NPANDAY-397] +- stripped off extra \\ in project FullFileName before parsing the path into tokens (instead of traversing back the array if last index is empty) +- added unit tests
