On 6/11/2013 5:04 PM, Richard Eckart de Castilho wrote: > Am 11.06.2013 um 22:55 schrieb Marshall Schor <[email protected]>: > >> 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. > Consider the integration tests of this plugin fail. Then we already have a > broken > plugin installed in the .m2/repository of Jenkins of of the developers machine True > > Consider further that uimaFIT (or maybe at some point cTakes or whatever) is > using > this plugins in its builds. Their jobs in Jenkins may break just because we > let > a broken plugin escape into the wild. Well, it would "escape" into the developer's machine, not any further :-) The fix for this would be "simple" - just delete the plugin in the .m2 repo. The next invocation would then download a (presumably) good version from Maven Central :-)
For me, this kind of thing would be a good trade-off if we could get the integration test for the plugin to work in a few seconds instead of many minutes. -Marshall > > The Maven life cycle defines the intergration-test phase before the install > phase. > The installation of the plugin under test is afaik a special feature of the > maven-invoker-plugin. If we want to rely on the "normal" install of the > plugin, then > we'd have to create a separate Maven module for the integration tests - which > I tried > to avoid. > > -- Richard
