[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323015#comment-323015
]
Sergei Ivanov commented on MNG-3092:
------------------------------------
@Scott:
I have never seen dependency resolution under Maven3 taking _minutes_ in our
environment, even though we are using version ranges for internal dependencies
quite extensively (both deep and wide, about 100+ internal
applications/libraries in our project all in all). From what we have seen,
metadata update is the real performance killer, especially if one runs Maven
with {{-U}} option to force it checking for new versions in the remote repo.
And with version ranges in a fluid environment we are effectively forced to use
{{-U}} aggressively, otherwise we end up relying on Maven's metadata caching
strategies, which introduces an element of uncertainty.
A number of times we ended up with really slow metadata update and dependency
resolution. Every time we checked Nexus logs and found out that it was (a)
trying to download metadata for internal artifacts from external repos (which
is also pretty bad from security point of view), or (b) that some external
repos got reconfigured/relocated (happened recently to Netbeans repo), or (c)
that some artifacts got relocated or were not accessible anymore. Each time,
after fixing repo configuration, routing rules, blacklisting/whitelisting or
caching strategies we managed to bring performance of the dependency resolution
back to acceptable levels.
If you have not already done so, may I suggest that you analyse the behaviour
of your repo manager, and try to make sure that the metadata update checks for
your artifacts are not being slowed down by unnecessarily proxying those
metadata requests to e.g. Maven Central. If repo manager is not your
bottleneck, then it may still be the case that you have genuinely reached the
point where performance of Maven3 went downhill because of the complexity of
your system.
> 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
