maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: forceVersion for maven-install-plugin?
Date Fri, 16 Mar 2007 19:09:50 GMT
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 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message