cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans <jheym...@apache.org>
Subject Re: FYI: Continuum is usable again
Date Tue, 08 May 2007 21:18:30 GMT
Marc Portier wrote:
> 
> 
> not really,
> only idea is some naive cron-job removing files from the repo:
> 
> 1/ regular (monthly) removal of the complete repository off the
> continuum 'user' will enforce pure clean builds, but
>   * make those first new builds of the month extremely slow
>   * dunno if that same 'user'/repo is used in other projects as well
> 
> 2/ another approach with a more 'continuous' feel would be to daily
> remove all files that were downloaded XX days ago (30?)
> 
> find ${USER}/.m2/repository -type f -mtime +30 -exec rm {} \;
> 
> forcing only those to be fetched again will somewhat spread the stress
> on downloading that stuff again
> 
> to introduce this scenario however you'ld need to gradually step down in
> age of documents (just to make sure that you don't get a big
> download-stress every 30 days measure from the first time you've put
> this in place)
> 
> some listings like:
> $ for i in $(seq 0 10); do echo -n "#files older then ${i}0 days: ";
> find ~/.m2/repository/ -type f -mtime +${i}0| wc -l; done
> 
> might hint at which groups to remove manually (during the week before
> starting the regular remove) in order to get an optimum spread
> 
> 
> anyway: additional challenge with this kind of hard cleaning is making
> sure that continuum isn't starting/running builds while the repo-files
> are being removed...
> 
> 
> above suggests that stuff like this might make more sense at the
> continuum level, anyone?
> 
> or even better, inside maven: having some kind of a flag that would at
> least check (not download) if jars/checksums are still
> available/matching at the remote repositories
> 

How about we just execute dependency:purge-local-repository from a 
continuum profile in the root pom ? That should clean out the repo 
enough to guarantee a consistent build.

I wouldn't worry too much about the first build being slow, repo1 is 
really fast nowadays.


Jorg


Mime
View raw message