On Friday, 18 January 2013, Maven User <[email protected]> wrote: > 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 “-SNAPSHOT”) builds > 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 “update policy” option which is available for "releases."
At first you think that it is a great pity that, at the time, the same object was reused for the "releases" as we'll as "snapshots" properties. and you think that by rights the "snapshots" property should be a subtype of the "releases" property as it just causes confusion on the half of users... However what this actually refers to is the update policy *of the metadata sourced from the release repository* Thus when you have a version range (which turn out to be a bad plan) an update policy of always means it will re-check the metadata to see if there are any new versions which might affect the range resolution. Release versions are *never* re-downloaded... But there are other files in a release repo which do change (metadata) and that is what the policy refers to HTH -Stephen > 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 “mvn –U clean deploy” fails to update the recently modified > numbered artifact in the local Maven cache. > > > The routine below is part of ${MAVEN_HOME}/conf/settings.xml: > > <profiles> > <profile> > <id>Repositories</id> > <activation> > <activeByDefault>true</activeByDefault> > </activation> > > <repositories> > <repository> > <id>Artifactory</id> > <name>Artifactory Public Mirror</name> > <url>http://machine.domain.com:8082/artifactory/repo > </url> > <layout>default</layout> > <releases> > <enabled>true</enabled> > <updatePolicy>always</updatePolicy> > </releases> > <snapshots> > <enabled>true</enabled> > <updatePolicy>always</updatePolicy> > </snapshots> > </repository> > </repositories> > </profile> > </profiles> > > > > Does anyone have any insight into why the local Maven cache is not being > updated with the newer numbered artifacts from our Artifactory repository? >
