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.
Do you have a working example of this I can look at? (ie. something
I can checkout and build w/o any modifications to see how this works)?
> 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).
How is this uncontrolled?
> 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.
True, though IMO forceVersion is a little easier ;-)
> - 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
That is what I want to do... I want to use "testing" for the version
of my artifacts to be tested, and then use "testing" for all versions
in the src/it poms.
> - 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.
I looked into some plugin that was using this... but couldn't get it
to build, nor could I find the snaps or source for the plugin it was
using to do the stage. But I really don't think its all that useful
to install, then uninstall. If the "testing" version is installed,
it can stay in the repo for all I care.
--jason
> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
|