You are viewing a plain text version of this content. The canonical link for it is here.

Posted to npanday-dev@incubator.apache.org by "christofer.dutz@c-ware.de" <ch...@c-ware.de> on 2013/11/12 09:21:44 UTC

Building NPanday

Hi,

so I had a look at building NPanday. It was quite a hastle getting the build to run, but in the end I seem to have gotten it working. I would however suggest to modify the build slightly.

There is one Problem in every plugin Project: You Need the plugin itself somewhere in the build of the rest of the plugins suilte. Unfortunately Maven doesn't respect plugins when building the reactor order of the modules and you usually get Errors about the plugin not being available in any repo ... of course ... it hasn't been built yet.

The solution is usually to provide a "minimal" maven Profile that builds only the plugin as well as the dependencies of the plugin. So a full build from scratch usually Looks like this:
mvn clean install -Pminimal
mvn clean install

Additionally I changed the Version of the openrdf dependencies in the module dotnet-registry to 2.0.1 and added two missing deps to openrdf-model and openrdf-sail-api ... after this the whole build worked like a charm.

I guess I will fine-tune my modifications and post a patch here in the next few days ... my next step will be getting the Integration-tests to run. Hopefully this will not be such a Monster Task as it was with another Project I worked on "Flexmojos".

Chris

Re: Building NPanday

Posted by Brett Porter <br...@apache.org>.

On 14 Nov 2013, at 6:42 am, christofer.dutz@c-ware.de wrote:

> 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 ;-)

Glad to see it worked - can you point where the docs were wrong?

> 
> 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 :-)

It should skip these if the older ones are not installed - what was the issue? Newer SDKs are supported - though new SDKs still need to be listed in the Azure plugin (we have up to v2.0 in azure-maven-plugin/src/main/resources/META-INF/npanday/executable-plugins.xml). Would be good for the IT to accommodate all those options, where installed.

> - I have Visual Studio 2013 installed and some tests are skipped because of me not having 2010 installed.

I haven't tried 2013 yet, though I think they run with 2012. What were the tests?

> - Still there are 18 Test failing (It seems some tests are currently not running ... which ones are known not to run?)

It's down to these:

Failed tests:   testMsBuildWithProjectReferences(npanday.its.NPANDAY_459_MsBuildProjectReferencesTest): Expected file was not found: f:\hudson\hudson-slave\workspace\NPanday-it-runner\npanday-it-runner\target\test-classes\NPANDAY_459_MSBuildProjectReferences\ConsoleApplication1\.references\test\test-snapshot-1.0-SNAPSHOT\test-snapshot.dll
  testCompilerWithArgs(npanday.its.NPandayIT0038CompilerWithArgsTest): Found unexpected class It0002 in assembly f:\hudson\hudson-slave\workspace\NPanday-it-runner\npanday-it-runner\target\test-classes\NPandayIT0038CompilerWithArgsTest\target\NPandayITCompilerWithArgs.dll

Tests in error: 
  testClassLibWithWebRefInstall(npanday.its.NPandayIT0037ClassLibWithWebRefInstallTest): Exit code was non-zero: 1; command line and log = (..)

See: https://builds.apache.org/view/M-R/view/NPanday/job/NPanday-it-runner/org.apache.npanday$npanday-it-runner/398/testReport/
More details from earlier: http://mail-archives.apache.org/mod_mbox/incubator-npanday-dev/201209.mbox/%3C4F3B3F9F-2885-4E3F-9AB7-4761378FF466%40apache.org%3E

> 
> 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.

We use that for the wix plugin, but the others are across multiple things and use the same tools as the Maven integration tests. Happy for improvements to be made, but haven't previously found it worth the effort...

> 
> 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?

Definitely valuable (along the lines of what the nuget importer is angling towards). The addin actually does this to some extent, and has the advantage of being in C# so it can read the assembly information. That might be something to extract into a command line tool.

- Brett

--
Brett Porter   @brettporter
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter