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 7612711166 for ; Mon, 14 Jul 2014 19:37:38 +0000 (UTC) Received: (qmail 14303 invoked by uid 500); 14 Jul 2014 19:37:37 -0000 Delivered-To: apmail-archiva-dev-archive@archiva.apache.org Received: (qmail 14218 invoked by uid 500); 14 Jul 2014 19:37:37 -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 13704 invoked by uid 99); 14 Jul 2014 19:37:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jul 2014 19:37:36 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of apache.org@msqr.us designates 202.37.100.97 as permitted sender) Received: from [202.37.100.97] (HELO mx0.ironport.snap.net.nz) (202.37.100.97) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jul 2014 19:37:28 +0000 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=1akexWKjxFc2Y1oqQljwjQrUOQwfgRImPeb1nDXq8RQ= c=1 sm=2 a=LdcabYGyVigA:10 a=6MY1vWnM1dQA:10 a=NjuLKI5jG4EA:10 a=8nJEP1OIZ-IA:10 a=Gw1udbuELT57SF3F0dAA:9 a=wPNLvfGTeEIA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAMEwxFN7/y9j/2dsb2JhbABZgw6BLaweAQEBAQEBBpxtAYEYFoR5AQQBMgFLCwUGRlcqiCkHyFUXgmGDGohuEQFXFoQtBZELigOSRYFZg1mBYjk X-IronPort-AV: E=Sophos;i="5.00,890,1396958400"; d="scan'208";a="265984264" Received: from rupert.snap.net.nz ([202.37.100.140]) by smtp0.ironport.snap.net.nz with ESMTP; 15 Jul 2014 07:37:07 +1200 X-Sender-IP: 123.255.47.99 Received: from x24.msqr.us (msqr.us [123.255.47.99]) by rupert.snap.net.nz (Postfix) with ESMTPS id 9DF1E25672 for ; Tue, 15 Jul 2014 07:37:06 +1200 (NZST) Received: from msqr.us (localhost [127.0.0.1]) by x24.msqr.us (8.14.9/8.14.7) with ESMTP id s6EJb40u020957 for ; Tue, 15 Jul 2014 07:37:04 +1200 (NZST) (envelope-from apache.org@msqr.us) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.4 at msqr.us Received: from 123.255.47.99 (SquirrelMail authenticated user matt) by msqr.us with HTTP; Tue, 15 Jul 2014 07:37:04 +1200 Message-ID: <2a0d8af0748449451eb115804852dcef.squirrel@msqr.us> In-Reply-To: <4bd395d17ea9fad0d6c12e8209d44688.squirrel@msqr.us> References: <4bd395d17ea9fad0d6c12e8209d44688.squirrel@msqr.us> Date: Tue, 15 Jul 2014 07:37:04 +1200 Subject: Re: Help understanding RepositoryContentConsumer API From: "Matt Magoffin" To: dev@archiva.apache.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Checked: Checked by ClamAV on apache.org I'm sorry I'm replying to my own email... I was not yet subscribed to the list when I sent my previous message. This is in reply to Brett's response on the 7th of July: Thank you Brett for your reply. > 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. If the "whenGathered" date was set to the epoch or null, or perhaps the RepositoryScanner.FRESH_SCAN constant (with a value of 0), that would indicate to my consumer that a "full" scan were being performed. But when I do initiate the Directory Scan from the UI, the "whenGathered" is set to the current time. > 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? If I could process updates and deletions, and know they were such, I could maintain the metadata appropriately, yes. The reason I want to re-create the metadata is for the case when something is deleted. I don't see how I get informed of deletions in the RepositoryContentConsumer API, however. Is there a way to get notified of them? Cheers, m@