from:"Lars Corneliussen"


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

Lars Corneliussen updated NPANDAY-402:
--

Summary: Add support to automatically attach and resolve PDB-symbols   
(was: Add support to automatically attach and resolve PDB-symbols and 
Code-Documentation (comment.xml) )

 Add support to automatically attach and resolve PDB-symbols 
 

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


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



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

[jira] [Created] (NPANDAY-634) Automatically attach (and resolve) VS Code Documentation files (comment.xml)

Lars Corneliussen created NPANDAY-634:
-

 Summary: Automatically attach (and resolve) VS Code Documentation 
files (comment.xml)
 Key: NPANDAY-634
 URL: https://issues.apache.org/jira/browse/NPANDAY-634
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Lars Corneliussen
Priority: Minor
 Fix For: Backlog


With NPANDAY-402 we introduced attaching and resolving PDBs. Also handling 
Code-Documentation files should be an quite easy addition.



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

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


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

Lars Corneliussen updated NPANDAY-402:
--

Summary: Add support to automatically attach and resolve PDB-symbols  (was: 
Add support to automatically attach and resolve PDB-symbols )

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

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


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



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

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


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

Lars Corneliussen commented on NPANDAY-599:
---

We talked about making i a per-project somehow, didn't we?

[code]
[07.08.2014 12:04:04] Lars Corneliussen: iirc somehow the deps were cached 
between reactor projects
[07.08.2014 12:04:34] Lars Corneliussen: but I can't remember what happend 
then... if it failed, or if it just included pdbs you wouldn't want...
[07.08.2014 12:06:07] Brett Porter (NPanday team): can see why it could be a 
problem, maybe better just to have the cache be mapped per project instead
[07.08.2014 12:09:19] Lars Corneliussen: if per-project is available, it seems 
much more approprieate than per-lookup1
[07.08.2014 12:22:07] Brett Porter (NPanday team): no per project lookup, but 
we can do that in the maps
[code]

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

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


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



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

AW: Release 1.5.0 ??

2014-08-21 Thread Lars Corneliussen // Zen

I think we should just release it as it is and take it from there. 
The snapshot-version has been in use for quite a while now.

Last issue to resolve would be 
https://issues.apache.org/jira/browse/NPANDAY-599

Brett, you talked about somehow caching the resolver per project. I think if
that's done we're fine and can close 599 and thus 402.

-Ursprüngliche Nachricht-
Von: Brett Porter [mailto:br...@porterclan.net] Im Auftrag von Brett Porter
Gesendet: Donnerstag, 21. August 2014 02:43
An: npanday-dev@incubator.apache.org
Betreff: Re: Release 1.5.0 ??

Thanks for the review and the nudge here Konstantin.

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

Do any others have a moment to look through them?

Thanks,
Brett

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

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

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


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

Lars Corneliussen reassigned NPANDAY-454:
-

Assignee: Brett Porter  (was: Lars Corneliussen)

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

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


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



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

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


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

Lars Corneliussen reassigned NPANDAY-599:
-

Assignee: Brett Porter  (was: Lars Corneliussen)

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

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


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



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

[jira] [Commented] (NPANDAY-499) Make configuration for compiler-plugins and executable-plugins more flexible


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

Lars Corneliussen commented on NPANDAY-499:
---

