Both Maven 2 and 3 fail to retrieve a <dependency> that is larger than Integer.MAX_VALUE

which servlet engine is your corporate maven repository using? Not sure if this is a maven problem or a problem of the repo manager (sending the wrong size). We would need to test this with downloading from a plane httpd.

I tried to sniff the headers when dependency is sent but it's not that easy. IEInspector HTTP Analyzer crashes, WireShark freezes and I can't see the headers. But on one occasion before HTTP Analyzer crashed I saw the correct response length header was sent. I'll try to see if there are other ways to see the headers. May be you can also reproduce this problem and sniff the traffic with better tools or better machines than mine.

URLConnection.getContentLength() is of type int, this might explain the trouble with wagon-http-lightweight.

Managed to grab headers again, before the sniffer crashed (see images attached). Yes, the correct length is sent. Was running Maven 2.2.1 and 3.0.2.

I have the same issue, using the latest maven 3.0.4. Downloads exactly 2^31-1 bytes and then stops. Also using artifactory to serve the artifact and downloading the artifact with wget works without problems.

must be fixed with https://git-wip-us.apache.org/repos/asf/maven-wagon/repo?p=maven-wagon.git;a=commit;h=b8ca4254b1f5a828e7b1347c49b5f14bbb59e30b
You can try last maven 3.1 snapshot available here https://builds.apache.org/view/M-R/view/Maven/job/maven-3.0.x/
@since build #365

I just attempted the 3.1 snapshot (build 320) and my download stalled again and gave me a bad md5 warning:

bdouglas@gambit templates$ /opt/apache-maven-3.1-SNAPSHOT/bin/mvn --version
Apache Maven 3.1-SNAPSHOT (rNON-CANONICAL_2012-12-01_03-31_jenkins; 2012-11-30 22:31:54-0500)
Maven home: /opt/apache-maven-3.1-SNAPSHOT
Java version: 1.6.0_33, vendor: Sun Microsystems Inc.
Java home: /opt/jdk1.6.0_33/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.6.11-1.fc17.x86_64", arch: "amd64", family: "unix"
bdouglas@gambit templates$

The checksum failing is when the artifact is only the Integer.MAX_VALUE size

[INFO] Configured Artifact: org.centos:CentOS-6.3-x86_64-bin-DVD1:1.0:iso
[DEBUG] Using connector WagonRepositoryConnector with priority 0 for http://xxxxx.com/artifactory/libs-release
Downloading: http://xxxxx.com/artifactory/libs-release/org/centos/CentOS-6.3-x86_64-bin-DVD1/1.0/CentOS-6.3-x86_64-bin-DVD1-1.0.iso
[WARNING] Checksum validation failed, expected eaa52f3d1ccf2df3b03e064fb0fa6168be28a4d4 but is 249cf446611db34ad8006bbdb99397c2a4bc201a for http://xxxxx.com/artifactory/libs-release/org/centos/CentOS-6.3-x86_64-bin-DVD1/1.0/CentOS-6.3-x86_64-bin-DVD1-1.0.iso

only checksum fail but artifact is correctly downloaded ?

No – looking at the download information, it stopped downloading then checked the checksum, it failed, so it retried the download, and kept trying and only got as far at the ~1G each time, finally failing

ok I just need to find a way how to test that.
As adding such huge file in the sources tree for unit test is impossible.

Tested with latest Maven 3.1-SNAPSHOT, same problem :

Apache Maven 3.1-SNAPSHOT (ac64dd6bb6096e8dbd54e3520208e5737fb1c804; 2013-05-29 18:48:30-0700)
Maven home: /root/apache-maven-3.1-SNAPSHOT
Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
Java home: /opt/mycorp/jvm/java-1.6.0-sun-x64/jre
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux", version: "3.4.33-2.24-default", arch: "amd64", family: "unix"

Artifact is 2.5Gb long

still weird for me.
I added a unit test https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=05098b3f0f0378a7272f0d9491ef356889bfc67f
And those huge files (with Content-Length or Chunked) are correctly downloaded.