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: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
