On 6/11/2013 5:31 PM, Richard Eckart de Castilho wrote: > 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.
I didn't know that on Jenkins, every build (for other projects) shared the same .m2 repository. Is that really true? I would have thought that each defined "build" had its own workspace, but I don't actually know... -Marshall
