Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] tycho-gmp.gmf.tooling builds consumes enormous amount of memory

Agree. No arguments there.

Off topic, wondering should there be a third option, custom location for maven repository. Say, I have 10 jobs, if I set private repository all 10 jobs downloads artifacts separately and occupies 10x space. However, I don't want my jobs to share the global local m2 repository for the reasons you mentioned. But if we have something like a custom location, then all of 10 jobs could share that location, thus reducing the space occupied by m2 repository  by 10 times. Do you think having such option makes sense ?

- Winston

On 2/24/12 5:28 AM, Matthias Sohn wrote:
2012/2/24 Mykola Nikishov <mn@xxxxxxxxx>
On 02/24/2012 09:29 AM, Matthias Sohn wrote:

> I believe that many projects (maybe all ?) use private maven repository
> inside job workspace
> for the following reasons:


>   * in general build jobs run into big trouble if some artifacts in
>     maven repository shared
>     across build jobs are corrupted since build engineers can't fix this
>     on their own since
>     they don't have direct write access to this shared maven repository
>     so they can't delete
>     the corrupt artifacts. With job-local, private maven repository this
>     can be easily fixed by
>     wiping the job's workspace which will throw away the private maven
>     repository.

It's not about corruption only. Private repository provides better
isolation for dependent projects in terms of a) direct dependencies and
b) versions of plugins:

a) For instance, running 'mvn install' for JGit will not affect EGit (as
it depends on JGit) in any way.

b) For instance, if some project changes its maven-javadoc-plugin's
version to something 'latest and greatest', all other projects that use
the same plugin without explicitly locking down its version, would use
this new version automagically. The result? Your build was good couple
days ago but now it's broken without any specific reason.

for maven dependencies we lock down all the versions we use 


cross-project-issues-dev mailing list

Back to the top