[~brettporter] It's a long time ago :-( - I guess we had plans to do more for 
better clarity, but it is optional work.

 Make configuration for compiler-plugins and executable-plugins more flexible
 

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


 Currently all configuration for compiler-plugins and executable-plugins are 
 located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
 h3. Design
 * (/) Plugins should be able to contribute their own configurations 
 (for example: the test-plugin should specify where to find nunit; currently 
 it is specified in dotnet-core)
 * Mojos should accept additional configurations as parameters (if 
 probingPaths do not match, or a new version has not yet made it into NPanday) 
 * It should be configurable per 'plugin' and overrideable through a Mojo 
 param / project-level-property, whether or not NPanday should try to run the 
 command from the %PATH%
 h3. Location of the right executable
 * Use 'identifier' to instead of 'profile' for locating the correct 
 executable-plugin; still allowing profile for customizing.
 * Enable version ranges for matching of versions in executables and compilers 
 for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}] 
 or {{[2.0,3.0)}}
 * (/) It should be possible to configure executableVersion additionally to 
 vendorVersion and frameworkVersion (for example in order to locate path's for 
 Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
 h3. Path detection
 * (/) Enable filtering in configuration files, supporting Windows Registry, 
 Environment Variables and (!) project properties
 h3. Naming and overall structure
 * (/) (A) Mojo comes with *Requirement and *Config, (B) Repository delivers 
 *Capability which is based on *Plugins; Then we try to match (A) with (B).
 * Rebrand 'plugin' to 'capability-configuration', hence 
 CompilerExecutableCapabilityConfiguration (?)
 * Rename 'vendor' and 'vendorVersion' to 'frameworkVendor' and 
 'frameworkVendorVersion' for better clarity (?) 
 * Join executable-plugins and compiler-plugins into one model (MDO + base 
 classes for Capability
 * distinguish three types of executables:
 ** *VendorExecutable* (is provided by the framework vendor
 ** *CompilerExecutable* (is also provided by the framwork vendor, but has 
 some extra requirements/capabilities
 ** *ThirdpartyExecutable* (is provided by a third party, hence neither 
 NPanday nor the vendor; adds 'probingPaths' and 'executableVersion')
 h3. Execution and Mojo Interaction
 * Refactor ExecutableRequirement.ctor to accept VendorRequirment + 
 executableIdentifier, executableVersion and executableProfile.
 * Remove get/setCommands() from ExecutableConfig, and require them to be 
 passed in to NetExecutable#execute() as parameter - 
 NetExecutable#execute(ListString commands) / filtering will happen inside
 * Provide utility methods, that handle exception conversions for Mojos (wrap 
 PlatformUnsupportedException and ExecutionException) in 
 MojoExecutionExceptions



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

[jira] [Assigned] (NPANDAY-499) Make configuration for compiler-plugins and executable-plugins more flexible


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

Lars Corneliussen reassigned NPANDAY-499:
-

Assignee: Brett Porter  (was: Lars Corneliussen)

 Make configuration for compiler-plugins and executable-plugins more flexible
 

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


 Currently all configuration for compiler-plugins and executable-plugins are 
 located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
 h3. Design
 * (/) Plugins should be able to contribute their own configurations 
 (for example: the test-plugin should specify where to find nunit; currently 
 it is specified in dotnet-core)
 * Mojos should accept additional configurations as parameters (if 
 probingPaths do not match, or a new version has not yet made it into NPanday) 
 * It should be configurable per 'plugin' and overrideable through a Mojo 
 param / project-level-property, whether or not NPanday should try to run the 
 command from the %PATH%
 h3. Location of the right executable
 * Use 'identifier' to instead of 'profile' for locating the correct 
 executable-plugin; still allowing profile for customizing.
 * Enable version ranges for matching of versions in executables and compilers 
 for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}] 
 or {{[2.0,3.0)}}
 * (/) It should be possible to configure executableVersion additionally to 
 vendorVersion and frameworkVersion (for example in order to locate path's for 
 Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
 h3. Path detection
 * (/) Enable filtering in configuration files, supporting Windows Registry, 
 Environment Variables and (!) project properties
 h3. Naming and overall structure
 * (/) (A) Mojo comes with *Requirement and *Config, (B) Repository delivers 
 *Capability which is based on *Plugins; Then we try to match (A) with (B).
 * Rebrand 'plugin' to 'capability-configuration', hence 
 CompilerExecutableCapabilityConfiguration (?)
 * Rename 'vendor' and 'vendorVersion' to 'frameworkVendor' and 
 'frameworkVendorVersion' for better clarity (?) 
 * Join executable-plugins and compiler-plugins into one model (MDO + base 
 classes for Capability
 * distinguish three types of executables:
 ** *VendorExecutable* (is provided by the framework vendor
 ** *CompilerExecutable* (is also provided by the framwork vendor, but has 
 some extra requirements/capabilities
 ** *ThirdpartyExecutable* (is provided by a third party, hence neither 
 NPanday nor the vendor; adds 'probingPaths' and 'executableVersion')
 h3. Execution and Mojo Interaction
 * Refactor ExecutableRequirement.ctor to accept VendorRequirment + 
 executableIdentifier, executableVersion and executableProfile.
 * Remove get/setCommands() from ExecutableConfig, and require them to be 
 passed in to NetExecutable#execute() as parameter - 
 NetExecutable#execute(ListString commands) / filtering will happen inside
 * Provide utility methods, that handle exception conversions for Mojos (wrap 
 PlatformUnsupportedException and ExecutionException) in 
 MojoExecutionExceptions



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

[jira] [Commented] (NPANDAY-402) Add support to automatically attach and resolve PDB-symbols and Code-Documentation (comment.xml)


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

Lars Corneliussen commented on NPANDAY-402:
---

[~brettporter] PDB-symbols get attached. comment.xml is not yet getting 
attatched. Also the subtasks are still real issues - but we could say they are 
known bugs :-)

 Add support to automatically attach and resolve PDB-symbols and 
 Code-Documentation (comment.xml) 
 -

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


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



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

[jira] [Resolved] (NPANDAY-597) Disable transitivity for pdb-artifacts


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

Lars Corneliussen resolved NPANDAY-597.
---

Resolution: Fixed

 Disable transitivity for pdb-artifacts
 --

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






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

[jira] [Closed] (NPANDAY-595) Option to disable PDB-resolving (disabled by default?)


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

Lars Corneliussen closed NPANDAY-595.
-

Resolution: Fixed

 Option to disable PDB-resolving (disabled by default?)
 --

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


 I think it is not necessary to resolve pdbs by default.
 It should at least be enough to resolve them for testing (although, if it 
 slows down passing tests, it might be better not to have nice stacktraces - 
 but that could be optional).



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

[jira] [Resolved] (NPANDAY-566) Custom NPanday-aware copy-dependencies / list-dependencies plugin


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

Lars Corneliussen resolved NPANDAY-566.
---

Resolution: Fixed

 Custom NPanday-aware copy-dependencies / list-dependencies plugin
 -

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


 When copying dependencies we have to run our own resolver, and we'd also like 
 to copy along pdb+xml+... as soon as we have those...



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

[jira] [Resolved] (NPANDAY-575) Copy pdb files into test assembly directory


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

Lars Corneliussen resolved NPANDAY-575.
---

Resolution: Fixed

 Copy pdb files into test assembly directory
 ---

 Key: NPANDAY-575
 URL: https://issues.apache.org/jira/browse/NPANDAY-575
 Project: NPanday
  Issue Type: New Feature
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Victor Stefoglo
Assignee: Lars Corneliussen
Priority: Minor
 Fix For: 1.5.0-incubating

 Attachments: ExampleProject.zip, dotnet-core.patch, 
 maven-test-plugin.patch


 Some coverage tools as OpenCover, PartCover require pdb files to be present.
 We use test assembly directory, for coverage tools, and we have a workaround 
 to copy pdb files to test assembly directory (using copy-maven-plugin). I 
 think this should be done by Npanday maven-test-plugin, now It copy all 
 dependency artifacts but generated pdb files are ignored. 



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

[jira] [Updated] (NPANDAY-402) Add support to automatically attach and resolve PDB-symbols and Code-Documentation (comment.xml)

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

Lars Corneliussen updated NPANDAY-402:
--

Description:
h2. ISSUES/TODO

* Integration tests missing
* impl for attaching comments.xml missing
* created subtasks (/)

h2. Original Description

The comments.xml file generated during CSharp compilation needs to be shipped
to developers for use in Visual Studio, similar to the javadoc artifact
produced by Maven for Java projects.

This is not currently attached as an artifact during the NPanday build for
dotnet-library.

was:
h2. ISSUES/TODO

* Integration tests missing
* created subtasks (/)

h2. Original Description

The comments.xml file generated during CSharp compilation needs to be shipped
to developers for use in Visual Studio, similar to the javadoc artifact
produced by Maven for Java projects.

This is not currently attached as an artifact during the NPanday build for
dotnet-library.

Add support to automatically attach and resolve PDB-symbols and
Code-Documentation (comment.xml)
-

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

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

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

[jira] [Commented] (NPANDAY-563) Generic MSDeploy synchronization mojo

2014-06-28 Thread Lars Corneliussen (JIRA)


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

Lars Corneliussen commented on NPANDAY-563:
---

agreed.

 Generic MSDeploy synchronization mojo
 -

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






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

[jira] [Commented] (NPANDAY-556) Importer for Nuget Packages

2014-06-28 Thread Lars Corneliussen (JIRA)


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

Lars Corneliussen commented on NPANDAY-556:
---

So; close and mark as resolve?

 Importer for Nuget Packages
 ---

 Key: NPANDAY-556
 URL: https://issues.apache.org/jira/browse/NPANDAY-556
 Project: NPanday
  Issue Type: New Feature
  Components: Development Setup, Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Lars Corneliussen
Assignee: Lars Corneliussen
  Labels: nuget
 Fix For: 1.5.0-incubating


 Nuget Packages are much broader than Maven Artifacts. Our first thought was 
 to implement a repository layout that would enable for resolving nuget 
 packages directly (see NPANDAY-372).
 But those packages come in various shapes and are not as easily converted to 
 {{dotnet-library}} artifacts as first thought.
 h3. Library Importer
 Instead we will create a plugin, that helps importing nuget packages (and 
 soon also plain DLL-libs) into maven artifacts. As a general rule, each DLL 
 contained in a single {{nupkg}} will result in a separate maven artifact.
 Some of the challenges we see:
 h4. Versions
 Nuget packages (and dlls) have four version numbers while maven only has 
 three. In most cases those are not used in nuget, but if, there has to be 
 some manual mapping.
 h4. Multi-targeted packages
 Nuget packages may contain libraries for different target frameworks (net20, 
 35, wp, sl, ...); something that we'd like to support in NPanday too 
 (NPANDAY-405)
 As a first approach, you'll have to specify which of the versions to import.
 We could also support a mapping from framework versions to maven version 
 qualifiers, as for example {{1.2-net20}}
 h4. Dependencies
 Since there is no easy mapping from package to artifact, it is not that easy 
 to convert the dependencies either. For each import it will be necessary to 
 specify how the reps are mapped.
 h4. Prerelease versions
 Nuget = 1.6 does also support prerelease versions. These should be mapped to 
 SNAPSHOT, if possible.
 h4. What more?
 Please comment or edit, if you see more challenges that I haven't seen yet.
 h2. Technical approach
 A plugin with it's own lifecycle will 'compile' import declarations and then 
 perform the import on 'compile'; then install and deploy the imported 
 packages on the corresponding maven life cycles 'install' and 'deploy'.
 {code:title=example import declaration}
 libs xmlns=http://npanday.apache.org/library-import/1.0.0;
   nuget
 packageNUnit/package
 version source=2.6.0.12054 mapTo=2.6.0/
 version source=2.5.10.11092 mapTo=2.5.10/
 libDirs
   defaultnet40/default
 /libDirs
   /nuget
 /libs
 {code}



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

[jira] [Commented] (NPANDAY-556) Importer for Nuget Packages

2014-06-28 Thread Lars Corneliussen (JIRA)


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

Lars Corneliussen commented on NPANDAY-556:
---

ups. didn't see the FIXED :-) thanks.

 Importer for Nuget Packages
 ---

 Key: NPANDAY-556
 URL: https://issues.apache.org/jira/browse/NPANDAY-556
 Project: NPanday
  Issue Type: New Feature
  Components: Development Setup, Maven Plugins
Affects Versions: 1.5.0-incubating
Reporter: Lars Corneliussen
Assignee: Lars Corneliussen
  Labels: nuget
 Fix For: 1.5.0-incubating


 Nuget Packages are much broader than Maven Artifacts. Our first thought was 
 to implement a repository layout that would enable for resolving nuget 
 packages directly (see NPANDAY-372).
 But those packages come in various shapes and are not as easily converted to 
 {{dotnet-library}} artifacts as first thought.
 h3. Library Importer
 Instead we will create a plugin, that helps importing nuget packages (and 
 soon also plain DLL-libs) into maven artifacts. As a general rule, each DLL 
 contained in a single {{nupkg}} will result in a separate maven artifact.
 Some of the challenges we see:
 h4. Versions
 Nuget packages (and dlls) have four version numbers while maven only has 
 three. In most cases those are not used in nuget, but if, there has to be 
 some manual mapping.
 h4. Multi-targeted packages
 Nuget packages may contain libraries for different target frameworks (net20, 
 35, wp, sl, ...); something that we'd like to support in NPanday too 
 (NPANDAY-405)
 As a first approach, you'll have to specify which of the versions to import.
 We could also support a mapping from framework versions to maven version 
 qualifiers, as for example {{1.2-net20}}
 h4. Dependencies
 Since there is no easy mapping from package to artifact, it is not that easy 
 to convert the dependencies either. For each import it will be necessary to 
 specify how the reps are mapped.
 h4. Prerelease versions
 Nuget = 1.6 does also support prerelease versions. These should be mapped to 
 SNAPSHOT, if possible.
 h4. What more?
 Please comment or edit, if you see more challenges that I haven't seen yet.
 h2. Technical approach
 A plugin with it's own lifecycle will 'compile' import declarations and then 
 perform the import on 'compile'; then install and deploy the imported 
 packages on the corresponding maven life cycles 'install' and 'deploy'.
 {code:title=example import declaration}
 libs xmlns=http://npanday.apache.org/library-import/1.0.0;
   nuget
 packageNUnit/package
 version source=2.6.0.12054 mapTo=2.6.0/
 version source=2.5.10.11092 mapTo=2.5.10/
 libDirs
   defaultnet40/default
 /libDirs
   /nuget
 /libs
 {code}



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

AW: NPanday incubator report

2014-06-14 Thread Lars Corneliussen // Zen

Hi Roman,

Raphael Bircher signed up as a mentor in late 2013.

Currently we have noone investing in the project. Brett and I do from time to 
time implement new features we need, do fixes whenever we (or our customers) 
get stuck.

We also have some people providing patches here and then - but it's the same 
for them - they do it, when they get stuck.

I think nearby everyone is using 1.5.0-SNAPSHOT at the moment anyway. It could 
just be released - even with bugs and regression issues.

I don't really know how to do the release, and Brett doesn't either find the 
time, I guess :-)

Still I see a good future for NPanday. The official Microsoft alternatives 
are just too bad. But still it's hard to convince Microsoft-people to have a 
look at NPanday - they get scared when the hear the word java. :-)
_
Lars

-Ursprüngliche Nachricht-
Von: odeach...@gmail.com [mailto:odeach...@gmail.com] Im Auftrag von Deng 
Ching-Mallete
Gesendet: Freitag, 13. Juni 2014 05:46
An: npanday-dev
Cc: mat...@apache.org; r...@apache.org
Betreff: Re: NPanday incubator report

Hi Roman,

My apologies, I didn't see your email immediately. Unfortunately, I am no 
longer an active mentor for NPanday. I've already stepped down as mentor for 
the project over a year ago so I am not quite up to date with what's happening 
on the project.

I took a quick look now at the Jira and commit notifications, and the last 
commit was on April 4. There were also a number of tickets reported in the 
recent weeks, but there doesn't seem to be anyone actively working on them.
Hope this somewhat helps!

Thanks,
Deng

On Fri, Jun 13, 2014 at 11:22 AM, Roman Shaposhnik r...@apache.org wrote:

 On Tue, Jun 10, 2014 at 1:18 AM, David Akehurst d...@akehurst.net wrote:
  I hope the project has not gone dormant.
  I still actively use it, and hoping for its continued development 
  and eventual (soon) promotion from incubating.

 At the very minimum the project would require some active mentors. 
 Hang in there -- we'll try to resolve this at IPMC level.

 Thanks,
 Roman.

[jira] [Commented] (NPANDAY-623) Support reactor reference to other modules at compile phase

2014-06-12 Thread Lars Corneliussen (JIRA)

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

Lars Corneliussen commented on NPANDAY-623:
---

Hi, you are right! Doesn*t like, that compile doesn't use final name - i think
it should.

But in the .NET-area there are some expectations to dll-names when
automatically resolving assemblies - so no easy choice.

Just changing final-name in the pom-model if it isn't yet custom-changed could
be another option.

Support reactor reference to other modules at compile phase

Key: NPANDAY-623
URL: https://issues.apache.org/jira/browse/NPANDAY-623
Project: NPanday
Issue Type: Bug
Components: Maven Plugins
Affects Versions: 1.4-incubating, 1.5.0-incubating
Environment: Maven 2.2.1
Reporter: Greg Domjan
Attachments: example.zip

When building multiple artifacts with dependencies in the reactor it appears
to be currently required that you build to the install phase.
This can actually be a bug - see
http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html
Even if not a bug, this goes against some common practices such as used in
the release-plugin which attempts to test the build by running all projects
to compile stage only.
In comparison the maven reactor allows for dependency resolution in Java JAR
dependencies as soon as the compile phase is run. It does this by pointing
the artifact file to the local class folder.
NPanday could take similar action and point the file to the local target file
as soon as compile.

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

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

2014-06-12 Thread Lars Corneliussen (JIRA)


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

Lars Corneliussen commented on NPANDAY-624:
---

Have you yet looked at the code? It's no magic :-)

Also, could it be the same problem as the other issue - that the artifact isn't 
resolved...?

 NPE in ilMerge
 --

 Key: NPANDAY-624
 URL: https://issues.apache.org/jira/browse/NPANDAY-624
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.5.0-incubating
 Environment: Windows, VS2005, VS2012, Platform SDK 6,7,7.1,8.0,8.1
 Using npanday.settings to select mininmal framework version 3.0
 Maven 2.2.1
Reporter: Greg Domjan

 ilMerge appears to be looking for the compiler details to select the 
 appropriate ilMerge app.  The compiler list is returning multiple options, 
 but then ilMerge gets NPE on following call to 
   ```File assemblyPath = compilerExecutable.getAssemblyPath();```
 [DEBUG] NPANDAY-102-003: Apply 
 rule:npanday.vendor.impl.VendorInfoTransitionRuleFactory$8@38c9aa93
 [DEBUG] NPANDAY-103-017: Entering State = FFF
 [DEBUG] NPANDAY-103-052: Set defaults: 3.0
 [DEBUG] NPANDAY-102-004: Vendor info requirement after 
 rule:[VendorRequirement for vendor MICROSOFT version 3.0, Framework Version = 
 3.0]
 [DEBUG] NPANDAY-065-008: Found vendor [Configured Vendor Info for MICROSOFT 
 3.0, Framework Version = 3.0] for requirement [VendorRequirement for vendor 
 MICROSOFT version 3.0, Framework Version = 3.0]
 [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability 
 [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 
 3.0], operatingSystem='Windows', language='C_SHARP']
 [DEBUG] NPANDAY-065-009: Failed to match policy: 
 ExecutableMatchPolicy[profile: 'FULL']
 [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability 
 [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 
 3.0], operatingSystem='Windows', language='C_SHARP']
 [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability 
 [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 
 3.0], operatingSystem='Windows', language='C_SHARP']
 [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability 
 [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 
 3.0], operatingSystem='Windows', language='C_SHARP']
 [DEBUG] NPANDAY-065-001: Found matching capability: CompilerCapability 
 [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 
 3.0], operatingSystem='Windows', language='C_SHARP']
 [DEBUG] NPANDAY-065-009: Failed to match policy: 
 ExecutableMatchPolicy[language: 'C_SHARP']
 [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability 
 [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 
 3.0], operatingSystem='Windows', language='VB']
 [DEBUG] NPANDAY-065-009: Failed to match policy: 
 ExecutableMatchPolicy[language: 'C_SHARP']
 [DEBUG] NPANDAY-065-005: Capability doesn't match: CompilerCapability 
 [vendorInfo=[Configured Vendor Info for MICROSOFT 3.0, Framework Version = 
 3.0], operatingSystem='Windows', language='ASP']
 [WARNING] NPANDAY-065-010: Found multiple matching capabilities; will choose 
 the first one: [CompilerCapability [vendorInfo=[Configured Vendor Info for 
 MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', 
 language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info 
 for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', 
 language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info 
 for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', 
 language='C_SHARP'], CompilerCapability [vendorInfo=[Configured Vendor Info 
 for MICROSOFT 3.0, Framework Version = 3.0], operatingSystem='Windows', 
 language='C_SHARP']]
 [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil
 [DEBUG] NPANDAY-061-007: Artifact Type:false
 [DEBUG] NPANDAY-061-006: Artifact Type:dotnet-library
 [DEBUG] NPANDAY-061-007: Artifact Type:false
 [DEBUG] NPANDAY-061-006: Artifact Type:dotnet-library
 [DEBUG] NPANDAY-061-007: Artifact Type:false
 [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil
 [DEBUG] NPANDAY-061-007: Artifact Type:false
 [DEBUG] NPANDAY-061-006: Artifact Type:gac_msil
 [DEBUG] NPANDAY-061-007: Artifact Type:false
 [WARNING] NPANDAY-231: previously netDependencyId was used to resolve some 
 private bin path...
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] null
 [INFO] 
 
 [DEBUG] Trace
 java.lang.NullPointerException

[jira] [Commented] (NPANDAY-623) Support reactor reference to other modules at compile phase

2014-06-02 Thread Lars Corneliussen (JIRA)


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

Lars Corneliussen commented on NPANDAY-623:
---

hmpf. could you provide a zip-file? don*t have too much time to look at it this 
week, though

 Support reactor reference to other modules at compile phase 
 

 Key: NPANDAY-623
 URL: https://issues.apache.org/jira/browse/NPANDAY-623
 Project: NPanday
  Issue Type: Bug
  Components: Maven Plugins
Affects Versions: 1.4-incubating, 1.5.0-incubating
 Environment: Maven 2.2.1
Reporter: Greg Domjan

 When building multiple artifacts with dependencies in the reactor it appears 
 to be currently required that you build to the install phase.  
 This can actually be a bug - see 
 http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html
 Even if not a bug, this goes against some common practices such as used in 
 the release-plugin which attempts to test the build by running all projects 
 to compile stage only.
 In comparison the maven reactor allows for dependency resolution in Java JAR 
 dependencies as soon as the compile phase is run. It does this by pointing 
 the artifact file to the local class folder.
 NPanday could take similar action and point the file to the local target file 
 as soon as compile.



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

[jira] [Commented] (NPANDAY-542) Support for multiple source dirs

2014-05-15 Thread Lars Corneliussen (JIRA)


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

Lars Corneliussen commented on NPANDAY-542:
---

Hi,

actually this should be available in 1.5.0-SNAPSHOT, yes :-)

_
Lars

 Support for multiple source dirs
 

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


 If another maven plugin generates sources for other plugins to process this 
 is not picked up by NPanday.
 Typically we have a plugin adding to the sources with the following code:
   /**
  * The source directories containing the sources to be compiled.
  * 
  * @parameter expression=${project.compileSourceRoots}
  * @required
  * @readonly
  */
 private ListString compileSourceRoots;
 ...
 compileSourceRoots.add(getTargetDir().getAbsolutePath());



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

[jira] [Commented] (NPANDAY-617) compile:generate-assembly-info Allow for filtering/customization of properties

2014-05-14 Thread Lars Corneliussen (JIRA)


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

Lars Corneliussen commented on NPANDAY-617:
---

Agreed. .NETs Nuget also starts aligning to semver (Semantic Versioning) with 
only 3 numbers. It is still possible to append a fourth with a dash, and if it 
needs to be a number, prepend it such that it is sortable as string.

Since I use Maven to resolve dependencies and package what I deploy, I don't 
care about .NETs version resolving. Also though about generating assembly 
binding xml for cases where the version rules not match.

Then using the first 3 numbers from the maven version + .0 (for 
AssemblyVersion) is a good fit. AssemblyInformationalVersion can be an 
arbitrary string - i just ignore the warning. (could put CS1607) in the default 
ignores, if so.

 compile:generate-assembly-info Allow for filtering/customization of properties
 --

 Key: NPANDAY-617
 URL: https://issues.apache.org/jira/browse/NPANDAY-617
 Project: NPanday
  Issue Type: Improvement
  Components: Maven Plugins
Affects Versions: 1.4-incubating
Reporter: Greg Domjan
  Labels: configuration, documentation, filters, versioning

 The generation of assembly info from the maven pom is desirable, especially 
 in reguard to filling in version and copyright year, so having a static 
 AssemblyInfo.cs to customize the value doesn't seem to be a good work around 
 (unless I've missed an alternate way to apply filtering?)
 It is unclear where these might be sourced from
 [assembly: AssemblyCopyright()]
 [assembly: AssemblyTrademark()]
 [assembly: AssemblyCulture()]
 The [assembly: AssemblyProduct()]  appears to be a combination of 
 Company-Title and it would be good to be able to customize it.
 In regard to version, it appears maven2 version format isn't supported?
 If an alternate source for version could be provided so that the version 
 formatted to .net/npanday standard could be used it would be helpful.
 For example Using the maven 2 standard format version of 
 major.minor.revision-build  reports issues due to generation requiring the 
 'string' version of major.minor.revision.build which can cause issues with 
 version comparison.
 ie. version8.1.0-0-SNAPSHOT/version
 generates
 [assembly: AssemblyVersion(8.1.0)]
 [assembly: AssemblyInformationalVersion(8.1.0-0-SNAPSHOT)]
 warning CS1607: Assembly generation -- The version '8.1.0-0-SNAPSHOT' 
 specified for the 'product version' is not in the normal 'major.minor.
 build.revision' format
 Best ref I found is 
 http://mojo.codehaus.org/versions-maven-plugin/version-rules.html
 For example, Maven arranges the version list in the following manner:
 1.0.1.0
 1.0.10.1
 1.0.10.2
 1.0.9.3
 Version 1.0.9.3 should come before 1.0.10.1 and 1.0.10.2, but the unexpected 
 fourth field (.3) forced Maven to evaluate the version as a string.



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

AW: NPanday report due Apr 2

2014-04-01 Thread Lars Corneliussen // Zen

+1


-Ursprüngliche Nachricht-
Von: Brett Porter [mailto:br...@porterclan.net] Im Auftrag von Brett Porter
Gesendet: Dienstag, 1. April 2014 07:30
An: npanday-dev@incubator.apache.org
Betreff: NPanday report due Apr 2

Hi,

The report has been missed for a couple of months, and is due on April 2.
Does anyone have any contributions they'd like to make to it?

Here is a draft - I'd appreciate a +1 or comments from those following
along.

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

NPanday has been incubating since 2010-08-13.

In previous reports, we indicated that there was a regression that blocked
releasing the next version. This has now been resolved, and the only thing
that stands in the way is sufficient cycles to push it out. There have been
a small number of users (not yet committers) who've stepped forward to help
test when that happens, which might help build some much needed momentum.
However, as before, it's still a concern whether sufficient release votes
could be found as many of the existing PPMC are inactive. The last release
was made on 16 May 2011.

The steps that have been identified are:
- apply patches that have been contributed recently
- convert the website to svnpubsub so updated documentation can be published
- perform the release steps

The NPanday automated builds have been impacted by changes to the Windows
build infrastructure again, but this is probably something that needs to be
worked around on our end.

---

Regards,
Brett

--
Brett Porter   @brettporter
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter

AW: svn commit: r1573504 - in /incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src: main/csharp/Converter/Algorithms/ test/resource/MvcApplication1/MvcApplication1/ test/resou

2014-04-01 Thread Lars Corneliussen // Zen

Hi Brett,

sorry for still not actively beeing watching the list :-(

Still an issue? Would need to dive into it to give you feedback.
If you really want an answer ping me on skype :-) Or send a copy to my
direct email address - - i'll then answer to the dev group :-)

Lars

-Ursprüngliche Nachricht-
Von: Brett Porter [mailto:br...@porterclan.net] Im Auftrag von Brett Porter
Gesendet: Montag, 3. März 2014 11:03
An: npanday-dev@incubator.apache.org
Cc: Lars Corneliussen
Betreff: Re: svn commit: r1573504 - in
/incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/sr
c: main/csharp/Converter/Algorithms/
test/resource/MvcApplication1/MvcApplication1/
test/resource/NPANDAY_480_AzureSupportOneWebRole/HelloWorld_WebRo

Hi Lars,

I'm interested in your feedback here. I've made this change to be more
inline with the previous behaviour which used contentPath. I picked up on
this because it turns out the Resolve Web Roles mojo in the Azure plugin
assumes a contentPath destination, and fails if you use iisApp.

Is this change correct, or should it in fact be iisApp now, and the resolve
mojo adjusted?

(You can verify the behaviour through the Azure integration tests).

Cheers,
Brett

On 3 Mar 2014, at 8:55 pm, br...@apache.org wrote:

 Author: brett
 Date: Mon Mar  3 09:55:30 2014
 New Revision: 1573504
 
 URL: http://svn.apache.org/r1573504
 Log:
 [NPANDAY-488] Use contentPath by default
 
 This was the previous behaviour:
 http://svn.apache.org/viewvc/incubator/npanday/trunk/plugins/msdeploy-
 maven-plugin/src/main/java/npanday/plugin/msdeploy/create/CreateConten
 tPackageMojo.java?r1=1333788r2=1332286pathrev=1333788
 
 Also, there is a problem using iisApp with resolve web roles, since it 
 expects the contentPath destination:
 http://svn.apache.org/viewvc/incubator/npanday/trunk/plugins/msdeploy-
 maven-plugin/src/main/java/npanday/plugin/msdeploy/create/CreateConten
 tPackageMojo.java?r1=1333788r2=1332286pathrev=1333788
 
 Modified:

incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src
/main/csharp/Converter/Algorithms/ASPNetPomConverter.cs

incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src
/test/resource/MvcApplication1/MvcApplication1/pom.test

incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src
/test/resource/NPANDAY_480_AzureSupportOneWebRole/HelloWorld_WebRole/pom.tes
t

incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src
/test/resource/NPANDAY_480_CloudServiceWithMultipleRoles/HelloWorld_WebRole/
pom.test

incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src
/test/resource/NPANDAY_488/NPANDAY_488_MSDeployPackageSimpleWebApp/pom.test

incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src
/test/resource/SilverlightApplication1/SilverlightApplication1.Web/pom.test

incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src
/test/resource/SilverlightApplication5/SilverlightApplication5.Web/pom.test

 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engi
 ne/src/test/resource/WebAppWithCultureRes/WebAppWithCultureRes/pom.tes
 t
 
 Modified: 
 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engi
 ne/src/main/csharp/Converter/Algorithms/ASPNetPomConverter.cs
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/trunk/dotnet/assemblies
 /NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/A
 SPNetPomConverter.cs?rev=1573504r1=1573503r2=1573504view=diff
 ==
 
 --- 
 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engi
 ne/src/main/csharp/Converter/Algorithms/ASPNetPomConverter.cs 
 (original)
 +++ incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/
 +++ Engine/src/main/csharp/Converter/Algorithms/ASPNetPomConverter.cs 
 +++ Mon Mar  3 09:55:30 2014
 @@ -54,7 +54,7 @@ namespace NPanday.ProjectImporter.Conver
 }
 
 Plugin msdeployPlugin =
AddPlugin(org.apache.npanday.plugins, msdeploy-maven-plugin, null,
false);
 -AddPluginExecution(msdeployPlugin, create-msdeploy-package,
new string[] { create-iisApp-package }, null);
 +AddPluginExecution(msdeployPlugin, 
 + create-msdeploy-package, new string[] { create-content-package 
 + }, null);
 
 if (projectDigest.SilverlightApplicationList != null)
 {
 
 Modified: 
 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engi
 ne/src/test/resource/MvcApplication1/MvcApplication1/pom.test
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/trunk/dotnet/assemblies
 /NPanday.ProjectImporter/Engine/src/test/resource/MvcApplication1/MvcA
 pplication1/pom.test?rev=1573504r1=1573503r2=1573504view=diff
 ==
 
 --- 
 incubator/npanday/trunk/dotnet/assemblies

Re: Building NPanday

2013-12-04 Thread Lars Corneliussen

In integration tests we do that already. I think we have a couple of 
integration tests that test other local repos… Maybe it is easy to just set 
the local-repository for all of them.

Brett should have a better overview…

I'm coming from the other side - learned Java just a couple of years ago.

Am 04.12.2013 um 09:39 schrieb christofer.d...@c-ware.de 
christofer.d...@c-ware.de:

 Hi Lars,
 
 I can immagine that not all design decisions we did in Flexmojos are 
 applicable and valid on other platforms. It was just that we noticed a lot 
 less fuss with this Approach. I guess you are right. Windows stuff was 
 allways a lot more complex than Java stuff ;-) But still we should think 
 about how it would be possible to make it easier to start working with 
 NPanday. Even I as a Maven and IT professional had to do quite some Research 
 getting things up and running. From my experiance with Flexmojos the Level of 
 willingness to do so is relatively small with the majority of potential users.
 
 I could help modify the testsuite to run with the maven-invoker. For this I 
 could simply duplicate the Setup used in Flexmojos. This shouldn't be that 
 hard. After all every test is simply executing a maven build and checking the 
 Output. So things should be quite similar.
 
 Chris
 
 
 Von: Lars Corneliussen [m...@lcorneliussen.de]
 Gesendet: Dienstag, 3. Dezember 2013 20:07
 An: npanday-dev@incubator.apache.org
 Betreff: Re: Building NPanday
 
 inline…
 
 Am 03.12.2013 um 12:22 schrieb christofer.d...@c-ware.de 
 christofer.d...@c-ware.de:
 
 Well in Flex the SDK also Comes with quite a lot of binaries. Even if most 
 of them are Jar files, there still are quite a lot of executeable binaries 
 (Flashplayer, Air-Runtime, Air Debugger) which are exe-files. I guess 
 however that DLLs could be a Problem, if the names Change in a mavenized 
 form. So if MyCool.dll would become mycool-1.3.4.dll I guess this would mess 
 up things, but I have to admit that I'm still pretty new to the .Net coding. 
 I've got tons of Java experiance and am currently confronted of having to 
 create .Net Clients for my Java Server applications ... and therefore 
 wanting to do this in one maven build (Just to give you a bit more on my 
 Background)
 Ok. In earlier versions of NPanday we had a separate repository that kept the 
 files with correct names in version folders. But that introduced a lot of 
 other problems.
 
 But I'd be fine with creating temporary execution-directories in the reactors 
 parent target-folder. Still I'm not sure, if we should mavenize all of .NETs 
 SDKs. I'm pretty sure they require changes to the registry ++
 
 Also the current vendor detection is more sophisticated than just resolving a 
 maven artifact (version, vendor, frameworkVersion, ++).
 
 I think the npanday-settings.xml-approach is ok, but in order to avoid the 
 bootstrapping problem, the vendor detection could run live in JAVA code.
 
 Still I see the need to resolve executables from maven (which again could be 
 imported from nuget). That is basically what the .NET plugins do. Just that 
 they aren't normal executables, but they get passed the mojo configuration...
 
 
 But what do you think about my Suggestion to have the Testsuite run in a 
 separate local test maven repo? I'm still cleaning up my main local maven 
 repo after my last execution of NPandays Testsuite.
 Totally agree. Not sure, what needs to be done to have that running, though...
 
 
 Chris
 
 
 Von: Lars Corneliussen [m...@lcorneliussen.de]
 Gesendet: Montag, 2. Dezember 2013 22:29
 An: npanday-dev@incubator.apache.org
 Betreff: Re: Building NPanday
 
 got you!
 
 but the npanday-settings.xml is more about the SDK binaries than about maven 
 artifacts. i don't think it is easy to copy them all around - but who knows.…
 
 For nunit, ++ it shouldn't be a problem at all!
 
 but I agree, that we should be able to have maven-artifacts (zip files, 
 e.g.) as prereq for plugins. We could for example use the 
 application-packaging (uses maven archiver).
 
 Am 26.11.2013 um 08:48 schrieb christofer.d...@c-ware.de:
 
 Well currently there are different Library packages in different versions 
 (.Net 2.0, .Net 3.5, .Net X.X. NUnit, Lots more ...). All of These have 
 their own internal Directory structure and contain sets of libraries 
 (DLLs). As far as I undertstood NPanday it depends on These Libs being 
 installed on the host running a NPanday build and NPanday depends on These 
 libraries as the dlls are not copied to the maven repository, but instead 
 the npanday-settings.xml tells it in what Directory things are located.
 
 My Suggestion was to mavenize the libraries (Making Maven artifacts out 
 of them and copying them to the local repo instead of maintaining the 
 npanday-settings.xml). This way you could deploy the artifacts to a Company 
 Maven repo and another user wanting to do a build

Re: Building NPanday

2013-11-25 Thread Lars Corneliussen

do still not really understand…
what libs are you talking about? nunit, ++? adana-repo? ...

Am 22.11.2013 um 11:42 schrieb christofer.d...@c-ware.de:

 Well I guess in the case of NPanday the local maven repostitory contains the 
 NPanday Plugin(s) in the maven local repository and a npanday-settings.xml 
 that is located somewhere. The Libs and Binaries used for compiling are 
 located in the place where they were installed.
 
 Assume an new colleague joins a Team already working on a Project. He has to 
 install all sorts of libs first and hopefully get them in the right Version. 
 In all other cases the build will Fail.
 
 I was suggesting not to use a npanday-settings.xml at all, but to create a 
 mavenizer that copies all the libs and binaries needed into a Maven form 
 located in the maven local repository. This way These files can also be 
 shared using a companies Maven repository and used in a Project by adding a 
 simple Maven dependency.
 
 Assumings this Approach, as soon as the new colleague joins the Team, the 
 first build, would download all needed libs and binaries from the companies 
 Maven repository and he could start working immediately.
 
 When I first started to get the NPanday Unit Test Suite to execute, I needed 
 quite some time to find out which Libraries were missing, After installing 
 some of them I noticed that the new Versions were incompatable with the ones 
 the Unit Test required and it was very hard to get Access to the old 
 Versions. This was all making it harder for me to get started and I think it 
 will also prevent others from doing the same.
 
 Chris
 
 
 Von: Lars Corneliussen [m...@lcorneliussen.de]
 Gesendet: Freitag, 22. November 2013 10:24
 An: npanday-dev@incubator.apache.org
 Betreff: Re: Building NPanday
 
 so, instead of running the mavenizer (dotnet-plugins/settings-generator) 
 through maven it would just run as a standalone program and update the 
 npanday-settings.xml?
 
 Am 21.11.2013 um 13:53 schrieb christofer.d...@c-ware.de 
 christofer.d...@c-ware.de:
 
 Hi Lars,
 
 And what about the idea of creating a .Net mavenizer that creates maven 
 artifacts for all needed components and libraries. Then you could rely on 
 this maven structure and new .Net Versions or lib Versions would simply be a 
 Thing of updating the Mavenizer.
 
 This is the path we took for Flexmojos which relys on a Flex SDK, Air SDK 
 and Flashplayer libs. Ryling on libs in a certain structure on a System was 
 a far to fragile construct and keept on breaking things whenever a new SDK 
 changed the structure a Little.
 
 Chris
 
 
 
 
 Von: Lars Corneliussen [m...@lcorneliussen.de]
 Gesendet: Donnerstag, 21. November 2013 11:07
 An: npanday-dev@incubator.apache.org
 Betreff: Re: Building NPanday
 
 Hi Christopher,
 
 for Azure we read the SDK paths from the registry (configured in embedded 
 xml-files).
 Some of the paths detection still runs in dotnet-plugins; I think it should 
 be moved to Java code in order to have it accessible directly (live) from 
 all plugins. (Now we generate a file npanday-settings.xml that contains the 
 information about installed .NET SDKs) 
 (https://issues.apache.org/jira/browse/NPANDAY-505)
 
 But it is not easy to get everything to run in all environments. The 
 nuget-importer also needs to have nuget on the PATH - which I don't like at 
 all! But there is no default place to get it from… Same with NUnit. It would 
 be great if we could bootstrap things through nuget… Maybe embedding the 
 nuget-commandline bottstrapper…
 
 _
 Lars
 
 Am 13.11.2013 um 20:42 schrieb christofer.d...@c-ware.de 
 christofer.d...@c-ware.de:
 
 Hi,
 
 Ok so I had another look at the bootstrap thing and it seems to work ... 
 think I should start looking at the stuff in the root directory and not 
 trusting the documentation on the website ... this sort of never works ;-)
 So I don't want to change a running system ;-)
 
 Now I'm trying to run the integration tests. Here I was having a little 
 trouble:
 - I installed Azure SDK 2.2 (Sort of couldn't install 1.7) and linked that 
 directory to C:\Programms\Windows Azure SDK\v1.6 and C:\Programms\Microsoft 
 SDKs\Windows Azure\.NET SDK\2012-06 and it seemed to have worked a little 
 :-)
 - I have Visual Studio 2013 installed and some tests are skipped because of 
 me not having 2010 installed.
 - Still there are 18 Test failing (It seems some tests are currently not 
 running ... which ones are known not to run?)
 
 One other thing I found a little annoying in the integration-tests suite, 
 was that it pollutes my local maven repository. I am the lead developer of 
 Flexmojos and here we use the maven-invoker-plugin to populate a test local 
 repo located in the test-harness' target directory and invoke child maven 
 builds, resulting in the normal local maven repo staying untouched. After a 
 mvn clean all of this is cleared keeping

Re: Incubator

Hi guys,

just my two cents on the project.

We (Faktum Software GmbH) are still interested in bringing NPanday forward. We 
use it actively on a big project - but the project consumes all my time. So I 
have hardly more time to do more then just make it run.

Still, we are actively making changes (PDB support, Nuget-importer, …) - but we 
haven't had the energy to push the release of 1.5 forward.

I'm also happy to help others getting involved. Just skype me on lcorneliussen
(I should maybe start to actively watch this list … :-))

Currently

_
Lars

Am 16.11.2013 um 20:38 schrieb Dennis Lundberg dennisl.apa...@gmail.com:

 Hi Raphael
 
 On Sun, Nov 10, 2013 at 9:16 PM, Raphael Bircher r.birc...@gmx.ch wrote:
 Hi David
 
 Am 10.11.13 20:41, schrieb David Akehurst:
 
 Hi,
 
 I know that Brett Porter used to be very active here (perhaps he is on
 holiday),
 he helped a college of mine get a local version of the plugin built, and
 has answered some of my questions before.
 
 Yea, I saw Brett Porter and know him from the infra list. Nice for him to
 have Holiday ;-) Anyway, I think, there are more committers here who are
 still sleeping. As you know, it needs time to wake up after a long sleep ;-)
 
 Anyway, I asked now the Incubator for new Mentors for this project. since
 the old Mentor Dennis Lundberg is inactive for over a year. And one Mentor
 is not enough anyway
 
 That's not entirely true, I signed the report back in February 2013,
 but yes I have been largely occupied elsewhere. In September I
 contacted Brett off-list to give a heads up that I planned to resign
 as a mentor. I'll take that discussion over at incubator when I can
 find the time.
 
 I too would be happy to make some contributions, but need some guidance,
 and can only build on linux at present.
 
 Unfortunaly I can't tell you much here. I comming from a compleet different
 direction (OpenOffice) and have no experiance with this kind of code. I can
 help with community building, and probabily a bit testing. But to be honest.
 I'm not planing to contribute for this project. Just help to restart.
 
 Btw. maybe a mail to the users would be good.
 
 Greetings from Switzerland
 Raphael
 
 
 
 
 -- 
 Dennis Lundberg

