On Mar 15, 2007, at 2:38 AM, Kenney Westerhof wrote:
Jason Dillon wrote:
How does a test repository help? I still need to configure in my
src/it/*/pom.xml the version of the plugin I'm testing.
The latest plugin will be used, which is usually what you're testing.
If the test repository does not contain other versions of the plugin,
the one you're testing will be used.
Yes, I know... *BUT* that means the current version must be
configured in the src/it/* poms... which I do not want to have to
maintain/update. And when there is no artifact for that version
already in the repo then execution of src/it will fail when executed
from the integration-test phase.
Maybe I don't understand what you mean by "test repositories".
It's basically -Dmaven.repo.local=/tmp/foo/ - an empty repository
only used for the build.
Right, that doesn't help solve any problem.
I just want my src/it/*/pom.xml to *always* use the right version
of the plugin (ie. that which was just compiled). I don't want to
have to go updating poms each time I make a new release to use the
new version.
This has nothing to do with versions, actually. See below.
See comment above... it has everything to do with versions. :-P
And even more important... the "install" phase happens *before*
the "integration-test" phase, so I still need a way to get the
artifacts into the repository before my integration-tests fire.
No, install happens AFTER the integration test phase.
Right, I mistyped that sorry.
Maven is very careful
not to make artifacts available that have failing tests.
If test fails, package won't run.
If integration-test fails (after package), install won't run.
Right... and I like that *feature* but to run integration tests my
plugin I need it to be in the repository so it will resolve...
Even if you were able to supply/override that testing version,
the tests will fail since the artifact is not yet in the local
repository.
If you run again (and have a previous testing version in the local
repo),
the version from the local repo will be tested, not the version in
target/.
Um... no... the build compiles stuff, then makes a jar, then installs
the artifact into the repo with a "testing" version for all its
artifacts, then runs integration-tests, where all child poms use
"testing" as the plugins version, if that passes, then the normal
install:install happens which puts the _real_ version into the repo,
else per-normal if the integration-tests failed, no _real_ version is
installed into the local repo.
The problem here is MNG-2677 (originally MNG-870): maven can't
resolve plugins
from the reactor.
Um... no... I agree MNG-2677 is a problem... and I'm still waiting
for that to get fixed for the Geronimo build... but that is *not* the
problem here. src/it/* tests are *not* run from the reactor, nor do
I want them to be run from the reactor.
I wrote the maven-it-plugin a while ago (at the time of writing
MNG-870),
which will run an embedded maven on src/it/*/pom.xml (which was
later turned
into the embedder). This embedded maven would recognize the just
built plugin
from the reactor, and not use the version from the local repository.
I'm using the maven-invoker-plugin and aside from this version issue
I'm really happy with it.
So even with proper versions you still have a problem, since
install is NOT run
before integration-test, and hence the plugin is NOT available in
the local
repository.
Um right... which is why forceVersion is needed here ;-)
If you can explain a better way to achieve the desired result I'm
all ears... but so far this is the only solution I can think of
which will work 100% of the time.
The proper way would be to explicitly run the tests against target/$
{artifact},
and not let it poms resolve it from the local or remote repositories.
Um... no... these are *integration tests* they are meant to test/
verify that integration with Maven works. And to do that, the
artifacts being tested need to get picked up/configured in the normal
way.
So, versions for plugins are not needed in src/it/*/pom.xml. And
even if you do
specify one, you can't be certain that the version matches the
artifact being
built, and even worse, you can't be certain the artifact just built
is being used.
Um... I don't get what you mean here at all... by using forceVersion,
running that in pre-integration-test, I can be 100% certain that the
code being tested *is* the code that was just built.
* * *
I'm happy to keep talking about this... and maybe I can convince you/
someone that this is the simplest solution... though I suppose at the
end of the day if the Maven dev team isn't interested in applying the
patch I made, I will be forced to make a new plugin to do the same
thing... which I'd like to avoid.
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
