Am 11.06.2013 um 23:15 schrieb Marshall Schor <[email protected]>: > 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 :-)
On Jenkins it would affect other builds. This could be avoided by activating the "use private maven repository" option for the UIMA SDK builds. It wouldn't exactly safe disk space on the poor Jenkins build slaves of the ASF though. > 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. I don't know… to increase the turn-around on a developer machine, how abound using "-DskipInvocation=true" to skip the integration tests and only run them occasionally? If good measures are taken to contain broken artifacts, I don't find a good argument for a -1, but I wouldn't +1 either. That disk space appears to be a scarce resource on the ASF Jenkins may be slightly in favor of an alternative to activating the private repository option, like skipping integration tests unless one wants to run them… or skipping them by default but activating them on Jenkins. -- Richard
