| Re: [dash-dev] Maven Nexus server |
On 16 Aug 2012, at 09:33, Aaron Digulla wrote:
Presumably because the build infra uses half of Maven central, or (more likely) random developers over the planet put 'maven.eclipse.org' at the front of their resolution profile and so we are acting as a cache for everything. So Point 1 to learn; we need to have an internal Nexus instance which is for the purposes of the internal Hudson infra caching, and we need to have an external one that can contain published Eclipse content. Ideally members of the public should only be able to see the latter. Point 2 to learn; the two repo1/repo2 were created to do some kind of load balance/mirror between the two (it was also created shortly after the repo1 DNS entry went wobbly a couple of years back). In retrospect we should have a single 'central' repo and then use the 'mirror' in the repository proxy configuration to utilise either of these. That would save storing a bunch of stuff twice. (In fact, we seem to be storing a third copy under 'central' which is the group, which doesn't help.) Point 3 to learn is that disk space needs to be monitored and alerted, in a way (presumably) similar to the Hudson setup. Part time admins rarely work out well. Point 4 is that whilst processing power for a VM isn't an issue, great gobs of virtual disk are a serious bottleneck to doing most of the work. Even a du -s * in the repositories folder takes significant amounts of time (tens of minutes) which really doesn't help when you are trying to solve the problems caused by lack of disk space. Point 5 is that really, published Eclipse content should migrate to Maven Central instead of being hosted on Eclipse infra. The key challenge, it seems, is getting it in a suitable form. I believe that CBI may be the way to make this happen. Alex |