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

Reply via email to