uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: jcasgen-maven-plugin integration test timing
Date Tue, 11 Jun 2013 20:55:12 GMT
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?


On 6/11/2013 4:26 PM, Richard Eckart de Castilho wrote:
> Am 11.06.2013 um 22:17 schrieb Marshall Schor <msa@schor.com>:
>> 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

View raw message