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)
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. 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 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 [m...@lcorneliussen.de] > Gesendet: Dienstag, 26. November 2013 07:17 > An: npanday-dev@incubator.apache.org > 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 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 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
