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 [email protected]: > 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 wouldn't have to install > the libs, but just reference them in his build. > > Is that a Little more clear that way? > > Chris > > ________________________________________ > Von: Lars Corneliussen [[email protected]] > Gesendet: Dienstag, 26. November 2013 07:17 > An: [email protected] > Betreff: Re: Building NPanday > > do still not really understand… > what libs are you talking about? nunit, ++? adana-repo? ... > > Am 22.11.2013 um 11:42 schrieb [email protected]: > >> 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 [[email protected]] >> Gesendet: Freitag, 22. November 2013 10:24 >> An: [email protected] >> 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 "[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
