From users-return-130826-apmail-maven-users-archive=maven.apache.org@maven.apache.org Fri Jan 18 07:28:36 2013 Return-Path: X-Original-To: apmail-maven-users-archive@www.apache.org Delivered-To: apmail-maven-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DE5DBEE8E for ; Fri, 18 Jan 2013 07:28:35 +0000 (UTC) Received: (qmail 59753 invoked by uid 500); 18 Jan 2013 07:28:33 -0000 Delivered-To: apmail-maven-users-archive@maven.apache.org Received: (qmail 59574 invoked by uid 500); 18 Jan 2013 07:28:33 -0000 Mailing-List: contact users-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Users List" Reply-To: "Maven Users List" Delivered-To: mailing list users@maven.apache.org Received: (qmail 76915 invoked by uid 99); 18 Jan 2013 04:25:48 -0000 X-ASF-Spam-Status: No, hits=2.1 required=5.0 tests=FROM_STARTS_WITH_NUMS,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of 3150hbr@gmail.com designates 209.85.214.196 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=d7IEdN+SgQstG7TGcrOs305FHNkxY072ykWJ7ofFX/g=; b=jd84cznvJuloQNC/isiNKtiHXrY7S1sEo/UNt8mnt+v3zl3fDQ/f/uf9IhPaDXYmkV IsP2UPRt8yRUPn5XHjHekON+ZzOxgp0kcwTl3NeuA87HQ/7AEx0gHOqRh6EEMIvfCQNh ZFbr7XCMSmzmM2kUSu3uF3mkLy/LUY3KcshimT67CLJHtd6raOIxg0lwp0OJq70HBKnB IU5s98FXa/fncbYlbYotgJ4X45pgHQDLldgIk7v8YlZg26xu87gCoKV0zwZzXJ4BuNkG pAagGhqq59TdQHOgS0DVl0rKPKXFVPcRcGEeO7XssMHnl8IhcjjCz2pFJj4i9+r7pm0W NVOQ== MIME-Version: 1.0 X-Received: by 10.182.226.74 with SMTP id rq10mr5929478obc.32.1358483121704; Thu, 17 Jan 2013 20:25:21 -0800 (PST) Date: Thu, 17 Jan 2013 23:25:21 -0500 Message-ID: Subject: always not working for with Maven 3.0.4 From: Maven User <3150hbr@gmail.com> To: users@maven.apache.org Content-Type: multipart/alternative; boundary=f46d04462ec0e70f3604d3887f76 X-Virus-Checked: Checked by ClamAV on apache.org --f46d04462ec0e70f3604d3887f76 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We produce a large application from the artifacts of 15+ components, many which contain multiple modules. The version numbers are all the same, and a build cycle takes about four hours. Late in a development cycle we run numbered (i.e. non =93-SNAPSHOT=94) buil= ds in continuous integration mode. Doing so facilitates quicker turnaround times of last minute bugs. Once a package is actually delivered to QA we return to producing -SNAPSHOT artifacts. We are aware re-producing numbered artifacts is not a best practice. Part of the reason we felt like running a numbered build in CI mode would work is the =93update policy=94 option which is available for "releases." See http://maven.apache.org/ref/3.0.4/maven-settings/settings.html. By our reading, this setting should enable the updating of numbered artifacts in the local Maven cache with a newer version from the central repository (we are using Artifactory Pro 2.5.1). Instead, we observe this behavior: Starting from an empty local Maven cache, the build of component #2 works as designed. However, after component #1 is rebuilt, a rebuild of component #2, which is dependent on the jar file produced by the build of component #1, the execution of =93mvn =96U clean deploy=94 fails to update the recently modif= ied numbered artifact in the local Maven cache. The routine below is part of ${MAVEN_HOME}/conf/settings.xml: Repositories true Artifactory Artifactory Public Mirror http://machine.domain.com:8082/artifactory/repo default true always true always Does anyone have any insight into why the local Maven cache is not being updated with the newer numbered artifacts from our Artifactory repository? --f46d04462ec0e70f3604d3887f76--