Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 19556 invoked from network); 20 Dec 2006 11:10:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Dec 2006 11:10:50 -0000 Received: (qmail 44625 invoked by uid 500); 20 Dec 2006 11:10:52 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 44606 invoked by uid 500); 20 Dec 2006 11:10:51 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 44597 invoked by uid 99); 20 Dec 2006 11:10:51 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Dec 2006 03:10:51 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted nor denied by domain of geir@pobox.com) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Dec 2006 03:10:40 -0800 Received: from [192.168.1.104] (unknown [67.86.14.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C36FC5190F for ; Wed, 20 Dec 2006 06:10:15 -0500 (EST) Message-ID: <45891A17.4010201@pobox.com> Date: Wed, 20 Dec 2006 06:10:15 -0500 From: "Geir Magnusson Jr." Reply-To: geir@pobox.com User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: dev@harmony.apache.org Subject: [general] safe fetching Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Our discussions about msvcrt71.dll and an internal thread at Intel regarding some of our internal CC infrastructure motivates me to suggest... We should consider allowing an override for dependency fetching in the style of a maven repo - one root URL from which all things can be found - to allow us to set up local caches of dependencies. I've used this trick in the past to ensure there was oversight over inclusions in maven-built products - we had a local maven repo that only a few of us could update, to ensure that we had accountability over what software was included in the builds. Maybe we can combine this with the "common_resources" subproject I started for the jdktools - I have yet to migrate either DRLVM or classlib to use it, but that can be the "canonical layout" we use, and have a separate filler-script to populate/update it. I dunno - I'm sure that there are lots of good ideas on how to solve this... geir