I tried to avoid having tests as a separate module, to avoid exactly this situation that broken artifacts escape from the build. I think that's in fact what the integration-test phase and concept are good for.
-- Richard Am 11.06.2013 um 23:04 schrieb Richard Eckart de Castilho <[email protected]>: > 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 > > 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. > > 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
