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 "[email protected]" <[email protected]>: > 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 [[email protected]] > Gesendet: Donnerstag, 21. November 2013 11:07 > An: [email protected] > 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 "[email protected]" > <[email protected]>: > >> 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: [email protected] [mailto:[email protected]] >> Gesendet: Mittwoch, 13. November 2013 16:15 >> An: [email protected] >> Betreff: AW: Building NPanday >> >> Sure, >> >> I'll create an issue and attach a patch as soon as I'm home. >> >> Chris >> >> ________________________________________ >> Von: Brett Porter [[email protected]] im Auftrag von Brett Porter >> [[email protected]] >> Gesendet: Mittwoch, 13. November 2013 13:25 >> An: [email protected] >> Betreff: Re: Building NPanday >> >> On 13 Nov 2013, at 6:44 pm, [email protected] 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
