I would like to fix this for you. I can workaround it, but fact is, maven is used incorrectly in jbehave. There is no reason to have the profiles defining repos in settings.xml when it belongs to pom.xml. Here is the pull request: https://github.com/jbehave/jbehave-core/pull/53
It moves what belongs to pom.xml to pom.xml, and leaves what belong to setting.xml in settings.xml, in particular the pluginGroups can only be defined inthere. The change is absolutely compatible with current behavior, practices and documentation. Cheers, Gabor 2013.08.12. 16:38, "Cristiano Gavião" <cvgav...@gmail.com> ezt írta: > You are the first to complain about this in years... > > so just copy the profiles in the provided setting.xml into yours and just > run the maven install... > > On 12/08/13 11:34, Czigola Gábor wrote: > > That's precisely the problem. You force devs to use jbehave's settings.xml > so thus skipping their existing settings.xml in that proper proxy settings > reside mostly. > > As quoted from the maven guide settings.xml should not be boundled with > any source tree. It is meant for workstation specific settings. All the > declarations in jbehave-core/settings.xml belong to jbehave-core/pom.xml > imho. > 2013.08.12. 16:27, "Cristiano Gavião" <cvgav...@gmail.com> ezt írta: > >> not all dependencies of JBehave are in maven central repository. maven >> provides us two ways to work with multiple repositories. >> >> we decided not to put the needed repositories inside the pom so it is >> the reason we use the settings.xml. and add it to the git just to provide >> the developers an easy way to set the build. >> >> so to build JBehave you just need do: >> >> mvn install -s settings.xml >> >> >> >> 2013/8/12 Gabor Czigola <gabor.czig...@gmail.com> >> >>> Started working on jbehave-core codebase and wonder why there is a >>> settings.xml boundled in the source tree? >>> >>> The purpose of settings.xml is to specify workspace specific mvn >>> settings, according to maven.jbehave.org/settings.html it "should not >>> be boundled to any specific project" for a good reason: people specify for >>> example local proxy and repo settings. By forcing this particular >>> settings.xml you doom everyone requiring specific settings. >>> >>> I don't see any reason why the definitions in settings.xml are not in >>> pom.xml actually? They do belong there, don't they? >>> >> >> >> >> -- >> "Tudo vale a pena se a alma não é pequena..." >> > >
