Maven: repositories

Question

I have a small Java project in a version control system (git), shared by 4 developers. I'm thinking about using Maven in this project as a build tool.

Dependency management is a wanted feature, but I don't want: - automatic updates of dependencies (as this could break my software). - to rely on an Internet connection to download dependencies from a remote repository and be able to compile my code.

Therefore, the questions:

1) May I configure Maven to use local dependencies (eg jars shared in a VCS)? I don't have several dependencies shared among several projects and my dependencies rarely will be updated, so using Maven repositories is not worth it to me imho.

2) If I choose to use a Maven repository, may I configure one in my local network? I don't want a remote repository mirror or a portal to the remote repository. I want a standalone repository with my dependencies, located at a server in my local network.

3) If I use the default Maven approach with the remote repository, could I turn off dependency updates after all dependencies are downloaded the first time?

Thanks in advance for any help.

Answer 1

I thought that Internet connectivity was only needed in the 1st compile, but I get several download msgs whenever I change code. Msgs like these:

Downloading: http://repo.maven.apache.org/maven2/org/eclipse/core/resources/maven-metadata.xml

Downloading: http://repository.springsource.com/maven/bundles/external/org/eclipse/core/resources/maven-metadata.xml

Downloading: http://repository.springsource.com/maven/bundles/release/org/eclipse/core/resources/maven-metadata.xml

Downloading: https://oss.sonatype.org/content/repositories/snapshots/org/eclipse/core/resources/maven-metadata.xml

Why is that? Is Maven looking for updates in these repositories or is there another reason to download these metadata xmls often?

Answer 2

Your concern about being dependent on Internet connectivity is a valid one, but I don't think it's as bad as you think.

After a dependency is downloaded from the Central Repository, it is saved to a cache on your hard drive (located at "~/.m2/repository"). From then on, the copy in the cache is used and Internet connectivity is no longer required to compile your application.

When you compile your first project in Maven, it will have to download a crap-load of stuff. But after that, all subsequent compilations will go much faster and they won't need to download anything.

Also, Maven's versioning scheme makes it so that all "release" versions of a dependency cannot change once they are deployed to the Central repository. For example, if I'm using version "2.2" of "commons-io", I know that this version of the library will always stay the same. A change cannot be made without releasing a new version.

"Snapshot" versions, however, can change. If a library's version is a snapshot, then it will end in "-SNAPSHOT" (for example, "1.2-SNAPSHOT" means the library will eventually be released as "1.2"). I don't think the Central repository allows snapshot builds though. You shouldn't use them in production code anyway.

Answer 3

Answer to 1:

Yes you can, google for System-Scope dependencies, BUT: It is not a good idea to do this, because you will remove one of the key-features.

<dependency>
  <groupId>com.mycompany</groupId>
  <artifactId>app-lib</artifactId>
  <version>3.1.0</version>
  <scope>system</scope>
  <systemPath>${project.basedir}/libs/app-lib-3.1.0.jar</systemPath>
</dependency>

Answer to 2:

Yes you can: - Artifactory - Nexus

Answer to 3:

Yes you can. For that case you can use the ---offline flag OR better approach: release all dependencies.

Some thoughts: You want to use a dependecy-management system, without using dependency-management, sounds strange to mee.

If you fear, that changes within your libs may break your code, just don't use SNAPSHOTs. Try a kind of version scheme. We use

x.y.z

• if z changes in a release, the jar should be compatible.
• if y changes, you'll have to change youz code
• if x changes... well everthing needs to be renewed.