Maven 2 & 3

critical: well... that is I think only for traveling persons really critical

It is also critical for people who are in countries with poor or very expensive internet access

This is still an issue in maven 2.0.8

azeckoski:test-runner azeckoski$ mvn -v
Maven version: 2.0.8
Java version: 1.5.0_13
OS name: "mac os x" version: "10.5.1" arch: "i386" Family: "unix"
azeckoski:test-runner azeckoski$ mvn -o clean install
[INFO] NOTE: Maven is executing in offline mode. Any artifacts not already in your local
repository will be inaccessible.

[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Sakai TestRunner
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

GroupId: org.sakaiproject.maven.plugins
ArtifactId: sakai
Version: SNAPSHOT

Reason: System is offline.
org.sakaiproject.maven.plugins:sakai:pom:SNAPSHOT

NOTE: Maven is executing in offline mode. Any artifacts not already in your local
repository will be inaccessible.

[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Fri Dec 07 09:28:15 PST 2007
[INFO] Final Memory: 2M/254M
[INFO] ------------------------------------------------------------------------

I can confirm this bug on maven versions 2.0.6, 2.0.7, and 2.0.8.

This is also a critical issue for corporate software teams with an internal Maven repository which is not available to developers who are working offline or at home where the internal repository is not available.

I've added an integration test to the Maven suite, to try to capture this failure so I can debug/fix it. However, the test case doesn't fail with either 2.0.7 or 2.0.9...

The test case is here: http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests/src/test/resources/mng-3314-offlineSnapshots

and the JUnit controller class is here:

http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests/src/test/java/org/apache/maven/integrationtests/MavenITmng3314OfflineSnapshotsTest.java

Can someone please let me know what I'm doing wrong here? In the comment two above this one, that output would seem to be correct, if the dependency weren't present in the local repository, and nobody else has given any concrete detail for this error in terms of console output or test-case projects.

Without more information, I'm going to close this bug as CANNOT_REPRODUCE.

I haven't been able to reproduce this error. I've incorporated a series of integration tests, as noted in the previous comment. If this bug is still present, and you can provide more details - or even better, a test build that's failing - then reopen it and I'll take another look.

I too see this issue. It happens for me when attempting to depend on a snapshot version of a module downloaded from a repository. If the snapshot version of the module is built and installed locally, the problem goes away.

I will attach two projects (in a tar file) that have minimal external dependencies, and the debug output of trying to build. Here are the steps to reproduce:

Environment:
Maven 2.0.8
Linux 2.6.18
Artifactory 1.2.5 (rev. 1154)

Preliminary steps:
1) Modify the pom files to refer to your repository instead of http://localhost:8081/artifactory/jumptap-snapshots
2) Build maven-test-project1
3) Upload the pom and jar for maven-test-project1 to your repository.

Steps that cause the error to happen:
1) Delete maven-test-project1 from the local repository.
2) Build maven-test-project2 without the offline flag (mvn install). This build is successful (and downloads maven-test-project1 to the local repository).
3) Build maven-test-project2 with the offline flag (mvn -o install). This build fails, unable to resolve the maven-test-project1 artifact.

Steps that cause the error not to happen
1) Build maven-test-project1 locally. This build is successful.
2) Build maven-test-project2 without the offline flag (mvn install). This build is successful.
3) Build maven-test-project2 with the offline flag (mvn -o install). This build is successful.

Contains two projects, maven-test-project1 and maven-test-project2. maven-test-project2 depends on maven-test-project1. maven-test-project2 offline unless maven-test-project1 has been built locally.

The debug log produced when trying to build maven-test-project2 offline when maven-test-project1 has not been built locally, but when maven-test-project1 has been previously downloaded due to an online build

Sorry about those two previous comments. I thought they were comments about the attachments, not comments about the bug. The first comment refers to maven-offline-snapshot-problem.tar and the second comment refers to maven-offline-snapshot-failure.log

There are new samples attached, so lets retry to reproduce for 2.0.11

The problem seems to be related to the ctime of the SNAPSHOT artifacts.

I have a hierarchal project where sub project B depend on subproject A. A and B are modules in the root pom:

root-+--A
     |
     +--B

Here are the scenarios (with maven 2.0.9):

• If I build the full project offline from the root project, everything works fine.
• If I build project B immediately afterwards (offline), everything works fine.
• If I wait awhile (an hour? a day? I can't remember) and build project B again (offline), it complains about a missing snapshot dependency to the A project. Now for the fix: If I touch the "missing" snapshot jars (touch ~/.m2/repository/myproject/A/1.0-SNAPSHOT/*) and build project B offline again, everything works fine again.

It seems that the snapshot artifacts have a maximum availability lifetime in offline mode.

I'm running Maven 2.0.8, and I see the same behavior that Henrik described. Touching the files does fix the problem.

If the snapshot dependencies are coming from a remote repository, then setting the snapshot update policy of the remote repository to never also fixes the issue. See http://maven.apache.org/settings.html#Repositories for an example.

The snapshot update policy does not seem to be applied to transitive dependencies. Maven still complains about transitive snapshot dependencies if the files have a timestamp from a previous day. I resolved this by including the transitive snapshots directly in my project dependencies.

IT for this has been updated to exhibit problem. The proposed patch (for the 2.0.x branch) simply skips the update checks for snapshots when Maven is in offline mode.

Patch applied, ITs pass.

This is not fixed for me in maven 2.0.10.