Re: Building NPanday

Hi Christopher,

for Azure we read the SDK paths from the registry (configured in embedded 
xml-files).
Some of the paths detection still runs in dotnet-plugins; I think it should be 
moved to Java code in order to have it accessible directly (live) from all 
plugins. (Now we generate a file npanday-settings.xml that contains the 
information about installed .NET SDKs) 
(https://issues.apache.org/jira/browse/NPANDAY-505)

But it is not easy to get everything to run in all environments. The 
nuget-importer also needs to have nuget on the PATH - which I don't like at 
all! But there is no default place to get it from… Same with NUnit. It would be 
great if we could bootstrap things through nuget… Maybe embedding the 
nuget-commandline bottstrapper…

_
Lars

Am 13.11.2013 um 20:42 schrieb christofer.d...@c-ware.de 
christofer.d...@c-ware.de:

 Hi,
 
 Ok so I had another look at the bootstrap thing and it seems to work ... 
 think I should start looking at the stuff in the root directory and not 
 trusting the documentation on the website ... this sort of never works ;-)
 So I don't want to change a running system ;-)
 
 Now I'm trying to run the integration tests. Here I was having a little 
 trouble:
 - I installed Azure SDK 2.2 (Sort of couldn't install 1.7) and linked that 
 directory to C:\Programms\Windows Azure SDK\v1.6 and C:\Programms\Microsoft 
 SDKs\Windows Azure\.NET SDK\2012-06 and it seemed to have worked a little :-)
 - I have Visual Studio 2013 installed and some tests are skipped because of 
 me not having 2010 installed.
 - Still there are 18 Test failing (It seems some tests are currently not 
 running ... which ones are known not to run?)
 
 One other thing I found a little annoying in the integration-tests suite, was 
 that it pollutes my local maven repository. I am the lead developer of 
 Flexmojos and here we use the maven-invoker-plugin to populate a test local 
 repo located in the test-harness' target directory and invoke child maven 
 builds, resulting in the normal local maven repo staying untouched. After a 
 mvn clean all of this is cleared keeping the normal local repo nice and 
 clean.
 
 Yet another improvement proposal would be the way the resources in the MS 
 SDKs are handled. I have seen a lot of systemPath stuff in the test poms. In 
 Flex we too have different versions of SDKs that are installed to different 
 places, which need to be accessed by the maven plugins. Instead of somehow 
 accessing the files in their native locations, I created a mavenizer 
 application, which creates Maven artifacts from the files in the SDKs and 
 allows deploying these locally and in remote repositories. What do you think 
 about creating a MS SDK mavenizer, which makes everything maveny and allows 
 reducing the complexity of the plugins greatly?
 
 Chris
 
 
 -Ursprüngliche Nachricht-
 Von: christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de] 
 Gesendet: Mittwoch, 13. November 2013 16:15
 An: npanday-dev@incubator.apache.org
 Betreff: AW: Building NPanday
 
 Sure,
 
 I'll create an issue and attach a patch as soon as I'm home.
 
 Chris
 
 
 Von: Brett Porter [br...@porterclan.net] im Auftrag von Brett Porter 
 [br...@apache.org]
 Gesendet: Mittwoch, 13. November 2013 13:25
 An: npanday-dev@incubator.apache.org
 Betreff: Re: Building NPanday
 
 On 13 Nov 2013, at 6:44 pm, christofer.d...@c-ware.de wrote:
 
 Hi Brett,
 
 Well in my checkout I added two profiles default and minimal each 
 containing only a modules section. Minimal only referencing the 
 compiler-maven-plugin and the default containing the normal 
 modules-section. I then disabled the Profile which automatically disables 
 itself as soon as the bootstrap property is set.
 
 At least this way is buildable using
 
 mvn clean install -Pminimal
 mvn clean install
 
 without having to have any Prior Version available in any repo. I would much 
 favour this Approach and it would be much more like other maven plugin 
 Projects are Setup.
 
 Yep, sounds good to me - would you like to contribute that as a patch in JIRA?
 
 - Brett
 
 --
 Brett Porter   @brettporter
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter

Re: PPMC/Committer who is still active

I am a committer. Now walking through the list and find old mails. :-)

Am 13.11.2013 um 17:13 schrieb Raphael Bircher r.birc...@gmx.ch:

 Hi at all
 
 I have a important question about the PPMC/Committers. Who is in the PPMC and 
 who is committer. And how many of them are still active. We have to create a 
 PPMC wich is able to manage the project. For this we need minimum three 
 people.
 
 On the committer list I see 10 People with access to the SVN. Are they all 
 sucked in a black hole or they waiting for better time ;-)
 
 Greetings Raphael

Re: Status of the project?

I like coding. But i hate mailing lists. :-)

Am 13.11.2013 um 08:00 schrieb Brett Porter br...@apache.org:

 Hi Raphael,
 
 Thanks for checking in. You were right in another message, I was on holidays.
 
 There are people here willing to develop on the project, but time comes and 
 goes for each. When we first brought the project into Apache, there was 
 interest from several others, including some Apache committers, but it waned 
 - and though we get occasional patches from new people, we've had trouble 
 getting them on as committers. I'm glad to see the interest sparked by your 
 message, which I'll respond to separately.
 
 In terms of mentors, we've gradually lost them over time, and I was 
 unsuccessful in recruiting new ones from general@. We very much need an 
 active mentor to keep us honest :) I hope you'll volunteer...
 
 For the overall status:
 
 We need to ship 1.5.0. Unfortunately, while the Windows build slave was 
 broken for a while some changes were made that broke compatibility. They are 
 good changes, but the regressions need to be fixed to ship a release.
 
 Aside from that, the project is reasonably stable. There are additions here 
 and there for new releases that come out, and some potential architectural 
 changes to take advantage of recent developments in .NET and Maven and cruft 
 to clear out, but otherwise it pretty much does what you need it to do. That 
 can make it hard to attract new contributors.
 
 One thing that could be improved is Mono support. While some things exist, 
 the existing developers don't use it - so that's an area for new contributors 
 to get involved.
 
 Another challenge I've found is that contributors tend to interact purely 
 over JIRA or even reach out over Skype. It has been difficult to get more 
 happening on this list as it should.
 
 I'll put this in as a report for this month if it is not too late. Thanks 
 again for following up.
 
 Cheers,
 Brett
 
 On 8 Nov 2013, at 2:03 pm, Raphael Bircher r.birc...@gmx.ch wrote:
 
 Hi all
 
 My name is Raphael Bircher. I'm from the Incubator and doing shepherding for 
 this project this month. In my review i saw nearly no activity in the last 
 three months. There is also only one mentor who is inactive since one year, 
 (according dev ml).
 
 The big question is: Is here still some willing and energy to develop this 
 project, or not.
 
 You have not filled the bord report now, pleas do it. I will do my shepherd 
 report anyway, and bring the topic to the incubator list.
 
 Greetings
 Raphael
 
 --
 Brett Porter   @brettporter
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter

Re: Status of the project?

good idea to make send jira-comments to dev!
thats where I live - if so.

Am 13.11.2013 um 13:28 schrieb Brett Porter br...@apache.org:

 
 On 13 Nov 2013, at 6:49 pm, christofer.d...@c-ware.de wrote:
 
 Hi Brett,
 
 Well I would strongly suggest to bring those discussions back here to the 
 list, cause this is the usual way Apache Projects communicate ... in the 
 Flex Project they always say: If it's not on the list, it didn't happen.. 
 This too would give other People more an Impression that this Project is not 
 dead.
 
 Yes, certainly agree.
 
 Additionally you could Setup Jira to mirror stuff Happening in Jira to this 
 list (We had this in the Flex Project, but switched that off as soon as 
 Speed increased).
 
 It currently goes to -commits - but I think in this case -dev makes more 
 sense. I'll look into changing that.
 
 - Brett
 
 --
 Brett Porter   @brettporter
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter

Re: trunk

2013-07-02 Thread Lars Corneliussen

developing npanday on linux/mac doesnt really work. 

try on windows...

_
Mobil versendet. 

Am 01.07.2013 um 21:00 schrieb David Akehurst d...@akehurst.net:

 Hi,
 
 I have just checked out the latest npanday trunk from
 
 https://svn.apache.org/repos/asf/incubator/npanday/trunk
 
 
 The build fails at NPanday :: Executable
 
 [INFO] NPanday :: Model :: Settings .. SUCCESS [1.498s]
 [INFO] NPanday :: Vendor . SUCCESS [1.463s]
 [INFO] NPanday :: Executable . FAILURE [2.460s]
 [INFO] NPanday :: Model :: Configuration Appenders ... SKIPPED
 
 
 there seems to be some test failures
 
 Failed tests:
 testCommandArgWithSpaces[0](npanday.executable.execution.CommandExecutorTest):
 (cmd.standardOut == expected). Values: expected = a b
 
 testCommandArgWithSpaces[1](npanday.executable.execution.CommandExecutorTest):
 (cmd.standardOut == expected). Values: expected = a b
 
 Tests in error:
 
 testCommandArgWithEmbeddedSingleQuotes_middle[0](npanday.executable.execution.CommandExecutorTest):
 NPANDAY-040-001: Could not execute: Command = /bin/sh -c echo 'a \' b',
 Result = 2
 
 testCommandArgWithEmbeddedSingleQuotes_middle[1](npanday.executable.execution.CommandExecutorTest):
 NPANDAY-040-001: Could not execute: Command = /bin/sh -c echo 'a \' b',
 Result = 2
 
 
 I am building on a linux machine, not windows, would this be why, or is
 there a problem with the current trunk?
 
 cheers

