maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: <updatePolicy>always</updatePolicy> not working for <releases> with Maven 3.0.4
Date Fri, 18 Jan 2013 08:34:30 GMT
On Friday, 18 January 2013, Maven User <3150hbr@gmail.com> 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?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message