Brett Porter wrote:
(see r682889)
Ah, and I was already wondering why the Hudson bundle ever (almost)
worked for me back in July.
it then
doesn't honour the installation settings at all, since the value is set
by the ITs by reading settings.xml itself.
What use case had you in mind
On 19/09/2008, at 4:16 AM, Benjamin Bentmann wrote:
Brett Porter wrote:
(see r682889)
Ah, and I was already wondering why the Hudson bundle ever (almost)
worked for me back in July.
it then doesn't honour the installation settings at all, since the
value is set by the ITs by reading
Brett Porter wrote:
I really think that the entire suite should use a sandboxed local repository
I just changed the maven-verifier to propagate the local repo of the
test runner to the IT build by default. Since -D maven.repo.local is
dominant over the settings.xml, this captures those ITs
I think a problem I was having with this (see r682889) is that it then
doesn't honour the installation settings at all, since the value is
set by the ITs by reading settings.xml itself.
Not sure if that's really a big deal, as this is probably a more
valuable ability to have.
However
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
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
On Wed, Sep 17, 2008 at 9:07 AM, Brett Porter [EMAIL PROTECTED] wrote:
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
