On 6/11/2013 6:53 PM, Marshall Schor wrote: > 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...
Well, I went to builds.apache.org and took a look at the uimaj-sdk build configuration, and found, under the "advanced" tab in the build section, some tic boxes, one of which was to use a private Maven repo. The help for this says that all jobs on one particular build machine do normally share a .m2 repo. Learn something new every day:-) -Marshall > > -Marshall >
