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 <[email protected] <mailto:[email protected]>>
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
