Return-Path: X-Original-To: apmail-archiva-dev-archive@www.apache.org Delivered-To: apmail-archiva-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3A07011CFF for ; Mon, 7 Jul 2014 05:09:48 +0000 (UTC) Received: (qmail 66930 invoked by uid 500); 7 Jul 2014 05:09:47 -0000 Delivered-To: apmail-archiva-dev-archive@archiva.apache.org Received: (qmail 66877 invoked by uid 500); 7 Jul 2014 05:09:47 -0000 Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@archiva.apache.org Delivered-To: mailing list dev@archiva.apache.org Received: (qmail 66866 invoked by uid 99); 7 Jul 2014 05:09:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Jul 2014 05:09:47 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.220.48] (HELO mail-pa0-f48.google.com) (209.85.220.48) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Jul 2014 05:09:41 +0000 Received: by mail-pa0-f48.google.com with SMTP id et14so4785860pad.21 for ; Sun, 06 Jul 2014 22:09:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=cLbCwpwCPcozGEWeEkJpXaX2EFgHCJ0Q8pMf5RM8N7M=; b=QCG0p51dHn2r28nwsl/J36gagrzh6GATxiaJVbFz6q21WVjsptbvildVpejdVAG/vt tRbR7BNH+J7SIKj0eb6TMbQ3E5uucmoxtycMoe6r58wqjumH5NgSockffRigYOUOjgts l+O76U+AHsgJnGPlSK0osOQ9vIVjhkNEHF3C+taObbDBkdGVD87n4Bwp8d9tmhEALN6Z EjRR5gxwPk7E7oiR2mkbsoKKnIQquJNjZOblb4pvNKFP7saFBJjVFRS6LeM4nZdw+IEn OiodPHOUOjGkxTL7o9s8kHB8SfeaZPrOIcLz1xDV00gp22sX8gomxaWEHFlE+lR4WU4T lCWg== X-Gm-Message-State: ALoCoQkvMeYTt/h0YdlToPXic2HY7zKiSTSMCsz0nfh/pmKlc8Jg25HJM9OMwmjhje3ssjGYUJls X-Received: by 10.68.117.42 with SMTP id kb10mr16578541pbb.75.1404709759185; Sun, 06 Jul 2014 22:09:19 -0700 (PDT) Received: from [10.0.0.7] (ppp121-44-163-165.lns20.syd7.internode.on.net. [121.44.163.165]) by mx.google.com with ESMTPSA id gg3sm51260269pbc.34.2014.07.06.22.09.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Jul 2014 22:09:17 -0700 (PDT) Sender: Brett Porter Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: Help understanding RepositoryContentConsumer API From: Brett Porter X-Priority: 3 (Normal) In-Reply-To: <4bd395d17ea9fad0d6c12e8209d44688.squirrel@msqr.us> Date: Mon, 7 Jul 2014 15:09:13 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <23D0CA5E-B193-4B17-8975-90C077605558@apache.org> References: <4bd395d17ea9fad0d6c12e8209d44688.squirrel@msqr.us> To: dev@archiva.apache.org X-Mailer: Apple Mail (2.1878.2) X-Virus-Checked: Checked by ClamAV on apache.org It's close, but not quite the same meaning. The flag is for scanning a = single file, vs. a whole repo (either via the repositories page, or a = scheduled job). Single files get consumed when they are added via = deployment/upload, for example. A whole repo scan can either be incremental (files newer than = "changesSince" in the scanner instance), or process all ("changesSince" = will probably be epoch/null). I thought that was passed through to the = consumer as "whenGathered", but it doesn't seem to be the case. We could probably add some more hooks into the overall process if you = wanted to propose such a change? Or is processing updates and deletions sufficient to maintain the = metadata, without having to start from scratch? - Brett On 5 Jul 2014, at 8:58 am, Matt Magoffin <"apache.org."@msqr.us> wrote: > Hello, >=20 > I have been working on a RepositoryContentConsumer implementation to > generate OSGi bundle repository metadata XML file. It mostly works, = except > that I think I'm not quite understanding the "executeOnEntireRepo" = flag in > this method: >=20 > void beginScan( ManagedRepository repository, Date whenGathered, = boolean > executeOnEntireRepo ) throws ConsumerException; >=20 > The issue I have is that I want to know if I am just performing an > incremental scan of the repository vs. the entire repository, i.e. = from > executing "Directories Scanning" action from the web UI. If the scan = is > incremental, I want to preserve the existing OBR metadata and just add = the > changes, otherwise I want to generate the metadata file from scratch. >=20 > I had thought the executeOnEntireRepo flag would tell me if the scan = was > incremental, but it does not seem that is true. Can you tell me then, = from > this API, how I might tell the difference between an incremental scan = and > a full scan? >=20 > Cheers, > Matt >=20 >=20