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
--
Matthias
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|