[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323053#comment-323053
]
Sergei Ivanov commented on MNG-3092:
------------------------------------
@Scott:
45 minutes is clearly abnormal: it takes me about 5 minutes to refresh all our
100+ Maven3 projects configured within an uber-project in IDEA, or 10 minutes
if IDEA needs to rebuild indexes. Either M2E is going around in circles and
trying to resolve dependencies thousands of times, or there is something in
your environment that causes massive delays.
Please make sure that your {{settings.xml}} file has a mirror section that
redirects all requests to 'central' to your Artifactory instance. Otherwise
Maven may attempt to fall back to looking any missing artifacts in central
(it's hardcoded in Maven and cannot be switched off!). If you are behind a
proxy server, these requests will be blocked, if you happen to have direct
access to the internet, then you'll be hammering central with requests for your
internal artifacts, which is bad news for both you (it takes considerable time
and creates a security risk) and maven central (it has to handle all those
unnecessary requests). Try to activate debug logging in both Artifactory and
Maven/M2E and make sure it is not attempting to do any silly things.
For reference, we have got the following sections in {{settings.xml}} (all
names changed to protect the innocent):
{code:lang=xml}
<mirrors>
<mirror>
<id>internal-mirror</id>
<name>Internal Maven repo, proxying to external repos, including
central</name>
<url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public</url>
<mirrorOf>external:*,our-artifact-releases,our-plugin-releases,!our-artifact-snapshots</mirrorOf>
</mirror>
</mirrors>
<profiles>
<profile>
<id>our-releases</id>
<repositories>
<repository>
<id>our-artifact-releases</id>
<name>Our Release Repository</name>
<url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>our-plugin-releases</id>
<name>Our Release Repository</name>
<url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
<profile>
<id>our-snapshots</id>
<repositories>
<repository>
<id>our-artifact-snapshots</id>
<name>Our Snapshot Repository</name>
<url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/repositories/snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>our-releases</activeProfile>
</activeProfiles>
{code}
Please note that the {{our-snapshots}} profile is not active by default. This
is to block remote shapshots if one does not want to download them.
@Jesse:
Please keep in mind that Maven3 creates a number of maven-metadata.xml files in
the local repo:
# At groupId/artifactId level it creates a {{maven-metadata-<repo/mirror
name>.xml}} file for every remote repo or a mirror that is configured in POM or
{{settings.xml}}. Additionally, it creates {{maven-metadata-local.xml}} file
that reflects local artifact installs.
# At groupId/artifactId/version level it creates {{maven-metadata-local.xml}}
file for local artifact installs only.
Deleting all locally cached snapshot directories under groupId/artifactId
directory without updating or purging the top-level metadata files is a recipe
for trouble. Stale version references in metadata files will make Maven believe
that those snapshots still exist, and it will desperately try to download
metadata and artifacts for the "missing" snapshot versions.
I suspect that you may have a cron job that purges snapshots from the local
repo daily, but does not do it in a clean way. As a result, "one build per day
spends a chunk of time" attempting to fetch these missing snapshots from
elsewhere.
> Version ranges with non-snapshot bounds can contain snapshot versions
> ---------------------------------------------------------------------
>
> Key: MNG-3092
> URL: https://jira.codehaus.org/browse/MNG-3092
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
> Reporter: Mark Hobson
> Assignee: Jason van Zyl
> Fix For: 3.1.1
>
> Attachments: MNG-3092.patch, MNG-3092.patch
>
>
> Contrary to the 2.0 design docs:
> "Resolution of dependency ranges should not resolve to a snapshot
> (development version) unless it is included as an explicit boundary."
> -- from
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
> The following is equates to true:
> VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new
> DefaultArtifactVersion( "1.1-SNAPSHOT" ) )
> The attached patch only allows snapshot versions to be contained in a range
> if they are equal to one of the boundaries. Note that this is a strict
> equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
