You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Maven User <31...@gmail.com> on 2013/01/18 05:25:21 UTC
always not working for with
Maven 3.0.4
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." 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?
Re: always not working for
with Maven 3.0.4
Posted by Stephen Connolly <st...@gmail.com>.
On Friday, 18 January 2013, Maven User <31...@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?
>
Re: always not working for
with Maven 3.0.4
Posted by Ron Wheeler <rw...@artifact-software.com>.
Version 1.0 is not newer than version 1.0.
No need to download a new copy since there is not one any newer than 1.0
which it already has.
You probably should go to SNAPSHOTs and try to find a way to release in
stages- low level code should be able to be tested and released without
releasing the high level stuff.
It requires a bit more discipline in the development cycle and a
willingness to admit to testing errors which require manual deletion of
artifacts that get released before all the bugs are out.
On the bright side:
It is kind of motivating (at least to the project manager) to be able to
say that you have released 10 of the 15+ components and only have 5+ to
go before the release is done.
It also makes everyone aware of the importance on interface
specifications and the need to test at the component level.
It also makes programmers stand behind their work and give an implied
warranty to their colleagues with each new SNAPSHOT and release.
Ron
On 18/01/2013 3:22 AM, Jörg Schaible wrote:
> Hi,
>
> Maven User 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.
> What does that mean in real?
>
>> 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." 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>
> A release is a release i.e. a unique artifact. There will be no updates. You
> may set this as well to "none".
>
>> </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?
> Depends on your real numbering scheme. E.g. as Maven n00bs we tried once a
> development scheme like
>
> 1.0-SNAPSHOT --> 1.0.0 --> 1.0-SNAPSHOT --> 1.0.1 --> 1.0-SNAPSHOT
>
> This fails miserably, because 1.0-SNAPHSOT is the equivalent of 1.0.0-
> SNAPSHOT and therefore the SNAPSHOT is always considered to be of a lesser
> number than any release.
>
> See, what I mean?
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: always not working for with Maven 3.0.4
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi,
Maven User 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.
What does that mean in real?
> 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." 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>
A release is a release i.e. a unique artifact. There will be no updates. You
may set this as well to "none".
> </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?
Depends on your real numbering scheme. E.g. as Maven n00bs we tried once a
development scheme like
1.0-SNAPSHOT --> 1.0.0 --> 1.0-SNAPSHOT --> 1.0.1 --> 1.0-SNAPSHOT
This fails miserably, because 1.0-SNAPHSOT is the equivalent of 1.0.0-
SNAPSHOT and therefore the SNAPSHOT is always considered to be of a lesser
number than any release.
See, what I mean?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org