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. Chris ________________________________________ Von: Brett Porter [br...@porterclan.net] im Auftrag von Brett Porter [br...@apache.org] Gesendet: Mittwoch, 13. November 2013 08:12 An: npanday-dev@incubator.apache.org Betreff: Re: Building NPanday Hi Chris, On 12 Nov 2013, at 8:21 pm, christofer.d...@c-ware.de wrote: > 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 Currently we have a "bootstrap" script which runs mvn with a --projects list, up until the right plugin is available, then lets you run the full one. Is there something we can do to make that clearer? Ideally, with a more recent release available, the default build could just depend on a previous version of the plugins. > > 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. That's good - did you find these artifacts in the central repo, or in the repo in the top level POM? It's been our objective to remove RDF for some time, but it's not completely happened yet. > > 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". Thanks again for your help. The integration tests may be a bit of a tough one - though it's just a few changes some of them are rather "deep" in the code. There was some discussion on this list about it a while ago - I'm happy to give some pointers when you get to this. Cheers, Brett -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
