Kenny, when you get a chance I'd love to see an example of the maven-
it-plugin in action.
For now, I've just configured my projects to use install:install-
file, which appears to be working fine (at the cost of a bit more
complicated configuration).
--jason
On Mar 16, 2007, at 3:58 AM, Kenney Westerhof wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]