I think the scenario that is driving the logic to install the maven plugin under test to a special isolated repository may not apply to this one.
This is because this plugin is not used to build any other things (other than user projects); that is, it's not used in building any of the UIMA projects. It seems to me that we could operate by having this plugin install itself to the developer's local .m2 repository, and then run the integration test. This would require that any parent pom be installed also to the local repository. That's needed, anyways, for other parts of the build. So - if we did that, I wonder if the rest of the build could be made to work without a custom repository? -Marshall On 6/11/2013 4:26 PM, Richard Eckart de Castilho wrote: > 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
