AW: Building NPanday
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 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
AW: Building NPanday
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
AW: Building NPanday
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 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
AW: Building NPanday
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
AW: Building NPanday
Hi, Ok ... to some of the problems I was having wih the testsuite ... so there seems to be major differences between 32bit and 64bit builds. I am running my Java Stuff and my IDE on a 64bit system. Therefore the PROGRAMFILES will always point to C:\Program Files making the tests look for C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web. Unfortunately NPanday should look in C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web instead. I was able to make the integration-tests find the resources by forcefully switching to a 32bit Java VM. I guess somehow using the maven-enforcer-plugin to fail on 64bit system immediately should help people like me not wasting too much time ;-) (http://maven.apache.org/enforcer/enforcer-rules/requireOS.html) Chris -Ursprüngliche Nachricht- Von: christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de] Gesendet: Mittwoch, 13. November 2013 20:43 An: npanday-dev@incubator.apache.org Betreff: AW: Building NPanday 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
AW: Building NPanday
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. Chris Von: Brett Porter [br...@porterclan.net] im Auftrag von Brett Porter [br...@apache.org] Gesendet: Mittwoch, 13. November 2013 08:12 An: npanday-dev@incubator.apache.org Betreff: Re: Building NPanday Hi Chris, On 12 Nov 2013, at 8:21 pm, christofer.d...@c-ware.de wrote: Hi, so I had a look at building NPanday. It was quite a hastle getting the build to run, but in the end I seem to have gotten it working. I would however suggest to modify the build slightly. There is one Problem in every plugin Project: You Need the plugin itself somewhere in the build of the rest of the plugins suilte. Unfortunately Maven doesn't respect plugins when building the reactor order of the modules and you usually get Errors about the plugin not being available in any repo ... of course ... it hasn't been built yet. The solution is usually to provide a minimal maven Profile that builds only the plugin as well as the dependencies of the plugin. So a full build from scratch usually Looks like this: mvn clean install -Pminimal mvn clean install Currently we have a bootstrap script which runs mvn with a --projects list, up until the right plugin is available, then lets you run the full one. Is there something we can do to make that clearer? Ideally, with a more recent release available, the default build could just depend on a previous version of the plugins. Additionally I changed the Version of the openrdf dependencies in the module dotnet-registry to 2.0.1 and added two missing deps to openrdf-model and openrdf-sail-api ... after this the whole build worked like a charm. That's good - did you find these artifacts in the central repo, or in the repo in the top level POM? It's been our objective to remove RDF for some time, but it's not completely happened yet. I guess I will fine-tune my modifications and post a patch here in the next few days ... my next step will be getting the Integration-tests to run. Hopefully this will not be such a Monster Task as it was with another Project I worked on Flexmojos. Thanks again for your help. The integration tests may be a bit of a tough one - though it's just a few changes some of them are rather deep in the code. There was some discussion on this list about it a while ago - I'm happy to give some pointers when you get to this. Cheers, Brett -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
