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

Reply via email to