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 "[email protected]" <[email protected]>: > 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 [[email protected]] > Gesendet: Dienstag, 3. Dezember 2013 20:07 > An: [email protected] > Betreff: Re: Building NPanday > > inline… > > Am 03.12.2013 um 12:22 schrieb "[email protected]" > <[email protected]>: > >> 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 [[email protected]] >> Gesendet: Montag, 2. Dezember 2013 22:29 >> An: [email protected] >> 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 [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
