Am 11.06.2013 um 22:17 schrieb Marshall Schor <[email protected]>: > On 6/11/2013 3:57 PM, Richard Eckart de Castilho wrote: >> The m2e integration test takes *very* long because it materializes a full >> OSGI runtime environment on the machine. The downloads take forever. > This seems to download to a local maven repository which is temporarily built > in > the target/local-repo area. > > I wonder if this could be changed to use the build-machine's .m2 repo, and > thus > cache or otherwise avoid downloading things?
The problem appears to be that the integration test must be able to install the plugin under test into a repository, so Maven can use it from there. A quite detailed description is given here: http://maven.apache.org/plugin-testing/maven-plugin-testing-tools/ <quote> In addition to plugin-version inconsistencies, integration-testing of Maven plugins must cope with the need to cleanup after themselves. Remember, Maven only loads plugins from its own local repository (possibly after resolving them from a remote repository). Because of this, the only practical way to use the current plugin within an integration-test build is to install it into some sort of local repository, then direct Maven to use that local repository for the build. To avoid side effects in other builds (remember, we're building Maven plugins here... and they're used to build other projects), it's critical to avoid using the main local repository used for normal Maven builds. Therefore, plugin integration tests require a custom local repository, to which the integration-testing builds can be directed. Further complicating this testing scenario is the fact that the plugin's parent POM or one of its ancestor POMs could be a snapshot which has been installed in the main local repository, but which is not reachable using the plugin-POM's <relativePath/> parent-element.+ + All of this seems to indicate that the best approach for ensuring the presence of all required POMs and plugins is to use the normal local repository to construct a new local repository for testing purposes. Work on this is ongoing. </quote> The integration tests run with a special "settings.xml" file which declares the target/local-repo as custom repository and which include the actual build system repo as "upstream" repository. Since the OSGI artifacts are not available in the "upstream" repository, they are downloaded. If there were available upstream, I suppose they's be copied. So far my understanding. -- Richard