Re: [jira] [Commented] (NPANDAY-587) Support for .NET Framework 4.5

2013-05-27 Thread Lars Corneliussen

4.5 is an in-place-upgrade for 4.0.
Will depend on if the systems has it installed or not.

But maybe, if stated 4.5 we can somehow validate, that 4.5 is really installed.

 
[ 
 https://issues.apache.org/jira/browse/NPANDAY-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667497#comment-13667497
  ] 
 
 Brett Porter commented on NPANDAY-587:
 --
 
 New vendor information needs to be aded
 
 Support for .NET Framework 4.5
 --
 
Key: NPANDAY-587
URL: https://issues.apache.org/jira/browse/NPANDAY-587
Project: NPanday
 Issue Type: Improvement
 Components: Maven Plugins
   Reporter: Brett Porter
   Assignee: Brett Porter
 
 Along with NPANDAY-586, check that projects using the new version of the 
 framework build successfully.
 
 --
 This message is automatically generated by JIRA.
 If you think it was sent incorrectly, please contact your JIRA administrators
 For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: building from SVN

2013-04-17 Thread Lars Corneliussen

I have tried to do npanday development on mono a couple of times, but given up 
every time.

in this case the implementation does the quoting escaping wrong - but i think 
if you fix that, the next problem will arise:
http://stackoverflow.com/questions/7254509/how-to-escape-single-quotes-in-bash-grep


Am 25.03.2013 um 17:59 schrieb David Durham david.durham...@gmail.com:

 Mono JIT compiler version 2.10.8 (tarball Sat Oct  6 23:22:30 UTC 2012)
 Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors.
 www.mono-project.com
