Some of the ITs use an alternate settings.xml file which won't have a
local repo specified.
It's one of the things I added to the ITProblems list. I really think
that the entire suite should use a sandboxed local repository that is
prepopulated with required dependencies (but not downloaded on every
build as that would be too slow - rather copied from the executing
Maven's local repository).
- Brett
On 17/09/2008, at 4:37 AM, Benjamin Bentmann wrote:
Hi,
just for some fun, I executed
mvn clean install -D maven.repo.local=M:\it-repo
on core-integration-tests-support and right afterwards
mvn clean test -P run-its -D maven.repo.local=M:\it-repo
on core-integration-tests where "mvn" refers to Maven 2.0.9. After
some time it ended up with about 10 failures and 8 errors.
Many of the errors seem to be caused by the forked Maven invocations
picking up the wrong local repo. Some investigation led me to
Verifier.java:1007 where a property "use.mavenRepoLocal" is
evaluated to decide whether the current path to the local repo
should be passed on to the forked Maven invocation. I couldn't find
any code spot that would set this to true which would mean the tests
would never use the intended repo as specified on my command line
via maven.repo.local but rather my local repo (in case the test
doesn't use custom user settings) or the default local repo (in case
the test uses custom user settings). I indeed observed the creation
of "~/.m2/repository" although this is not my local repo, i.e. some
tests broke out the sandbox.
Since the ITs are working for others, I must be missing something.
Can somebody help?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
