Ok, we've got different approaches here. I'll line them out to summarize:
Mine:
- use an integration testing plugin like maven-it-plugin to run test projects
placed in src/it/*/pom.xml against the current artifact, which is not installed
in any repository yet.
- The embedder is fed the current artifact and the src/it/* projects in the
reactor,
where the current artifact is marked to be skipped during the build.
Note: the IT projects don't have to specify a <version> for any <plugin>
they're testing,
since the version tag is optional. If absent, the latest version will be used,
or the version from the reactor. MNG-1677 currently prevents maven from using
a plugin
from the reactor, though normal artifacts work.
Your approach:
- bind a modified install plugin to the pre-integration-test phase to install
the artifact with a different version in the local repository
- run the invoker plugin to fork maven to build src/it/*.pom, using the local
repository,
remote repositories etc (IMHO an uncontrolled environment).
If your approach works, go for it. Here are some other comments wrt. your
problems:
- use the install:install-file mojo; you can specify the path to the artifact
in target/
and the version you want to use - no need for a forceVersion parameter.
- if you hardcode the version to install ('testing') in the pom, i see no harm
in specifying that version in src/it/*/pom.xml aswell
- perhaps the staging mojo (can't remember which plugin) is of use; it
temporarily
installs the plugin in the local repository, backing up what's there;
after the integration test, it restores the local repository.
Jason Dillon wrote:
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.
Sure it does, it solves the problem you described above: having to specify
a version in the src/it/ poms. If there's only 1 version available in the
local repository (/tmp/foo), that one will be used. so you don't have to
specify the version.
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
See comment above. ;)
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...
With your approach, requiring the use of the local repo, yes. With
mine, no. ;)
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.
There are 2 reactors: the main build reactor, and the reactor created
by the maven-it-plugin which contains the artifact to test and the test
projects.
So then it _is_ a problem if you take that approach.
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.
Ok. You could also use the verifier (shared/maven-verifier). That one also
forks maven (or runs it embedded if you choose). We use it in the
core-integration-tests.
>>> 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.
They are, just not from the local repo but from a predefined path. I think
we've established that maven can run plugins from local and remote repositories
so you don't have to test that ;)
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.
It's one way to do it, yes, overwriting the existing plugin in the local
repository.
But if the integration test fails, and some project uses your plugin without a
version
specified, it could use the faulty 'testing' plugin in the local repository.
That's
something maven tries to avoid - placing artifacts in the local repo that
haven't
passed the tests.
* * *
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.
If you can convince us, we'll apply the patch, but there are some drawbacks.
There are other discussions going on how to get all the different integration
test methods sorted out in just one approach, where this one is a solution
to a problem we're having with one of them, which was already solved in another
mojo.
Anyway I think it's a good thing to get the discussion going again so we can
sort
this out. I really think maven should provide an easy means of integration
testing
plugins and other artifacts, preferrably without polluting the local repository
;)
-- Kenney
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
