Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: domain of marc.portier@gmail.com
 designates 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:sender;
        b=oDgvmapbQz9WAbT7eO0Va/D1du2mYUSDf2bd/iIUdlZq88klmgaYcuL9aMh0MoRk2QifcHw3jMPqHLBl/4adQFmvxf70pRRnsul1K5tluJ1q0ODTK2eM88Z1RZ4XCWfnQJZzGH4L9BCv+iCF6FnkOXjui+xze5Q8qNaqBpAwT64=
Message-ID: <4640442B.2030107@outerthought.org>
Date: Tue, 08 May 2007 11:34:35 +0200
From: Marc Portier <mpo@outerthought.org>
Organization: Outerthought
User-Agent: Thunderbird 1.5.0.10 (X11/20070403)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: FYI: Continuum is usable again
References: <463F61A7.3080009@tuffmail.com> <464010CE.9050707@apache.org>
In-Reply-To: <464010CE.9050707@apache.org>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Sender: Marc Portier <marc.portier@gmail.com>


Reinhard Poetz wrote:

> Using Continuum is definitly a step forward in order to have a stable
> build but it doesn't detect problems if dependencies can't be downloaded
> anymore or if we remove a module from our build but forget to remove all
> dependencies on it from other modules. In those cases only a build with
> a clean local repo would help. Though I don't know how this could be
> achieved together with a Continuum build. Any ideas?
> 

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

wdot?

-marc=