TLS:   __thread
SIGSEGV:   altstack
Notifications: epoll
Architecture:  amd64
Disabled:  none
Misc:  softdebug
LLVM:  supported, not enabled.
GC:Included Boehm (with typed GC and Parallel Mark)
 
 
 Linux 3.7.10-1-ARCH #1 SMP PREEMPT Thu Feb 28 09:50:17 CET 2013 x86_64 
 GNU/Linux
 
 Thanks,
 Dave
 
 
 On Fri, Mar 22, 2013 at 8:30 PM, Brett Porter br...@apache.org wrote:
 What operating system and version of Mono are you using? Others may have 
 more input, as most of my NPanday work is done on a Windows virtual machine.
 
 Regards,
 Brett
 
 On 22/03/2013, at 3:05 PM, David Durham david.durham...@gmail.com wrote:
 
 Hi all,
 
 I'm getting the following error when I checkout from SVN and run
 bootstrap.sh.  Anyone available to help?  Thanks.
 
 
 Running npanday.executable.execution.switches.SwitchFormatTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.581 sec
 Running npanday.executable.execution.QuotingAndEscapingBehaviourTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
 Running npanday.executable.execution.CommandExecutorTest
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 [INFO]  +--[ RUNNING: /bin/sh -c asdfasdf]
 [ERROR]  | /bin/sh: asdfasdf: command not found
 [INFO]  +--[ FAILED, result = 127, error output = true]
 Result is 127
 Executing with x_unified_simple_quoting
 [INFO]  +--[ RUNNING: /bin/sh -c mkdir
 /home/ddurham/work/npanday/npanday/components/dotnet-executable/target/test-resources/sampledirectory]
 [INFO]  +--[ DONE ]
 Executing with x_unified_simple_quoting
 [INFO]  +--[ RUNNING: /bin/sh -c mkdir
 '/home/ddurham/work/npanday/npanday/components/dotnet-executable/target/test-resources/sample
 directory']
 [INFO]  +--[ DONE ]
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 [INFO]  +--[ RUNNING: /bin/sh -c echo
 ]
 [INFO]  | 
 
 [INFO]  +--[ DONE ]
 npanday.executable.execution.UnifiedShellCommandExecutor@69a0bc8a
 Executing with x_unified_simple_quoting
 [INFO]  +--[ RUNNING: /bin/sh -c echo x]
 [INFO]  | x
 [INFO]  +--[ DONE ]
 Executing with x_unified_simple_quoting
 [INFO]  +--[ RUNNING: /bin/sh -c echo 'a b']
 [INFO]  | a b
 [INFO]  +--[ DONE ]
 Executing with x_unified_simple_quoting
 [INFO]  +--[ RUNNING: /bin/sh -c echo 'a \' b']
 [ERROR]  | /bin/sh: -c: line 0: unexpected EOF while looking for matching 
 `''
 [ERROR]  | /bin/sh: -c: line 1: syntax error: unexpected end of file
 [INFO]  +--[ FAILED, result = 1, error output = true]
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_simple_quoting
 Executing with x_unified_custom_quoting
 Executing with x_unified_custom_quoting
 Executing with x_unified_custom_quoting
 Executing with x_unified_custom_quoting
 Executing with x_unified_custom_quoting
 Executing with x_unified_custom_quoting
 Executing with x_unified_custom_quoting
 Executing with x_unified_custom_quoting
 Executing with x_unified_custom_quoting
 Executing with x_unified_custom_quoting
 Executing with x_unified_custom_quoting
 [INFO]  +--[ RUNNING: /bin/sh -c asdfasdf]
 [ERROR]  | /bin/sh: asdfasdf: command not found
 [INFO]  +--[ FAILED, result = 127, error output = true]
 Result is 127
 Executing with x_unified_custom_quoting
 [INFO]  +--[ RUNNING: /bin/sh -c mkdir

Re: NPanday 1.5 reease

2013-01-03 Thread Lars Corneliussen

Hi,

Brett and I had some trys to release NPanday 1.5 - but couldn't wrap it up yet.
We are still actively developing it - but it goes in rushes.

@Brett: from your point, what is in the way for releasing? Failing ITs?

But you can configure the release plugin to accept snapshot plugin versions.

_
Lars

Am 28.12.2012 um 13:33 schrieb Adrián Boimvaser adrianboimva...@gmail.com:

 Dear NPanday developers,
 
 Like a year ago I contributed a couple patches for NPANDAY-510 NPANDAY-533
 and I've been waiting for a the next release since then. Now that I'm about
 to release a my project I'm being forced to create a private release on my
 corporate repository or replace wix-maven-plugin with exec-maven-plugin.
 
 Are there any plans to release NPanday 1.5? Is development still active?
 
 Thanks in advance.
 
 Best regards,
 Adrián Boimvaser

Re: svn commit: r1390287 - in /incubator/npanday/npanday-its/trunk/src/test/java/npanday/its: AbstractNPandayIntegrationTestCase.java NPandayIT0036InstalledArtifactsVerificationTest.java

2012-09-26 Thread Lars Corneliussen

that is the problem, when not trusting the build :)
i made the its fail, but i didn't think it was my fault, since builds fail 
often :-)

Am 26.09.2012 um 07:49 schrieb br...@apache.org:

 Author: brett
 Date: Wed Sep 26 05:49:15 2012
 New Revision: 1390287
 
 URL: http://svn.apache.org/viewvc?rev=1390287view=rev
 Log:
 update test now that sources are not necessarily copied to
 target/build-sources
 
 Modified:

 incubator/npanday/npanday-its/trunk/src/test/java/npanday/its/AbstractNPandayIntegrationTestCase.java

 incubator/npanday/npanday-its/trunk/src/test/java/npanday/its/NPandayIT0036InstalledArtifactsVerificationTest.java
 
 Modified: 
 incubator/npanday/npanday-its/trunk/src/test/java/npanday/its/AbstractNPandayIntegrationTestCase.java
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/npanday-its/trunk/src/test/java/npanday/its/AbstractNPandayIntegrationTestCase.java?rev=1390287r1=1390286r2=1390287view=diff
 ==
 --- 
 incubator/npanday/npanday-its/trunk/src/test/java/npanday/its/AbstractNPandayIntegrationTestCase.java
  (original)
 +++ 
 incubator/npanday/npanday-its/trunk/src/test/java/npanday/its/AbstractNPandayIntegrationTestCase.java
  Wed Sep 26 05:49:15 2012
 @@ -310,24 +310,9 @@ public abstract class AbstractNPandayInt
 return target/comments.xml;
 }
 
 -protected String getBuildSourcesMain( String fileName )
 -{
 -return getBuildFile( build-sources, fileName );
 -}
 -
 protected String getBuildSourcesGenerated( String fileName )
 {
 -return getBuildSourcesMain( fileName );
 -}
 -
 -protected String getTestSourcesMain( String fileName )
 -{
 -return getBuildFile( build-test-sources, fileName );
 -}
 -
 -protected String getTestSourcesGenerated( String fileName )
 -{
 -return getTestSourcesMain( fileName );
 +return getBuildFile( build-sources, fileName );
 }
 
 protected String getBuildFile( String buildDirectory, String fileName )
 
 Modified: 
 incubator/npanday/npanday-its/trunk/src/test/java/npanday/its/NPandayIT0036InstalledArtifactsVerificationTest.java
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/npanday-its/trunk/src/test/java/npanday/its/NPandayIT0036InstalledArtifactsVerificationTest.java?rev=1390287r1=1390286r2=1390287view=diff
 ==
 --- 
 incubator/npanday/npanday-its/trunk/src/test/java/npanday/its/NPandayIT0036InstalledArtifactsVerificationTest.java
  (original)
 +++ 
 incubator/npanday/npanday-its/trunk/src/test/java/npanday/its/NPandayIT0036InstalledArtifactsVerificationTest.java
  Wed Sep 26 05:49:15 2012
 @@ -38,8 +38,9 @@ public class NPandayIT0036InstalledArtif
 File testDir = ResourceExtractor.simpleExtractResources( getClass(), 
 /NPandayIT0036InstalledArtifactsVerificationTest );
 Verifier verifier = getVerifier( testDir );
 verifier.executeGoal( install );
 -verifier.assertFilePresent(
 -new File( testDir, getAssemblyFile( NPandayIT0036, 1.0.0.0, 
 exe ) ).getAbsolutePath() );
 +String exe =
 +new File( testDir, getAssemblyFile( NPandayIT0036, 1.0.0.0, 
 exe ) ).getAbsolutePath();
 +verifier.assertFilePresent( exe );
 verifier.assertFilePresent(
 new File( testDir, getAssemblyFile( NPandayIT0036-test, 
 1.0.0.0, dll ) ).getAbsolutePath() );
 verifier.assertFilePresent( new File( testDir, getAssemblyFile( 
 test-assemblies/NPandayIT0036, 1.0.0.0,
 @@ -49,27 +50,8 @@ public class NPandayIT0036InstalledArtif
 verifier.assertFilePresent( new File( testDir, getAssemblyFile( 
 test-assemblies/NUnit.Framework, 1.0.0.0,
 dll 
 ) ).getAbsolutePath() );
 
 -verifier.assertFilePresent( new File( testDir, getBuildSourcesMain( 
 Module1.vb ) ).getAbsolutePath() );
 -verifier.assertFilePresent( new File( testDir, getBuildSourcesMain( 
 folder/Module2.vb ) ).getAbsolutePath() );
 -verifier.assertFileNotPresent(
 -new File( testDir, getBuildSourcesMain( 
 should-not-be-copied.txt ) ).getAbsolutePath() );
 -verifier.assertFileNotPresent(
 -new File( testDir, getBuildSourcesMain( 
 should-not-be-copied.xml ) ).getAbsolutePath() );
 -verifier.assertFileNotPresent(
 -new File( testDir, getBuildSourcesMain( 
 folder/should-not-be-copied-2.txt ) ).getAbsolutePath() );
 -verifier.assertFileNotPresent(
 -new File( testDir, getBuildSourcesMain( 
 folder/should-not-be-copied-2.xml ) ).getAbsolutePath() );
 -
 -verifier.assertFilePresent( new File( testDir, getTestSourcesMain( 
 Module1.vb ) ).getAbsolutePath() );
 -verifier.assertFilePresent( new File( testDir, getTestSourcesMain( 
 folder/Module2.vb ) ).getAbsolutePath() );
 -

Re: moving npanday.org to the ASF

2012-05-30 Thread Lars Corneliussen

Hi Brett,

sounds good to me!

When starting to offer dotnet-librarys extracted from nuget-packages, we have 
to think through .NET CLR versions - since one nuget-package can contain 
multiple libs for multiple clr-versions
Either we include the clr-version in the library version (e.g. 1.2.0-net40), or 
we offer multiple repositories for 2.0, 3.0, 3.5, 4.0, and so on… People can 
then define those in the right order to configure precedence.
_
Lars

Am 29.05.2012 um 12:44 schrieb Brett Porter:

 The ASF infra team are waiting on some sign of consensus before moving 
 forward, so if anyone has an opinion - it would be great to hear it now.
 
 On 24/05/2012, at 11:49 AM, Brett Porter wrote:
 
 A couple of sounds good would be handy too if you don't have any concerns 
 :)
 
 On 22/05/2012, at 5:12 PM, Brett Porter wrote:
 
 Hi,
 
 I have a long overdue note to transfer the domain name from its current 
 location to the ASF.
 
 The current uses are:
 - repo.npanday.org points to repo.maestrodev.com, which houses the 
 artifacts to build NPanday = 1.4 with Maven as a convenience (without 
 having to construct your own repository), as well as the releases prior to 
 entering the ASF. Pretty similar to how repo.maven.apache.org is handled.
 - www.npanday.org, which is redirected to 
 http://incubator.apache.org/npanday
 
 I don't propose we change either of those at the moment. Hopefully with the 
 changes Lars has done on trunk the 1.5.0 release will not require the 
 repository to build any more, and we can have a separate discussion on how 
 we might make it easier for users to obtain other artifacts (again, his 
 work on NuGet integration will help here).
 
 Any concerns with this plan?
 
 Cheers,
 Brett
 
 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter
 http://twitter.com/brettporter
 
 
 
 
 
 
 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter
 http://twitter.com/brettporter
 
 
 
 
 
 
 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter
 http://twitter.com/brettporter

Re: exe archiver for Maven assembly plugin?

2012-03-13 Thread Lars Corneliussen

Hallo Christopher,

seems like you find out things …
Can't really grasp what you are trying to do.

_
Lars
- auch deutsch :-) -

Am 02.03.2012 um 10:39 schrieb christofer.d...@c-ware.de:

 Hi,
 
 I am currently trying to setup a Maven build consisting of a mixed 
 configuration (I am using 1.5-incubator-SNAPSHOT):
 
 1.   Java Library (jar packaging)
 
 2.   Windows Executable (winexe packaging)
 The release should be a jar containing the Java library with an embedded exe 
 (So I can load the binary from within my Java code)
 
 When using the Maven assembly plugin, all I get is this:
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.2.1:single (make-assembly) 
 on project lib-psexec-assembly: Failed to create assembly: Error adding 
 file-set for 'de.cware.utils:lib-psexec-service:winexe:1.0.0-SNAPSHOT' to 
 archive: Error adding archived file-set. PlexusIoResourceCollection not found 
 for: 
 C:\Maven-Repository\de\cware\utils\lib-psexec-service\1.0.0-SNAPSHOT\lib-psexec-service-1.0.0-SNAPSHOT.exe:
  No such archiver: 'exe'. - [Help 1]
 So it seems there is no archiver available to handle exe resources.
 
 So my question now is:
 How do I configure the assembly to do this or is the such an assembler simply 
 missing from NPanday and one should be implemented.
 
 I would volunteer implementing one, if this would be the way to go, I just 
 don't want to implement something that isn't needed.
 
 Chris
 
 
 [ C h r i s t o f e r  D u t z ]
 
 C-Ware IT-Service
 Inhaber
 Dipl. Inf. Christofer Dutz
 Karlstraße. 104, 64285 Darmstadt
 
 fon:  0 61 51 / 27315 - 61
 fax:  0 61 51 / 27315 - 64
 mobil:  0171 / 7 444 2 33
 email:  christofer.d...@c-ware.demailto:christofer.d...@c-ware.de
 http://www.c-ware.dehttp://www.c-ware.de/
 
 UStId-Nr. DE195700962

Handling configuration when packaging with NPanday

2012-01-09 Thread Lars Corneliussen

Hi guys,

I have some thoughts to share around configuration for the new packaging 
implementations in NPanday 1.5.0: cloud service, dotnet application, 
msdeploy/web applications.

Sorry for the long e-mail, but that really is important for me as dev, coach, 
npanday contributor, and user :-)

First, lets have a look at how Visual Studio handles the documentation for the 
various types:

web.config / app.config
Before Visual Studio 2008 one had to completely manually handle how the 
configuration is deployed onto other environments. I usually then deployed the 
config file initially only; after that i handled all changes to the 
configuration manually.

In 2008 three new features are added that make this easier. 

1) configuration can be split up in many files by using theSection 
configurationFile=../ on any section. Then you can deploy most of the config 
every time and just handle environment-specific configs in separate files like 
connectionStrings.config++

2) Config transforms (XDT); with right click on a web.config you can choose 
Add Config Transforms which will add a sub-file for each configuration in 
your Configuration Mangager, hence Web.Debug.config, Web.Release.config; those 
files are quite intelligent patch definitions applied to the main web.config 
on publish. By default this is only available for the main web.config, but not 
for sublevel web.configs nor for the app.config.

3) Parameters. Here you can define XPath-replacement-rules for various files; 
when unpacking/deploying a package with MSDeploy, by providing your 
environment-specific values for the defined parameters, the replacement will be 
applied to the files contained in the package. Sadly this is not integrated in 
Visual Studio, but has to be done manually.

Azure
Azure configurations consist of two parts: Cloud Service Definition (csdef) and 
Cloud Service Configuration (cscfg). The latter is meant to be 
environment-specific and Visual Studio allows you to configure multiple copies 
(Cloud, Local, ...). Csdef on the other hand is not (meant to be) environment 
specific and hence makes it into the Cloud Service Package (cspkg).

Sadly in the UI it is not easy to see what config setting is stored where; 
however when turning on a specifc configuration (! ALL) some options will be 
disabled; these are the ones that go into the csdef: endpoints, vm size, ...

NPanday
In NPanday we would like to unify how configuration is handled. The main goal 
must be to create and distribute environment-unspecific packages. NPanday 
should prevent the developer from accidentally including sensitive 
configuration elements like connection strings e.g. in (public) packages.

This is why we do not want to just xcopy all config files into the packages.

But rather we'd like to find a good generic approach to handling config files.

Wanted behaviour:

1) Instead of Debug and Release, Cloud and Local we use Package all 
over.

2) For Azure, by default, ServiceConfiguration.Azure.cscfg is distributed; it 
is a COPY, not a transformation. Should we support transformation here? XDT, 
XSL?

3) For Webs and Apps we use web. or app.package.config and copy it over as web. 
or app.config. Currently this also is a copy, but the plan is to make it a XDT 
transformation that then is applied to the main web. or app.config.

If the *.package.config file doesn't exist, it prints a warning. I think it 
should actually FAIL!! But should it rather fallback to web/app.config with the 
risk of including sensitive settings in the packages?

4) An application can have multiple configs (sublevel web.configs or 
splitted-out configs) which is not supported by the current implementation (can 
add them through a component descriptor though). I suggest we handle those in 
the same way? XDT applyable? Fallback?

Happy for any thoughts/answers around this issue.

_
Lars

Re: NPanday future direction for multi-platform

2012-01-05 Thread Lars Corneliussen

Question of design and naming. I certainly can make XDT pluggable, using the 
MSBuild version on Windows and make it fail, if it isn't available. .

With MSBuild I can try to make it easy to integrate xbuild later on. 

_
Mobil versendet. 

Am 05.01.2012 um 11:53 schrieb Brett Porter br...@apache.org:

 How much of this can be handled through the execution framework that is now 
 in place, so that a default implementation that works with Windows can be 
 built, but then someone inclined to use it could (now or later) implement an 
 alternative for Mono?
 
 - Brett
 
 On 05/01/2012, at 8:12 PM, Lars Corneliussen wrote:
 
 Hi,
 
 we have now integrated azure and msdeploy in 1.5.0; functionality that 
 certainly isn't and probably won't be available on other platforms than 
 Microsoft.NET/Windows.
 
 But still we have surrounding things. dotnet-application, for example, 
 supports packaging of runnables (config + exe/dll + deps) in a zip; that is 
 available to all platforms.
 
 https://issues.apache.org/jira/browse/NPANDAY-493
 Now, I want to create an XDT-plugin (XmlDocumentTransform) that enables 
 transformation of config-files in the packaging process (usually you 
 wouldn't like your local web.config/app.config) to be packaged unchanged. 
 
 XDT is provided by MSBuild, but there is also an alternative implementation 
 available, that maybe runs, or at least could be changed to run on mono, too 
 (http://code.google.com/p/xdt/). How much extra effort would it be worth to 
 choose that implementation instead of Microsofts, in order to support it on 
 !win?
 
 Alternatively we could also offer XSL-transformations only. Functional, 
 though not as comfortable as XDT.
 
 Anybody willing to help making XDT work on Mono?
 
 https://issues.apache.org/jira/browse/NPANDAY-486
 Then, we also think to implement MSBuild. Again, we have the option to 
 support Xbuild as well; does anybody want to support, doing this?
 
 any comments?
 
 Disclaimer: I'm not (yet) using Mono at all. Not on Windows, neither on my 
 Mac.
 _
 Lars
 
 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter
 http://twitter.com/brettporter

Re: svn commit: r1226446 - in /incubator/npanday/trunk/components/dotnet-core/src/main: groovy/npanday/lifecycle/LifecycleConfigurationGenerator.groovy java/npanday/ArtifactType.java

2012-01-02 Thread Lars Corneliussen

Same should be done for dotnet-application

_
Mobil versendet. 

Am 02.01.2012 um 16:49 schrieb br...@apache.org:

 Author: brett
 Date: Mon Jan  2 15:49:48 2012
 New Revision: 1226446
 
 URL: http://svn.apache.org/viewvc?rev=1226446view=rev
 Log:
 [NPANDAY-488] add includeDependencies to the artifact type for MSDeploy 
 packages, so that Azure projects don't have a problem trying to resolve the 
 dependencies
 
 Modified:

 incubator/npanday/trunk/components/dotnet-core/src/main/groovy/npanday/lifecycle/LifecycleConfigurationGenerator.groovy

 incubator/npanday/trunk/components/dotnet-core/src/main/java/npanday/ArtifactType.java
 
 Modified: 
 incubator/npanday/trunk/components/dotnet-core/src/main/groovy/npanday/lifecycle/LifecycleConfigurationGenerator.groovy
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/trunk/components/dotnet-core/src/main/groovy/npanday/lifecycle/LifecycleConfigurationGenerator.groovy?rev=1226446r1=1226445r2=1226446view=diff
 ==
 --- 
 incubator/npanday/trunk/components/dotnet-core/src/main/groovy/npanday/lifecycle/LifecycleConfigurationGenerator.groovy
  (original)
 +++ 
 incubator/npanday/trunk/components/dotnet-core/src/main/groovy/npanday/lifecycle/LifecycleConfigurationGenerator.groovy
  Mon Jan  2 15:49:48 2012
 @@ -59,6 +59,10 @@ class LifecycleConfigurationGenerator {
configuration{
extension typeDef.extension
type typeDef.packagingType
 +if (typeDef.includesDependencies)
 +{
 +  includesDependencies typeDef.includesDependencies
 +}
}
}
}
 
 Modified: 
 incubator/npanday/trunk/components/dotnet-core/src/main/java/npanday/ArtifactType.java
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/trunk/components/dotnet-core/src/main/java/npanday/ArtifactType.java?rev=1226446r1=1226445r2=1226446view=diff
 ==
 --- 
 incubator/npanday/trunk/components/dotnet-core/src/main/java/npanday/ArtifactType.java
  (original)
 +++ 
 incubator/npanday/trunk/components/dotnet-core/src/main/java/npanday/ArtifactType.java
  Mon Jan  2 15:49:48 2012
 @@ -176,7 +176,7 @@ public enum ArtifactType
 AZURE_CLOUD_SERVICE_CONFIGURATION (azure-cloud-service-configuration, 
 null, cscfg),
 
 /* MSDeploy support */
 -MSDEPLOY_PACKAGE (msdeploy-package, null, msdeploy.zip);
 +MSDEPLOY_PACKAGE (msdeploy-package, null, msdeploy.zip, true);
 
 /**
  * The extension used for the artifact(netmodule, dll, exe)
 @@ -194,6 +194,12 @@ public enum ArtifactType
 private String targetCompileType;
 
 /**
 + * Whether to flag the artifact type as including its dependencies (do 
 not pass them on transitively), or not (pass
 + * them on transitively)
 + */
 +private boolean includesDependencies = false;
 +
 +/**
  * Constructor
  */
 ArtifactType( String packagingType, String targetCompileType, String 
 extension )
 @@ -204,6 +210,17 @@ public enum ArtifactType
 }
 
 /**
 + * Constructor
 + */
 +ArtifactType( String packagingType, String targetCompileType, String 
 extension, boolean includesDependencies )
 +{
 +this.packagingType = packagingType;
 +this.targetCompileType = targetCompileType;
 +this.extension = extension;
 +this.includesDependencies = includesDependencies;
 +}
 +
 +/**
  * Returns extension used for the artifact(netmodule, dll, exe).
  *
  * @return Extension used for the artifact(netmodule, dll, exe).
 @@ -233,6 +250,11 @@ public enum ArtifactType
 return targetCompileType;
 }
 
 +public boolean isIncludesDependencies()
 +{
 +return includesDependencies;
 +}
 +
 /**
  * Returns artifact type for the specified packaging name
  *

Re: svn commit: r1226489 - in /incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src: main/csharp/Converter/Algorithms/ test/resource/MvcApplication1/MvcApplication1/ test/resou

2012-01-02 Thread Lars Corneliussen

XDT will then also require a new file to be added.

_
Mobil versendet. 

Am 02.01.2012 um 18:35 schrieb br...@apache.org:

 Author: brett
 Date: Mon Jan  2 17:35:35 2012
 New Revision: 1226489
 
 URL: http://svn.apache.org/viewvc?rev=1226489view=rev
 Log:
 [NPANDAY-488] adjust default config behaviour until XDT is in place, so that 
 a reasonable Web/app.config is
 
 Modified:

 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/ASPNetPomConverter.cs

 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/AzureWorkerPomConverter.cs

 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/test/resource/MvcApplication1/MvcApplication1/pom.test

 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/test/resource/NPANDAY_480_AzureSupportOneWebRole/HelloWorld_WebRole/pom.test

 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/test/resource/NPANDAY_480_CloudServiceWithMultipleRoles/HelloWorld_WebRole/pom.test

 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/test/resource/NPANDAY_480_CloudServiceWithMultipleRoles/HelloWorld_WorkerRole/pom.test

 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/test/resource/NPANDAY_480_CloudServiceWithWorkerRole/HelloWorld_WorkerRole/pom.test

 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/test/resource/NPANDAY_488/NPANDAY_488_MSDeployPackageSimpleWebApp/pom.test
 
 Modified: 
 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/ASPNetPomConverter.cs
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/ASPNetPomConverter.cs?rev=1226489r1=1226488r2=1226489view=diff
 ==
 --- 
 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/ASPNetPomConverter.cs
  (original)
 +++ 
 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/ASPNetPomConverter.cs
  Mon Jan  2 17:35:35 2012
 @@ -40,17 +40,14 @@ namespace NPanday.ProjectImporter.Conver
 
 Liststring goals = new Liststring();
 goals.Add(assemble-package-files);
 -foreach (Content content in projectDigest.Contents)
 -{
 -if (content.IncludePath.Equals(web.package.config, 
 System.StringComparison.InvariantCultureIgnoreCase))
 -{
 -goals.Add(process-web-config);
 -}
 -}
 +goals.Add(process-web-config);
 
 Plugin aspnetPlugin = AddPlugin(org.apache.npanday.plugins, 
 aspnet-maven-plugin, null, false);
 AddPluginExecution(aspnetPlugin, prepare-package, 
 goals.ToArray(), null);
 
 +// TODO: until XDT works, just use Web.config itself
 +AddPluginConfiguration(aspnetPlugin, webConfig, Web.config);
 +
 Plugin msdeployPlugin = AddPlugin(org.apache.npanday.plugins, 
 msdeploy-maven-plugin, null, false);
 AddPluginExecution(msdeployPlugin, create-msdeploy-package, new 
 string[] { create-package }, null);
 
 
 Modified: 
 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/AzureWorkerPomConverter.cs
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/AzureWorkerPomConverter.cs?rev=1226489r1=1226488r2=1226489view=diff
 ==
 --- 
 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/AzureWorkerPomConverter.cs
  (original)
 +++ 
 incubator/npanday/trunk/dotnet/assemblies/NPanday.ProjectImporter/Engine/src/main/csharp/Converter/Algorithms/AzureWorkerPomConverter.cs
  Mon Jan  2 17:35:35 2012
 @@ -40,18 +40,15 @@ namespace NPanday.ProjectImporter.Conver
 
 Liststring goals = new Liststring();
 goals.Add(assemble-package-files);
 -foreach (Content content in projectDigest.Contents)
 -{
 -if (content.IncludePath.Equals(app.package.config, 
 System.StringComparison.InvariantCultureIgnoreCase))
 -{
 -goals.Add(process-app-config);
 -}
 -}
 +goals.Add(process-app-config);
 goals.Add(package);
 
 Plugin plugin = AddPlugin(org.apache.npanday.plugins, 
 application-maven-plugin, null, false);
 AddPluginExecution(plugin, package-application, 
 goals.ToArray(),

Re: Contributing to wix-maven-plugin

2011-12-22 Thread Lars Corneliussen

Hi Adrián,

I'm a little bit christmas-offline now. So Sit and wait can happen sometimes :)

There is a way to become an NPanday developer, but it'll require a couple of
good patches that drive the project in the right direction. It also usually
takes some time until patches are available in a new release.

When I originally had a series of patches for NPanday, I had a private git
repository based on https://github.com/apache/npanday to keep a fork for a
while.
I also then wrote a utility that helped me creating SVN-compatible patches from
git feature branches here: http://lcorneliussen.de/utils/git-svn/github.com

_
Lars

Am 22.12.2011 um 15:53 schrieb Adrián Boimvaser:

Hi Lars?

What's next? Sit and wait?
I made some refactorings and improvements to wix-maven plugin I would also
like to contribute.
Is there a way I can become a NPanday developer?

Thanks.
Adrián.

2011/12/21 Adrián Boimvaser adrianboimva...@gmail.com

Thanks Lars,

I created the issue and attached the patch.

https://issues.apache.org/jira/browse/NPANDAY-510

Adrián.

2011/12/21 Lars Corneliussen m...@lcorneliussen.de

Hi Adrián,

happy to hear that.
The best is, if you create an issue and attach the patch here:

https://issues.apache.org/jira/secure/CreateIssue.jspa?pid=12311182issuetype=4Create=Create

Is that ok for you?
_
Lars

Am 21.12.2011 um 13:35 schrieb Adrián Boimvaser:

Hi, I'd like to make a contribution to wix-maven-plugin. Where should I
send the patch?
Thanks.
Adrián Boimvaser

Re: svn commit: r1221092 - /incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java

2011-12-19 Thread Lars Corneliussen

why is it skipped on !Windows?

_
Mobil versendet. 

Am 20.12.2011 um 05:06 schrieb br...@apache.org:

 Author: brett
 Date: Tue Dec 20 04:06:05 2011
 New Revision: 1221092
 
 URL: http://svn.apache.org/viewvc?rev=1221092view=rev
 Log:
 show more information for settings generator, so there's less confusion when 
 it is skipped
 
 Modified:

 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java
 
 Modified: 
 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java?rev=1221092r1=1221091r2=1221092view=diff
 ==
 --- 
 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java
  (original)
 +++ 
 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java
  Tue Dec 20 04:06:05 2011
 @@ -157,6 +157,7 @@ public class SettingsGeneratorMojo
 {
 if ( !System.getProperty( os.name ).contains( Windows ) )
 {
 +getLog().info( NPANDAY-119-001: Skipping settings generation, 
 only valid on Windows operating systems );
 return false;
 }
 
 @@ -175,11 +176,13 @@ public class SettingsGeneratorMojo
 {
 if ( isFrameworkVersionExisting( frameworkVersion ) )
 {
 +getLog().info( NPANDAY-119-002: Skipping settings 
 generation, requested framework  + frameworkVersion +  is already 
 configured );
 return false;
 }
 }
 catch ( IOException e )
 {
 +getLog().info( NPANDAY-119-003: Skipping settings 
 generation, error reading existing file:  + e.getLocalizedMessage() );
 return false;
 }
 }

Re: svn commit: r1221092 - /incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java

2011-12-19 Thread Lars Corneliussen

Also an error reading the current file should just be thrown; it is an error 
that the user has to fix. most certainly he edited it himself. NPanday should 
then just fail. 

_
Mobil versendet. 

Am 20.12.2011 um 05:06 schrieb br...@apache.org:

 Author: brett
 Date: Tue Dec 20 04:06:05 2011
 New Revision: 1221092
 
 URL: http://svn.apache.org/viewvc?rev=1221092view=rev
 Log:
 show more information for settings generator, so there's less confusion when 
 it is skipped
 
 Modified:

 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java
 
 Modified: 
 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java?rev=1221092r1=1221091r2=1221092view=diff
 ==
 --- 
 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java
  (original)
 +++ 
 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/javabinding/src/main/java/NPanday/Plugin/Settings/SettingsGeneratorMojo.java
  Tue Dec 20 04:06:05 2011
 @@ -157,6 +157,7 @@ public class SettingsGeneratorMojo
 {
 if ( !System.getProperty( os.name ).contains( Windows ) )
 {
 +getLog().info( NPANDAY-119-001: Skipping settings generation, 
 only valid on Windows operating systems );
 return false;
 }
 
 @@ -175,11 +176,13 @@ public class SettingsGeneratorMojo
 {
 if ( isFrameworkVersionExisting( frameworkVersion ) )
 {
 +getLog().info( NPANDAY-119-002: Skipping settings 
 generation, requested framework  + frameworkVersion +  is already 
 configured );
 return false;
 }
 }
 catch ( IOException e )
 {
 +getLog().info( NPANDAY-119-003: Skipping settings 
 generation, error reading existing file:  + e.getLocalizedMessage() );
 return false;
 }
 }

Re: Jenkins CI is up

2011-12-09 Thread Lars Corneliussen

agree. 

_
Mobil versendet. 

Am 08.12.2011 um 17:53 schrieb Brett Porter br...@apache.org:

 
 On 08/12/2011, at 6:53 PM, Lars Corneliussen wrote:
 
 
 Am 06.12.2011 um 22:27 schrieb Brett Porter:
 
 
 On 07/12/2011, at 5:15 AM, Lars Corneliussen wrote:
 
 That is good news!!! Some questions:
 
 1) what about embedded integration tests? should those run in the normal 
 build? guess it takes too long?
 
 what do you mean by embedded? The wix-like ones, or running the current ITs 
 without forking Maven?
 The wix-like ones. I'm writing some of these for new plugins, too.
 
 That's currently an extra 3 minutes, so I imagine with more tests it would 
 take too long for quick feedback. It would also be helpful to get a separate 
 build history for the main build and the one with ITs on, IMO.
 
 - Brett
 
 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter

Draft: Incubator PMC/Board report for Dec 2011

2011-12-08 Thread Lars Corneliussen

Hi. Here is my draft for the PMC/Board report. Any comments?

NPanday

NPanday allows projects using the .NET framework to be built with Apache Maven. 
NPanday allows .NET projects to be converted into Maven projects thus allowing 
them to fully utilize the other technologies driven by Maven. NPanday has been 
incubating since August 2010.

We are now in the process of releasing NPanday-1.4.1-incubating and at the same 
time developing NPanday-1.5.0-incubating, which will come with azure- and 
silverlight support as well as quite extensive core refactorings removing 
historical burden.

We are also happy to report that our community continues to gain new people in 
terms of patch contributors and reporters on issues.

The top priorities towards graduation are:

* regular release
* guide regular patch contributors towards becoming committers
* improve engagement of existing committers

There are no issues for the Incubator PMC or board at this time.

Re: What do you use MSBuild-plugin for? Rethinking MSBuild / Xbuild integration

2011-11-22 Thread Lars Corneliussen

I think we can offer both versions in two separate MSBuild lifecycles: 
integrated and delegated

Details on this idea are all documented on the issue, but let me give a brief 
summary of the plan:

The integrated lifecycle would still leave use NPanday to do the actual 
compile, but generate sources and resources which then will automatically be 
added to pom/build/resources and sources (in-memory)

The delegating lifecycle would leave the artifact generation to MSBuild. But 
NPanday would surround it and ensure MSBuild to respect dependencies 
correctly and use correct output paths, e.g.

If people then just want to execute MSBuild as-is, I'd point them to the 
custom-lifecycle and maven-exec-plugin - IMHO we shouldn't support that 
requirement.
_
Lars


Am 22.11.2011 um 05:44 schrieb Brett Porter:

 Hi Lars,
 
 Those requirements look good to me.
 
 While I prefer that approach, I wonder if it might become too complicated in 
 some projects. I'm still curious if there is a usecase for NPANDAY-244 to 
 provide a simpler (though less rich) build mechanism that effectively 
 delegates to msbuild, then allows NPanday users to augment it with some 
 dependency/distribution management and the execution of additional plugins in 
 the lifecycle.
 
 Cheers,
 Brett
 
 (BTW, dropping -users CC - to avoid cross-posting it might be better just to 
 point them to the -dev@ thread in future)
 
 On 22/11/2011, at 3:34 AM, Lars Corneliussen wrote:
 
 Hello dear NPanday users and developers,
 
 we think of reimplementing the integration with MSbuild since the current 
 solution is quite fragile and erroneous.
 
 I have started to document my thoughts here and i'd be really happy to get 
 feedback from you all! Especially I'd like to hear if, and how, you use the 
 current MSBuild plugin.
 
 Please anwer to this Mail, or even better, write a comment on the issue.
 https://issues.apache.org/jira/browse/NPANDAY-486
 
 _
 Lars
 Apache NPanday Committer
 
 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter

Discontinue or update the vsinstaller plugin !?

2011-11-21 Thread Lars Corneliussen

Hi again,

the maven-vsinstaller-plugin is outdated. On my machine it even fails, because 
it can't find a component descriptor for dotnet-module - vsinstaller has it's 
own Components.xml in order to be able to run standalone.

If we want to keep it up to date, we would have to:

1) Remove the Components.xml and instead create a package (Assembly-plugin) in 
VisualStudio.Addin that contains needed DLLs and the .AddIn-file and then reuse 
the same for both the wix-based Windows installer and vsinstaller-plugin (see 
https://issues.apache.org/jira/browse/NPANDAY-293).

Then, on install, only override the bin-path for the DLL.

2) Update the documentation of the plugin (usage).

3) Update the documentation of how to debug NPanday Addin (because then the 
developer can just use the vsinstaller) 

_
Lars

Re: Discontinue or update the vsinstaller plugin !?

2011-11-21 Thread Lars Corneliussen

Actually I was wrong - it's just that you can't run the VS installer plugin 
while you are located in some Maven Project that contains dotnet-module 
packaging.


Am 21.11.2011 um 12:26 schrieb Lars Corneliussen:

 Hi again,
 
 the maven-vsinstaller-plugin is outdated. On my machine it even fails, 
 because it can't find a component descriptor for dotnet-module - vsinstaller 
 has it's own Components.xml in order to be able to run standalone.
 
 If we want to keep it up to date, we would have to:
 
 1) Remove the Components.xml and instead create a package (Assembly-plugin) 
 in VisualStudio.Addin that contains needed DLLs and the .AddIn-file and then 
 reuse the same for both the wix-based Windows installer and 
 vsinstaller-plugin (see https://issues.apache.org/jira/browse/NPANDAY-293).
 
 Then, on install, only override the bin-path for the DLL.
 
 2) Update the documentation of the plugin (usage).
 
 3) Update the documentation of how to debug NPanday Addin (because then the 
 developer can just use the vsinstaller) 
 
 _
 Lars

What do you use MSBuild-plugin for? Rethinking MSBuild / Xbuild integration

2011-11-21 Thread Lars Corneliussen

Hello dear NPanday users and developers,

we think of reimplementing the integration with MSbuild since the current 
solution is quite fragile and erroneous.

I have started to document my thoughts here and i'd be really happy to get 
feedback from you all! Especially I'd like to hear if, and how, you use the 
current MSBuild plugin.

Please anwer to this Mail, or even better, write a comment on the issue.
https://issues.apache.org/jira/browse/NPANDAY-486

_
Lars
Apache NPanday Committer

Re: Remove repitetive namespace folder segments

2011-11-15 Thread Lars Corneliussen

Then we have to drop src/main/csharp, too. 

Tests could be in a subfolder 'Test' or 'Tests', resources are kept together 
with normal sources. 

That would be most common while adding the possibility to have tests together 
with the code, but omit it in the compiled assembly. Most .NET-Developers will 
fi d that to be good news and it is optional anyway. 

_
Lars

_
Mobil versendet. 

Am 15.11.2011 um 09:57 schrieb Brett Porter br...@apache.org:

 Sounds good to me. The conventional directory layout should be what most .NET 
 developers expect it to be (but still configurable).
 
 - Brett
 
 On 14/11/2011, at 11:25 PM, Lars Corneliussen wrote:
 
 Hi guys,
 
 in java it is common to have package folders inside 'src/main/java', as for 
 example 'npanday/plugins/compile' - in .NET on the other hand we just 
 configure a root namespace in the project file and then start with folders 
 from there.
 
 I'd like to do that in NPanday, too. That means remove the path-segments 
 that repeat the default namespace per project.
 
 Any objections?
 
 _
 Lars
 
 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/

Re: NPanday Visibility

2011-11-14 Thread Lars Corneliussen

Agree! Java dev's will still find it :)

NPanday / Maven is about much more than dependency management; but still, 
without a good repository containing everything (Maven Central / Nuget 
Gallery), it will be hard to reach the masses.

Integration with Nuget Gallery, and a new fresher Website will help us gaining 
momentum.

Currently, when you visit http://incubator.apache.org/npanday/ you need 5 
minutes to figure out what it is about.

Try http://ninject.org/ ; after 10 seconds, you'll be able to tell me what it 
is about.

The same with http://nuget.org/

_
Lars



Am 13.11.2011 um 01:02 schrieb Brett Porter:

 Currently the site is a bit oriented towards Maven users who want to build 
 .NET projects. Perhaps we need some HOWTO's titled .NET dependency 
 management, oriented more at bringing NPanday's capability to the 
 conventional .NET user?
 
 On 09/11/2011, at 5:05 AM, Lars Corneliussen wrote:
 
 Hi guys,
 
 I got a comment on my blog:
 
 Hi, I think, it’s a great project! Please, make this project more visible, 
 we are using Maven for Java and we searched for “.net dependency 
 management”. All we found was some alpha projects at codplex (refix and 
 crude have around 30 downloads). After an extensive search we have found 
 NuGet and OpenWrap. I have found this project completely accidentally!!! It 
 would be really useful to get least some google hits to npanday on the 
 first page….
 
 
 Any concrete ideas on how to make NPanday more visible?
 
 _
 Lars
 
 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/

Remove repitetive namespace folder segments

2011-11-14 Thread Lars Corneliussen

Hi guys,

in java it is common to have package folders inside 'src/main/java', as for 
example 'npanday/plugins/compile' - in .NET on the other hand we just configure 
a root namespace in the project file and then start with folders from there.

I'd like to do that in NPanday, too. That means remove the path-segments that 
repeat the default namespace per project.

Any objections?

_
Lars

[vote] NPanday Source: Move on to VS 2010, but still target CLR 2.0 + .NET 3.5

2011-11-10 Thread Lars Corneliussen

Hi,

it would be great, if we could use the many new language features introduced in 
C# 3.0 and 4.0.

If I implement multi-targeting 
(https://issues.apache.org/jira/browse/NPANDAY-404), is it then OK to require 
.NET 4.0 tools and Visual Studio 2010 for all NPanday developers?

_
Lars

Re: How can I contribute? (and a bug feature request)

2011-11-02 Thread Lars Corneliussen

Hi Stoyan,

welcome to the list!

We have some Get Involved documentation here:
http://incubator.apache.org/npanday/docs/1.4.0-incubating/developers/index.html

Preamble: I'm a .NET-guy, as you easily can see on my blog 
(http://lcorneliussen.de/blog)

I agree with you; .NET is way behind Java in terms of build tools. It was sad 
for me that the guys at Microsoft that built Nuget (and Guys that built the 
preceeding Nu) didn't even know about Apache Maven - and neither about 
NPanday. The .NET-Community struggles to learn from other communities.

I joined the team in October 2010 because I think NPanday is absolutely the 
right horse to bet on. But still, there is loads of work to do.

 One more thing. No offense but the current code base (I have only looked at
 the .NET code so far) needs some cleaning up (TODOs, XML parsing, etc.).
 Let me know if you're interested in a code review and to who I should e-mail
 it, also I'll be more than glad to do most of the clean up myself if I'd be
 allowed to push/propose changes.

I guess that about 50% of the Java code is simply dispensable. And the .NET 
code is quite badly organized. 
I think we rather need concrete improvement suggestions + patches - in small 
steps, than a code review :-)

A year ago I started some work on the VS plugin, refactoring to command 
pattern, but I didn't manage to finish it: 
https://github.com/lcorneliussen/npanday/commit/5ed038f9bb38a957d40d14bba8895ac9337e8aaa

I also commented on the two issues you mentioned/submitted.
_
Lars


https://github.com/lcorneliussen/npanday/commit/5ed038f9bb38a957d40d14bba8895ac9337e8aaa
Am 01.11.2011 um 21:44 schrieb Stoyan Damov:

 Hi guys,
 
 First, sorry if the I'm not following the protocol for sending a single
 thing in one e-mail (e.g. this is a question, a bug report, and a feature
 request) but I couldn't find a How to send e-mails to this list link.
 
 Our company is evaluating NPanDay for use by our the .NET team (the Java
 team is already using maven), mainly to get rid of NuGet as a dependency
 management system with which we're not at all happy, but also to have a
 common toolset (.NET tools are years behind the ones for Java).
 From my little experience with NPanDay I believe it's the cure we were
 looking for (we were interested in NPanDay for quite some time but because
 we're using .NET framework 4  VS 2010 previous versions were not worth
 evaluating).
 
 I found some problems (described below) in NPanDay.VisualStudio.Plugin
 (mainly in ReferenceManager) which I QD fixed. However, I'd like to
 actually do a more thorough code review  make the best possible fix, and
 then propose it.
 I couldn't find what's the ceremony of submitting a patch, hence I'm
 asking on this list. Sorry if that's not the right place for that.
 
 The first bug is in Resync references which calls
 ReferenceManager.CopyArtifact:
 
 if (!artifact.FileInfo.Exists || artifact.Version.EndsWith(SNAPSHOT))
 {
if 
 (!NPanday.ProjectImporter.Digest.Model.Reference.DownloadArtifact(artifact,l
 ogger))
{
ReferenceErrorEventArgs e = new ReferenceErrorEventArgs();
e.Message = string.Format(Unable to get the artifact {0} from any
 of your repositories., artifact.ArtifactId);
onError(e);
return;
}
 }
 
 The check for SNAPSHOT above forces Resync references to try and download
 the artifact off the remote repository.
 If the artifact is not yet installed (which is common if I'm developing a
 new module but don't want to commit/push it yet), what happens is that:
 1. The resync fails (which is bad) and
 2. If the artifact is installed in the local repo, it gets deleted (which is
 worse)
 
 What should happen (for SNAPSHOTs) instead is this:
 
 1. Try to get timestamp of artifact in remote repo. If that fails, it
 shouldn't be a problem, the artifact might not be deployed (yet).
 2. Try to get timestamp of artifact in local repo. If that fails, then this
 is an error and should be reported.
 3. Get the timestamp of the local file (in .references/...)
 4. If there's a remote timestamp and it's greater than the local one, update
 the local repo's artifact.
 5. If the local repo's timestamp (possibly updated at point 4) is greater
 than the timestamp of the local file, update the file in .references/...
 
 For steps 1 and 2 use the timestamp in maven-metadata.xml (in
 ReferenceManager.copyToReferenceFolder there's already a TODO which suggests
 to use metadata/versioning/lastUpdated for the timestamp).
 Currently, the local repo's timestamp is considered to be the file's last
 write time (not even .LastWriteTimeUtc, which is another bug).
 
 To make it clear, since we're all developers, here's the algo in pseudo code
 (this might not compile, I'm writing it in Outlook):
 
 DateTime remoteRepoTimestamp, localRepoTimestamp, localFileTimestamp;
 bool hasRemoteTimestamp =TryGetArtifactRemoteRepositoryTimestamp(artifact,
 logger, out remoteRepoTimestamp);
 bool hasLocalRepoTimestamp =

Re: How can I contribute? (and a bug feature request)

2011-11-02 Thread Lars Corneliussen

 I'll do my best to help NPanday kill NuGet ;)

I think we could rather use the momentum behind the NuGet Gallery to speed up 
the adoption of NPanday...
Maven encourages lazyness... who will ever download a jar manually? Everything, 
in every version, is on Maven Central.

But with NPanday you still have to deploy every single .NET-Dependency 
yourself. If we could leverage Nuget Gallery (groupId 'nuget' :-), or what ever 
is before the first '.' in the nuget name) that would be a huge benefit:
https://issues.apache.org/jira/browse/NPANDAY-372

 I recently spoke to a guy (to remain nameless) at Microsoft (and works
 with Phil Haack) who said our company is one of the 5 in the world having
 a .NET  Java division,

Every company with more than 20 developers does Java, .NET and PHP; even 
Microsoft does Java and PHP. Sad to hear such words from the lonely isle of 
DevDiv.

  I simply don't buy
 that, hence I'm more than happy to contribute to NPanday. He didn't know
 about Apache Maven and NPanday as well, which as you said is sad.
Me neither; and again welcome! The road to become a committer isn't hard either 
- after a few good patches, that drive the project in the correct direction, 
we'll set up you up for a vote :-)

_
Lars

Am 02.11.2011 um 09:42 schrieb Stoyan Damov:

 Thanks for the warm welcome!
 
 I'll do my best to help NPanday kill NuGet ;)
 
 I recently spoke to a guy (to remain nameless) at Microsoft (and works
 with Phil Haack) who said our company is one of the 5 in the world having
 a .NET  Java division, and that the things I want from NuGet simply don't
 match the needs of the 80% of NuGet's target group. I simply don't buy
 that, hence I'm more than happy to contribute to NPanday. He didn't know
 about Apache Maven and NPanday as well, which as you said is sad.
 
 Cheers,
 Stoyan
 
 
 
 On 11/2/11 9:45 AM, Lars Corneliussen m...@lcorneliussen.de wrote:
 
 Hi Stoyan,
 
 welcome to the list!
 
 We have some Get Involved documentation here:
 http://incubator.apache.org/npanday/docs/1.4.0-incubating/developers/index
 .html
 
 Preamble: I'm a .NET-guy, as you easily can see on my blog
 (http://lcorneliussen.de/blog)
 
 I agree with you; .NET is way behind Java in terms of build tools. It was
 sad for me that the guys at Microsoft that built Nuget (and Guys that
 built the preceeding Nu) didn't even know about Apache Maven - and
 neither about NPanday. The .NET-Community struggles to learn from other
 communities.
 
 I joined the team in October 2010 because I think NPanday is absolutely
 the right horse to bet on. But still, there is loads of work to do.
 
 One more thing. No offense but the current code base (I have only
 looked at
 the .NET code so far) needs some cleaning up (TODOs, XML parsing,
 etc.).
 Let me know if you're interested in a code review and to who I should
 e-mail
 it, also I'll be more than glad to do most of the clean up myself if
 I'd be
 allowed to push/propose changes.
 
 I guess that about 50% of the Java code is simply dispensable. And the
 .NET code is quite badly organized.
 I think we rather need concrete improvement suggestions + patches - in
 small steps, than a code review :-)
 
 A year ago I started some work on the VS plugin, refactoring to command
 pattern, but I didn't manage to finish it:
 https://github.com/lcorneliussen/npanday/commit/5ed038f9bb38a957d40d14bba8
 895ac9337e8aaa
 
 I also commented on the two issues you mentioned/submitted.
 _
 Lars
 
 
 https://github.com/lcorneliussen/npanday/commit/5ed038f9bb38a957d40d14bba8
 895ac9337e8aaa
 Am 01.11.2011 um 21:44 schrieb Stoyan Damov:
 
 Hi guys,
 
 First, sorry if the I'm not following the protocol for sending a
 single
 thing in one e-mail (e.g. this is a question, a bug report, and a
 feature
 request) but I couldn't find a How to send e-mails to this list link.
 
 Our company is evaluating NPanDay for use by our the .NET team (the Java
 team is already using maven), mainly to get rid of NuGet as a
 dependency
 management system with which we're not at all happy, but also to have a
 common toolset (.NET tools are years behind the ones for Java).
 From my little experience with NPanDay I believe it's the cure we were
 looking for (we were interested in NPanDay for quite some time but
 because
 we're using .NET framework 4  VS 2010 previous versions were not worth
 evaluating).
 
 I found some problems (described below) in NPanDay.VisualStudio.Plugin
 (mainly in ReferenceManager) which I QD fixed. However, I'd like to
 actually do a more thorough code review  make the best possible fix,
 and
 then propose it.
 I couldn't find what's the ceremony of submitting a patch, hence I'm
 asking on this list. Sorry if that's not the right place for that.
 
 The first bug is in Resync references which calls
 ReferenceManager.CopyArtifact:
 
 if (!artifact.FileInfo.Exists || artifact.Version.EndsWith(SNAPSHOT))
 {
   if 
 
 (!NPanday.ProjectImporter.Digest.Model.Reference.DownloadArtifact(artifac
 t,l
 ogger

Re: How can I contribute? (and a bug feature request)

2011-11-01 Thread Lars Corneliussen

Correct list; no rules violated! :) 

Regarding the state of the .NET-Code: I could't agree more. And it is not much 
better on the Java side; but still the right horse to bet on!!

I'll answer more in detail tomorrow!

cheers,
Lars

_
Mobil versendet. 

Am 01.11.2011 um 21:44 schrieb Stoyan Damov stoyan.da...@pirinsoft.com:

 Hi guys,
 
 First, sorry if the I'm not following the protocol for sending a single
 thing in one e-mail (e.g. this is a question, a bug report, and a feature
 request) but I couldn't find a How to send e-mails to this list link.
 
 Our company is evaluating NPanDay for use by our the .NET team (the Java
 team is already using maven), mainly to get rid of NuGet as a dependency
 management system with which we're not at all happy, but also to have a
 common toolset (.NET tools are years behind the ones for Java).
 From my little experience with NPanDay I believe it's the cure we were
 looking for (we were interested in NPanDay for quite some time but because
 we're using .NET framework 4  VS 2010 previous versions were not worth
 evaluating).
 
 I found some problems (described below) in NPanDay.VisualStudio.Plugin
 (mainly in ReferenceManager) which I QD fixed. However, I'd like to
 actually do a more thorough code review  make the best possible fix, and
 then propose it.
 I couldn't find what's the ceremony of submitting a patch, hence I'm
 asking on this list. Sorry if that's not the right place for that.
 
 The first bug is in Resync references which calls
 ReferenceManager.CopyArtifact:
 
 if (!artifact.FileInfo.Exists || artifact.Version.EndsWith(SNAPSHOT))
 {
if 
 (!NPanday.ProjectImporter.Digest.Model.Reference.DownloadArtifact(artifact,l
 ogger))
{
ReferenceErrorEventArgs e = new ReferenceErrorEventArgs();
e.Message = string.Format(Unable to get the artifact {0} from any
 of your repositories., artifact.ArtifactId);
onError(e);
return;
}
 }
 
 The check for SNAPSHOT above forces Resync references to try and download
 the artifact off the remote repository.
 If the artifact is not yet installed (which is common if I'm developing a
 new module but don't want to commit/push it yet), what happens is that:
 1. The resync fails (which is bad) and
 2. If the artifact is installed in the local repo, it gets deleted (which is
 worse)
 
 What should happen (for SNAPSHOTs) instead is this:
 
 1. Try to get timestamp of artifact in remote repo. If that fails, it
 shouldn't be a problem, the artifact might not be deployed (yet).
 2. Try to get timestamp of artifact in local repo. If that fails, then this
 is an error and should be reported.
 3. Get the timestamp of the local file (in .references/...)
 4. If there's a remote timestamp and it's greater than the local one, update
 the local repo's artifact.
 5. If the local repo's timestamp (possibly updated at point 4) is greater
 than the timestamp of the local file, update the file in .references/...
 
 For steps 1 and 2 use the timestamp in maven-metadata.xml (in
 ReferenceManager.copyToReferenceFolder there's already a TODO which suggests
 to use metadata/versioning/lastUpdated for the timestamp).
 Currently, the local repo's timestamp is considered to be the file's last
 write time (not even .LastWriteTimeUtc, which is another bug).
 
 To make it clear, since we're all developers, here's the algo in pseudo code
 (this might not compile, I'm writing it in Outlook):
 
 DateTime remoteRepoTimestamp, localRepoTimestamp, localFileTimestamp;
 bool hasRemoteTimestamp =TryGetArtifactRemoteRepositoryTimestamp(artifact,
 logger, out remoteRepoTimestamp);
 bool hasLocalRepoTimestamp =
 TryGetArtifactLocalRepositoryTimestamp(artifact, logger, out
 localRepoTimestamp);
 localFileTimestamp = GetLocalFileTimestamp(artifact.FileInfo, logger);
 if (hasRemoteTimestamp  hasLocalRepoTimestamp  remoteRepoTimestamp 
 localRepoTimestamp)
 {
 UpdateLocalRepoArtifact(); // ==
 NPanday.ProjectImporter.Digest.Model.Reference.DownloadArtifact(artifact,
 logger)
 // ^^ error handling above omitted for brevity
 localRepoTimestamp = remoteRepoTimestamp;
 }
 if (hasLocalRepoTimestamp  localRepoTimestamp  localFileTimestamp)
 {
 copyToReferenceFolder(artifact, referenceFolder);
 } 
 
 Something like this.
 
 
 The 2nd thing is that there's a pretty good case to have Resync references
 from *local* repo and Resync references (from remote, which is described
 in the bug above).
 Resync references from local repo should skip the remote repo. Here's the
 valid case:
 
 I'm working on X and Y. I make a change in X and maven install it (in the
 local repo). I don't push the changes to the SCM.
 Y has a dependency on X and I want to resync the references so that I get
 the updated X dependency. Currently I can't do that.
 
 I can't (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.

Re: .NetPortable support analysis

2011-07-06 Thread Lars Corneliussen

So far we determine the tools by vendor, vendorVersion, frameworkVersion 
(npanday-settings.xml) and then we have profile within that version 
(compiler-plugins.xml), right?


This could be:

Microsoft;3.0;2.0+FULL
Mono;2.6;2.0+FULL

I don't know .NETPortable, but:

a) if it is a different toolset, and not really part of .NET framework 
releases, we should maybe rephrase Vendor by Distribution or so - 
and then add .NETPortable


b) if it is a part of .NET core (versioned within), a profile 
.NETPortable,Profile2 might be enough.


But I rather think .NETPortable is comparable to silverlight, which is 
separately released and still not supported by NPanday.




From here, what about respecifying the attributes:

vendor: means, what it means today
vendorVersion: this one, too

runtime: CLR, Mono, silverlight, Portable?
runtimeVersion: instead of frameworkVersion
runtimeProfile: Profile2, FULL, CLIENT, ...



What do you guys think?


Am 06.07.11 04:35, schrieb John Fallows:

Devs,

Now that PCL has landed in trunk, I'd like to discuss some alternatives in
how we might prefer to expose the feature.

plugin
 groupIdorg.apache.npanday.plugins/groupId
 artifactIdmaven-compile-plugin/artifactId
 extensionstrue/extensions
 configuration
 profilePORTABLE/profile
 frameworkVersionv4.0/frameworkVersion
 
frameworkName.NETPortable,Version=v4.0,Profile=Profile2/frameworkName

 frameworkDisplayNamePortable Library/frameworkDisplayName
 /configuration

/plugin

It turns out that the obscurely named Profile2 in the example from
NPANDAY-450 actually has system-defined meaning and is not a byproduct of
internal VS2010 internal project-specific naming as previously thought.

As you can see from the directory listings below, the various profiles have
meaning; Profile1, Profile2, Profile3, Profile4 - in terms of which specific
combinations of platforms are supported.  This is because some of the DLLs
used to resolve APIs during compilation are not actually present on all
platforms. (!)

*Directory of c:\Program Files\Reference
Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile1\SupportedFrameworks
*06/02/2011  09:18 PM   254
.NETFramework,Version=v4.0+,Profile=All.xml
06/02/2011  09:18 PM   271
Silverlight,Version=v4.0+,Profile=WindowsPhone.xml
06/02/2011  09:18 PM   252 Silverlight,Version=v4.0+.xml
06/02/2011  09:18 PM   199 Xbox,Version=v4.0+,Profile=All.xml

*Directory of c:\Program Files\Reference
Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile2\SupportedFrameworks
*06/02/2011  09:18 PM   254
.NETFramework,Version=v4.0+,Profile=All.xml
06/02/2011  09:18 PM   271
Silverlight,Version=v4.0+,Profile=WindowsPhone.xml
06/02/2011  09:18 PM   252 Silverlight,Version=v4.0+.xml

*Directory of c:\Program Files\Reference
Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile3\SupportedFrameworks
*06/02/2011  09:18 PM   254
.NETFramework,Version=v4.0+,Profile=All.xml
06/02/2011  09:18 PM   252 Silverlight,Version=v4.0+.xml

*Directory of c:\Program Files\Reference
Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile4\SupportedFrameworks
*06/02/2011  09:18 PM   271
Silverlight,Version=v4.0+,Profile=WindowsPhone.xml
06/02/2011  09:18 PM   252 Silverlight,Version=v4.0+.xml

Therefore, it would seem appropriate to use theprofile  configuration in
the compile plugin to select the corresponding combination of libraries so
that unsupported APIs would not be undesirably exposed during compilation
with NPanday.

For example:

plugin
 groupIdorg.apache.npanday.plugins/groupId
 artifactIdmaven-compile-plugin/artifactId
 extensionstrue/extensions
 configuration
 profile.NETPortable;Profile2/profile

 frameworkVersionv4.0/frameworkVersion

 /configuration

/plugin

Using the more specificprofile  name will allow us to precisely control
which libraries are needed during compile time.

Taking this approach would move responsibility of the
TargetFrameworkAttribute value to the compiler-plugins.xml file, to obtain
the value of .NETPortable,Version=v4.0,Profile=Profile2 to be used when
generating the assembly attributes, rather than taking it from the
frameworkName mojo property as it is today.  Further, we could make the
target framework display name such as Portable Library defined by
compiler-plugins.xml
as well, eliminating the frameworkDisplayName from the compiler mojo.

What do you think?

tc,
-john.

Codeplex update

2011-05-26 Thread Lars Corneliussen


Hi,

I updated the codeplex page.

Added the 1.4.0-incubating release including the urls to Apache Incubator.
http://npanday.codeplex.com/releases/view/67075

I also changed the Home and Documentation pages, to make the move even 
more clear.


http://npanday.codeplex.com/
http://npanday.codeplex.com/documentation

I'm now in the process of merging the documentation.

_
Lars

1.4.0-incubation Blog Post

2011-05-26 Thread Lars Corneliussen


For those that doesn't follow my blog:

http://startbigthinksmall.wordpress.com/2011/05/26/apache-npanday-1-4-0-incubating-released-net-for-maven/

Re: [ANNOUNCEMENT] Apache NPanday 1.4.0-incubating Released!

2011-05-16 Thread Lars Corneliussen

This is great!!! ;)

should we remove 1.3 from the download archive? 

http://archive.apache.org/dist/incubator/npanday/binaries/
--
Message sent from mobile device

Am 17.05.2011 um 04:59 schrieb Adelita Padilla apadi...@maestrodev.com:

 Hi Everyone,
 
 
 The NPanday development team is pleased to announce the release of Apache
 NPanday 1.4.0-incubating under the Apache Incubator.
 
 
 NPanday is a project to integrated Apache Maven into .NET development
 environments.  It includes both a Visual Studio add-in to integrated Maven,
 and a set of plugins for Maven that can build .NET projects uniformly from
 the command line.
 
 
 The latest release can be downloaded from
 http://incubator.apache.org/npanday/docs/1.4.0-incubating/download.html
 
 
 These are the major changes included in this release:
 
 * Visual Studio 2010 and .Net 4.0 Framework support
 * Removal of UAC and PAB directories
 * Updated groupIds of all NPanday components including plugins to
 org.apache.npanday
 
 For a complete list of all the features and fixes included in this release,
 please refer to
 http://incubator.apache.org/npanday/docs/1.4.0-incubating/release-notes.html
 
 
 If you have any questions, please consult:
 the website: http://incubator.apache.org/npanday/
 the npanday-user mailing list: npanday-us...@incubator.apache.org
 
 
 This is the first release of NPanday here in Apache.  Thanks to the NPanday
 and Apache Incubating community for helping grow the project.
 
 
 Enjoy!
 
 
 --
 
 liit

Re: [VOTE] NPanday-1.4.0-incubating

2011-05-06 Thread Lars Corneliussen


+1

- VS Addin installs and launches (not tested more)
- Repo contains everything needed (rest is downloaded from central).
- Most ITs pass (its-trunk).
- My sample projects pass :-)

Well done.

Integration Test Errors
http://pastie.org/1873091

Tests in error:

  test(npanday.its.NPANDAY_377_WithCustomNPandaySettingsFileTest)
  test(npanday.its.NPANDAY_377_WithCustomNPandaySettingsDirectoryTest)
  - what could that be? both fail with 'The plugin 
'org.apache.npanday.plugins:maven-compile-plugin' does not exist or no valid 
version could be found

  testConflictingExtensions(npanday.its.NPANDAY_140_ConflictingExtensionsTest)
  - this never passed on my machine

  testLadderBuild(npanday.its.NPANDAY_268_TransitiveDependenciesTest)
  
testTransitiveDependenciesNotOnCompile(npanday.its.NPANDAY_268_TransitiveDependenciesTest)
  - seems to be a bug in the tests.  both fail with: The plugin 
'npanday.plugin:maven-compile-plugin' does not exist or no valid version could 
be found


Am 06.05.11 11:44, schrieb Adelita Padilla:

Hi NPanday Users,

I'm happy to announce that NPanday-1.4.0-incubating is available and ready
for your testing and voting.

You can start testing here:

Repository Builder:
http://vmbuild.apache.org/archiva/repository/staged-npanday/org/apache/npanday/npanday-repository-builder/1.4.0-incubating/

MS Installer:
http://vmbuild.apache.org/archiva/repository/staged-npanday/org/apache/npanday/npanday-installer/1.4.0-incubating/

Source:
http://vmbuild.apache.org/archiva/repository/staged-npanday/org/apache/npanday/npanday-project/1.4.0-incubating/

The docs for 1.4.0-incubating can also be found here
http://incubator.apache.org/npanday/docs/1.4.0-incubating/index.html

[] +1 1.4.0-incubating passes and is ready for release
[] 0 Don't care
[] -1 Objection and please state the reason why.


Thanks again for the hardworking people who contributed patches and filed
issues.


Cheers,

--

liit

Re: Different solutions for sources and tests

2011-05-02 Thread Lars Corneliussen

IMHO, everything should be refactored in to one solution. Just go ahead. 
I don't think this is intentional.


_
Lars

Am 02.05.11 11:57, schrieb Deng Ching:

Hi,

Currently, the sources and the tests are in different solutions. This makes
it harder to do refactoring -- if there are changes in the API, the tests
don't get updated and you'd have to explicitly update them. Was there a
reason why it was done like this and would there be any problems if they are
merged into one solution?

Thanks,
Deng

NPanday Conventions

2011-05-02 Thread Lars Corneliussen


Hi alltogether,

Just wan't to discuss some of the documented and undocumented conventions:

In the documentation file there already is a comment to keep in mind, 
when reading:


   ~~ TODO: set a title for identifiers, since there are other
   conventions. Adjust to simplify - one group for whole project,
   ~~ plus subgroup for plugins and one for visual studio. Take a note
   that some don't follow convention now and are
   ~~ retained for legacy reasons, but will be refactored away in future


1) Conventions for Group-IDs and Artifact IDs:

   *OLD: ** If the module does not contain children modules, the Group
   ID is the same as the artifact ID.
   *OLD:* * If a module contains children modules, the child module
   Group ID should either be equivalent to a pluralized
parent module Group ID or be a deriviative of the parent
   module Group ID.


Imho this doesn't make sense. As stated in the comment above we should 
change that to something like:


   NEW: Use the groupId to group a certain set of artifacts. If
   possible, do not use the same identifier for both the group and the
   artifact - this often leads to confusions. The Group-ID usually is
   lower case. In .NET-projects, the artifact id becomes the assembly
   name. This makes UpperCase more suitable for .NET artifact ids.


Also this doesn't make sense:

   *OLD: *The directory structure of the source directory (typically
   src/main/csharp) will follow the same pattern as the group ID.


It should be changed to:

   *NEW: *The directory structure of the source directory (typically
   src/main/csharp) will follow the same pattern as the root namespace
   of a project. This usually corresponds to both the artifactId and
   the assembly name.

2) Add SVN conventions
- Copy from and link to 
http://maven.apache.org/developers/conventions/svn.html


3) Add Source-code conventions
- Copy from and link to 
http://maven.apache.org/developers/committer-environment.html


Any other suggestions?

_
Lars

Re: Is this a different transitive dependency issue from NPANDAY-412?

2011-05-02 Thread Lars Corneliussen

Any project that want's to resolve references (transitive or not) need 
the compile-plugin as extension in order to map from packaging to file 
extension... dotnet-library - dll, dotnet-executable - exe


Workarround: Instead of specifying the packaging, you can also specify 
the file extension as type in dependencies. This should work without 
the compile-plugin, too. But it is not really a nice way.


Sorry for hinting here again, but how can we get beyond NPANDAY-412? It 
is one of the last issues to be resolved for 1.3.1-incubating.


Am 02.05.11 22:25, schrieb John Fallows:

When a non-NPanday project (in an independent Maven execution) depends on a
dotnet-executable, and tries to resolve transitive dependencies for that
project, such as dotnet-library, the build breaks for the non-NPanday
project because it fails to resolve the transitive dotnet-library
dependency.

The original dependency was not for the dotnet-executable itself, but for a
separate classifier on that project, so the NPanday plugin was not necessary
in the non-NPanday project to resolve the immediate dependency.  However, in
order to avoid the breakage when attempting to resolve the dotnet-library
transitive dependency, we had to add in the NPanday plugin as an extension
in the non-NPanday project.

Is this an expected requirement?  Is it specific to NPanday, or a general
requirement for Maven?

One could imagine there being enough information in the dotnet-executable
pom to alleviate the need for specifying the NPanday extension plugin again
in the non-NPanday project to resolve the transitive dotnet-library
dependency.

tc,
-john.

Status for 1.3.1-incubating

2011-05-01 Thread Lars Corneliussen


Hi,

we have 6 open issues, still.

123 needs attention. Who has a old machine to test it on? We could 
also release RC, and have it tested there.

- 412 relates to this, too

377 is in progress. Should be resolved tomorrow.

383, who can rename the group ids?

403 successful generation of poms after clicking on Cancel button, 
*Unassigned*, reported by Liit

Liit, what is to be done to resolve this issue?

412 Execuable path for Windows 7 SDK is not auto-detected when 
npanday-settings.xml is generated, resgen.exe not found

John, I need input from you here.

398 MojoGenerator can't generate .NET-Mojos referencing a newer 
NPanday.Plugin.dll

Joe, you wanted to take care of this. What is the status?


_
Lars

Hi,

we have only six todos left:

383 groupid to org.apache.npanday, *unassigned*, reported by liit
377 hardcoded path in registry-config.xml, *liit*
387 Improve checking of mirror repos, *Unassigned*, reported by Joe
389 MojoGenerator can't generate .NET-Mojos referencing a newer 
NPanday.Plugin.dll, *Joe*, reported by Lars
403 successful generation of poms after clicking on Cancel button, 
*Unassigned*, reported by Liit

123 building without path, *Brett* (testing and fixes?)

1) When should we do 383? After code/feature freeze as part of 
release preparation?

2) Who will take care of 403?
3) Which dates should we target for code/feature freeze? I'd suggest 
Apr. 27th - one week from now.
4) Who will take care of the release preparations? What date should we 
target for the first RC? I'd suggest April 29th or May 2nd.


_
Lars

Re: svn commit: r1098424 - in /incubator/npanday/trunk: components/dotnet-vendor/src/main/java/npanday/vendor/ components/dotnet-vendor/src/main/java/npanday/vendor/impl/ plugins/netplugins/NPanday.Pl

2011-05-01 Thread Lars Corneliussen



--
Message sent from mobile device

Am 02.05.2011 um 03:39 schrieb Brett Porter br...@apache.org:

 
 On 02/05/2011, at 8:19 AM, lcornelius...@apache.org wrote:
 
 Modified: 
 incubator/npanday/trunk/components/dotnet-vendor/src/main/java/npanday/vendor/SettingsUtil.java
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/trunk/components/dotnet-vendor/src/main/java/npanday/vendor/SettingsUtil.java?rev=1098424r1=1098423r2=1098424view=diff
 ==
 --- 
 incubator/npanday/trunk/components/dotnet-vendor/src/main/java/npanday/vendor/SettingsUtil.java
  (original)
 +++ 
 incubator/npanday/trunk/components/dotnet-vendor/src/main/java/npanday/vendor/SettingsUtil.java
  Sun May  1 22:19:50 2011
 @@ -35,7 +35,7 @@ import java.util.Hashtable;
 public class SettingsUtil
 {
/**
 - * Return the registered settings, or create from default settings file 
 location (.m2/npanday-settings.xml)
 + * Return the registered settings, or create from configured 
 (-Dnpanday-settings=...) or default settings file location 
 (.m2/npanday-settings.xml)
 * @param repositoryRegistry The registry.
 * @return The current, or just created SettingsRepository
 * @throws SettingsException If anything goes wrong reading or 
 registering the settings
 @@ -43,7 +43,13 @@ public class SettingsUtil
public static SettingsRepository getOrPopulateSettingsRepository( 
 RepositoryRegistry repositoryRegistry)
throws SettingsException
{
 -  return getOrPopulateSettingsRepository(repositoryRegistry, 
 PathUtil.getHomeM2Folder());
 +String settingsFolder = PathUtil.getHomeM2Folder();
 +String customFolder = System.getProperty( npanday.settings );
 +if (customFolder != null  customFolder != )
 
 This won't necessarily work, as string comparisons aren't native. You want 
 !.equals(customFolder), or use something like !StringUtils.isEmpty for the 
 whole line.

i'll fix that. 

 
 +{
 +settingsFolder = customFolder;
 +}
 +return getOrPopulateSettingsRepository(repositoryRegistry, 
 settingsFolder );
}
 
/**
 
 
 Modified: 
 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/src/main/csharp/NPanday/Plugin/Settings/PathUtil.cs
 URL: 
 http://svn.apache.org/viewvc/incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/src/main/csharp/NPanday/Plugin/Settings/PathUtil.cs?rev=1098424r1=1098423r2=1098424view=diff
 ==
 --- 
 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/src/main/csharp/NPanday/Plugin/Settings/PathUtil.cs
  (original)
 +++ 
 incubator/npanday/trunk/plugins/netplugins/NPanday.Plugin.Settings/src/main/csharp/NPanday/Plugin/Settings/PathUtil.cs
  Sun May  1 22:19:50 2011
 @@ -17,12 +17,29 @@
 // under the License.
 //
 
 +using System;
 using System.IO;
 
 namespace NPanday.Plugin.Settings
 {
 +// TODO: Move this to common PathUtil, when NPANDAY-422 is fixed
public static class PathUtil
{
 +public static string GetHomeM2Folder()
 +{
 +return Environment.GetEnvironmentVariable(USERPROFILE) + 
 /.m2;
 +}
 +
 +public static string BuildSettingsFilePath( string 
 settingsPathOrFile )
 +{
 +if (settingsPathOrFile.EndsWith( xml ))
 +{
 +return settingsPathOrFile;
 +}
 
 Same comment as before - this would be more robust if there was a way to 
 check isDirectory or isFile instead.
when it doesn't exist, we still need to determine if it is a file or a 
directory. This might also have been liits thoughts when reqiring a dir, 
instead of a file - because npanday both writes, reads and overwrites the file. 
 

 
 - Brett
 
 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter

Re: Welcome John Fallows as new Committer for NPanday

2011-04-20 Thread Lars Corneliussen


Herzlich Willkommen John! - I'd say in German :-)

Happy to see npanday grow.

Cheers,
Lars

Am 20.04.11 09:30, schrieb Josimpson Ocaba:

Hi Everyone,

I'm very happy to welcome John as a new committer for NPanday, he has been
active in the community for some time now and has been regularly
contributing patches, discussions, and ideas on how to grow NPanday.

We hope to see more people become committers soon! Thanks again John for all
your hard work!

Cheers!

Joe

Get the release out the door

2011-04-20 Thread Lars Corneliussen


Hi,

we have only six todos left:

383 groupid to org.apache.npanday, *unassigned*, reported by liit
377 hardcoded path in registry-config.xml, *liit*
387 Improve checking of mirror repos, *Unassigned*, reported by Joe
389 MojoGenerator can't generate .NET-Mojos referencing a newer 
NPanday.Plugin.dll, *Joe*, reported by Lars
403 successful generation of poms after clicking on Cancel button, 
*Unassigned*, reported by Liit

123 building without path, *Brett* (testing and fixes?)

1) When should we do 383? After code/feature freeze as part of release 
preparation?

2) Who will take care of 403?
3) Which dates should we target for code/feature freeze? I'd suggest 
Apr. 27th - one week from now.
4) Who will take care of the release preparations? What date should we 
target for the first RC? I'd suggest April 29th or May 2nd.


_
Lars

Re: Test Failures

2011-04-18 Thread Lars Corneliussen

That is a regression. I tried to catch Command line to long for cmd.exe. This 
test should only run on windows. 

Brett, do we support categories by os?

--
Message sent from mobile device

Am 18.04.2011 um 15:47 schrieb Matthias Wessendorf mat...@apache.org:

 Hi,
 
 in my previous email, I reported to JUnit test failures.
 
 One I corrected already ([1]) - The patch contains a bit of documentation.
 (as stated in the bug - I am surprised that on Linux the return-code
 is 1 as well for 'command not found')
 
 The second failure:
 
 testTooLongCommandName_withSpace(npanday.executable.CommandExecutorTest)
 
 generates something like:
 /bin/bash -c echo x.
 
 Not sure I get why you are expecting a test failure here.
 
 Thanks!
 Matthias
 
 [1] https://issues.apache.org/jira/browse/NPANDAY-407
 
 -- 
 Matthias Wessendorf
 
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

Re: other old commits

2011-04-12 Thread Lars Corneliussen


Am 12.04.11 04:45, schrieb Brett Porter:
  
  Modified: incubator/npanday/trunk/dotnet/assemblies/NPanday.Plugin.MojoGenerator/src/main/csharp/NPanday/Plugin/MojoGenerator/Generator.cs

  
URL:http://svn.apache.org/viewvc/incubator/npanday/trunk/dotnet/assemblies/NPanday.Plugin.MojoGenerator/src/main/csharp/NPanday/Plugin/MojoGenerator/Generator.cs?rev=1025511r1=1025510r2=1025511view=diff
  
==
  --- 
incubator/npanday/trunk/dotnet/assemblies/NPanday.Plugin.MojoGenerator/src/main/csharp/NPanday/Plugin/MojoGenerator/Generator.cs
 (original)
  +++ 
incubator/npanday/trunk/dotnet/assemblies/NPanday.Plugin.MojoGenerator/src/main/csharp/NPanday/Plugin/MojoGenerator/Generator.cs
 Wed Oct 20 11:37:11 2010
  @@ -100,11 +100,9 @@ namespace NPanday.Plugin.MojoGenerator
jcuLocal.unmarshall(javaClass, fileInfo);
}

  - ResourceManager resourceManager = new 
ResourceManager(NPanday.Plugin.MojoGenerator,
  -   
Assembly.GetExecutingAssembly());
  - String pomXml = (String) 
resourceManager.GetObject(pom-java.xml);
  - TextReader reader = new StringReader(pomXml);
  - XmlSerializer serializer = new 
XmlSerializer(typeof(NPanday.Model.Pom.Model));
  +TextReader reader = new 
StreamReader(Assembly.GetExecutingAssembly().
  +
GetManifestResourceStream(Assembly.GetExecutingAssembly().GetManifestResourceNames()[0]));
  + XmlSerializer serializer = new 
XmlSerializer(typeof(NPanday.Model.Pom.Model));
NPanday.Model.Pom.Model model = 
(NPanday.Model.Pom.Model) serializer.Deserialize(reader);   
model.artifactId = artifactId + .JavaBinding;
model.groupId = groupId;
  
  I'm not sure I understand this change. Is it reading the POM as the first resource from an asembly?
  
I also stumbled over that change and filed a bug. Didn't know it was 
introduced lately:



   JavaBindings-Generator for .NET-Mojos is fragile (and not working
   for NPanday.Plugin.SettingsGenerator)
   https://issues.apache.org/jira/browse/NPANDAY-385


https://issues.apache.org/jira/browse/NPANDAY-385

Re: NPanday 1.3.1-incubating Branched from a certain revison from Trunk

2011-04-06 Thread Lars Corneliussen


Hi Joe,

I found out, that NPanday can still be built on Maven 2.2.1 (didn't try 
below). So this should be ok.
We could just release what we have now as 1.4-incubating - it is 
certainly better than 1.3-incubating was.


The PATH issue should be good. And documentation I can stop at any time :-)

Liit should have a look at the last open issue, and then we go for a 
fast release.


_
Lars



Am 06.04.11 10:02, schrieb Josimpson Ocaba:

Hi Everyone,

With the many changes in our trunk recently I feel that this is too much for
a point release and could fall into a 1.4-incubating release in itself.
Having NPanday being built on Maven 3.x is also a major change for me. So
what do you guys think if we branch out from a certain revision and release
that as 1.3.1-incubating instead? Of course we will make sure that the
revision will be stable.

With this branch out we can also lessen the time for preparation for the
release instead of stabilizing the issues that are in trunk. I'm very much
biased on getting a 1.3.1-incubating ASAP :D


What do the others think?


Cheers,

Joe

Documentation TOC/Navigation cleanup...

2011-04-06 Thread Lars Corneliussen



  
  
Hi,

for me it is hard to even find the stuff I documented myself.
This is why I made some changes to the styles (for better
readability) and updated the Navigation.

This is what it looks like here now. What do you think?

Re: Documentation TOC/Navigation cleanup...

2011-04-06 Thread Lars Corneliussen

 On Thu, Apr 7, 2011 at 8:13 AM, Josimpson Ocaba joc...@maestrodev.com wrote:
 I have a question on ALM, can we replace it with something that a new user
 can easily understand? I'm sorry I also don't have anything in mind that
 could replace it but maybe we can brainstorm something.
 
 Or.. maybe the ALM section can just be removed then move Release and
 Version Management inside Developer's Guide and Artifact
 Repositories and Automated Builds under Get Involved?

 
Don't think it belongs there. Both have very little to do with NPanday and 
would just get in the way when somebody wants to learn NPanday. 

Maybe renaming it to Application Lifecycle Management helps. 

Or Beyond Building. 

Maven Ecosystem

Maven Ecosystem Beyond Building

I think Application Lifecycle Management is still the best of these choices. 
Beyond building sounds good, too.

NPanday Repo down...

2011-04-01 Thread Lars Corneliussen

http://repo.npanday.org/archiva/repository/npanday-group/ seems to be 
down (again).



 Service Temporarily Unavailable

The server is temporarily unable to service your request due to 
maintenance downtime or capacity problems. Please try again later.



Apache/2.2.3 (CentOS) Server at repo.npanday.org Port 80

Re: Finding a date for NPanday 1.3.1 Finalizing Meetup

2011-03-31 Thread Lars Corneliussen

See y'all in about 16 hours, then. 8:00 Friday for me. Second option on doodle. 

--
Message sent from mobile device

Am 30.03.2011 um 09:28 schrieb Lars Corneliussen m...@lcorneliussen.de:

 Hi,
 
 I created a doodle. Please add your name and check where you have time 
 available.
 
 You can adjust to your timezone in the upper right corner.
 
 
   NPanday 1.3.1 Finalizing Meetup
 
 http://www.doodle.com/r8f5x2pzvdhye3wf
 
 _
 Lars

Re: Weird dependency resolving issues

2011-03-31 Thread Lars Corneliussen

ok. then we have to fix that for 1.3.1 :)

--
Message sent from mobile device

Am 01.04.2011 um 07:25 schrieb Josimpson Ocaba joc...@maestrodev.com:

 Yes, the actual dll were also deployed because when building npanday and
 trying to resolve the dependencies it is looking for a .dll from the remote
 repository.
 
 As what Adelita mentioned if those dependencies are not yet installed it
 what cause a failure :(

Re: Set up Continuous Integration for NPanday

2011-03-30 Thread Lars Corneliussen


Hi,

we had a discussion on that a while ago:
http://mail-archives.apache.org/mod_mbox/incubator-npanday-dev/201101.mbox/%3c4d353360.70...@lcorneliussen.de%3E

I think brett planned to work on getting continuum back working. Last 
execution over there was March 14th and it failed.

http://ci.npanday.org/continuum/projectGroupSummary.action?projectGroupId=16

Brett?

PD: No te abrumes. Casi todos aqui hablan el ingles como lengua 
extranjera :-)


-
Lars



Am 30.03.11 00:33, schrieb Javier Mandiola:

Hi Lars,

Which CI Build Server do you want to use? Hudson, CruiseControl or
Continnium?

I have experience with Hudson, but I have little knowledge of maven, I'm
learning recently

PD:sorry for my english but my native language is Spanish

Regards

On Tue, Mar 29, 2011 at 5:43 PM, Lars Corneliussenm...@lcorneliussen.dewrote:


How is the state here? Would be great to have that setup ASAP - as I'm
trying to aquire new developers :-)

-
Lars

Finding a date for NPanday 1.3.1 Finalizing Meetup

2011-03-30 Thread Lars Corneliussen


Hi,

I created a doodle. Please add your name and check where you have time 
available.


You can adjust to your timezone in the upper right corner.


   NPanday 1.3.1 Finalizing Meetup

http://www.doodle.com/r8f5x2pzvdhye3wf

_
Lars

Re: Set up Continuous Integration for NPanday

2011-03-30 Thread Lars Corneliussen


1) some still fail
2) will it build on commit?

Am 30.03.11 15:29, schrieb Brett Porter:

On 30/03/2011, at 5:54 PM, Lars Corneliussen wrote:


Hi,

we had a discussion on that a while ago:
http://mail-archives.apache.org/mod_mbox/incubator-npanday-dev/201101.mbox/%3c4d353360.70...@lcorneliussen.de%3E

I think brett planned to work on getting continuum back working. Last execution 
over there was March 14th and it failed.
http://ci.npanday.org/continuum/projectGroupSummary.action?projectGroupId=16

It got tripped on the initial version change and some server misconfigurations. 
With moving to Apache's Jenkins instance on the cards, some of these things 
haven't been fixed.

That should be ready now if someone wants to proceed - I think Joe filed the 
initial ticket and was working on it.

In the mean time, I am building it again on ci.npanday.org now.

- Brett

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter

Bootstrapping NPanday

2011-03-29 Thread Lars Corneliussen


Hi again,

when you first build with the new settings, do the following:

1) Build trunk using mvn 2.x and NPanday 1.3-incubating
2) Delete npanday-settings.xml
3) Run any integration test against NPanday 1.3.1-incubating (joe should 
have switched the trunk version) in order to create a fresh one

4) Remove (almost) everything .NET-related from the PATH
5) Just keep Nunit-binaries on the PATH :-)
6) Switch to Maven 3
7) Change the root pom to

stable.npanday.version${project.version}/stable.npanday.version
!--stable.npanday.version1.2.1/stable.npanday.version--


8) Build with mvn clean install

As an alternative to 1) and 3) you can do the switch, and then run the 
first build with in a Visual Studio Prompt.


Who could run the integration tests and find, if there are any more 
issues here?


-
Lars

Set up Continuous Integration for NPanday

2011-03-29 Thread Lars Corneliussen

How is the state here? Would be great to have that setup ASAP - as I'm 
trying to aquire new developers :-)


-
Lars

Building NPanday using newest NPanday and Maven 3


Hi,

I really find it an obstacle to build NPanday trunk itself with an old 
NPanday version. It feels like stone age :) But sadly, due to a bug in 
MVN 2.2.1, it is not possible to use plugin-versions that just built 
within the same reactor.


So i suggest to move on to Maven 3.0.x for building NPanday trunk.

Suggestion:

1) Bootstrapping NPanday with current NPanday. (not possible on MVN 2.2.x)
2) Require Maven = 3 for *building* NPanday = 1.3.1

We should still make sure, that NPanday does work with Maven 2.2.x, though.

Integration tests should run both in Maven 2.2.1 and Maven 3.0.2 or 3.0.3

*TODO:*
* Add a Jira-Issue
* change npanday.stable.version to npanday.bootstrap.version
* preconfigure npanday.bootstrap.version with ${project.version}
* update docs
* remove all .NET-PATHes from the PATH environment
* remove most of the PATH-related docs

*Helpers on Windows for rapid switching of maven versions:*

*mvn3.bat* (somewhere on the PATH)
set M2=C:\Program Files\Apache\apache-maven-3.0.2\bin
set M2_HOME=C:\Program Files\Apache\apache-maven-3.0.2
set PATH=C:\Program Files\Apache\apache-maven-3.0.2\bin;%PATH%
mvn --version

*mvn2.bat* (somewhere on the PATH)
set M2=C:\Program Files\Apache\apache-maven-2.2.1\bin
set M2_HOME=C:\Program Files\Apache\apache-maven-2.2.1
set PATH=C:\Program Files\Apache\apache-maven-2.2.1\bin;%PATH%
mvn --version

Moving on to .NET 3.5 for NPanday C#-Sources


Hi again,

since .NET 3.5 targets CLR 2.0, it would not change anything for our 
users when we move on to .NET 3.5 for NPanday trunk.

All of us have 3.5 installed anyway, right?

Is a vote appropriate for such questions?

lg,
Lars

Re: Building NPanday using newest NPanday and Maven 3


What do the others think? Vote necessary?

Am 28.03.11 16:51, schrieb Brett Porter:

Definitely helpful in trying to ship a self-contained release.

On 28/03/2011, at 5:30 PM, Lars Corneliussen wrote:


Hi,

I really find it an obstacle to build NPanday trunk itself with an old NPanday 
version. It feels like stone age :) But sadly, due to a bug in MVN 2.2.1, it is 
not possible to use plugin-versions that just built within the same reactor.

So i suggest to move on to Maven 3.0.x for building NPanday trunk.

Suggestion:

1) Bootstrapping NPanday with current NPanday. (not possible on MVN 2.2.x)
2) Require Maven= 3 for *building* NPanday= 1.3.1

We should still make sure, that NPanday does work with Maven 2.2.x, though.

Integration tests should run both in Maven 2.2.1 and Maven 3.0.2 or 3.0.3

*TODO:*
* Add a Jira-Issue
* change npanday.stable.version to npanday.bootstrap.version
* preconfigure npanday.bootstrap.version with ${project.version}
* update docs
* remove all .NET-PATHes from the PATH environment
* remove most of the PATH-related docs

*Helpers on Windows for rapid switching of maven versions:*

*mvn3.bat* (somewhere on the PATH)
set M2=C:\Program Files\Apache\apache-maven-3.0.2\bin
set M2_HOME=C:\Program Files\Apache\apache-maven-3.0.2
set PATH=C:\Program Files\Apache\apache-maven-3.0.2\bin;%PATH%
mvn --version

*mvn2.bat* (somewhere on the PATH)
set M2=C:\Program Files\Apache\apache-maven-2.2.1\bin
set M2_HOME=C:\Program Files\Apache\apache-maven-2.2.1
set PATH=C:\Program Files\Apache\apache-maven-2.2.1\bin;%PATH%
mvn --version


--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter

Re: Moving on to .NET 3.5 for NPanday C#-Sources


Am 28.03.11 17:01, schrieb Brett Porter:

On 28/03/2011, at 5:33 PM, Lars Corneliussen wrote:


Hi again,

since .NET 3.5 targets CLR 2.0, it would not change anything for our users when 
we move on to .NET 3.5 for NPanday trunk.
All of us have 3.5 installed anyway, right?

yup, as long as testing that it runs inside VS 2005 still exists (or we decide 
explicitly not to support that any more).

It should. But maybe users would have to install .NET Fx 3.5 - when we 
reference System.Core. Does somebody have a clean machine with VS2005 
only on?

Is a vote appropriate for such questions?

Not really necessary unless something is very hard to gain consensus on. Otherwise, 
voting is best kept for releases  committers where there is a binary decision 
to be made.

- Brett

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter

Re: Weird dependency resolving issues