Como faço para forçar o Maven a usar meu repositório local em vez de ir para repositórios remotos para recuperar artefatos?

97

Estou usando o Maven 3.3.3 com Java 8 no Mac Yosemite. Tenho um projeto multi-módulo.

    <modules>
            <module>first-module</module>
            <module>my-module</module>
                …
    </modules>

Quando eu construo meu um dos meus módulos filho, por exemplo, “meu-módulo” acima, usando “instalação limpa mvn”, o build tenta baixar os artefatos do módulo filho de um repositório remoto que defini em meu ~ / .m2 Arquivo /settings.xml. A saída está abaixo

[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building my-module 87.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: http://download.java.net/maven/2/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml (788 B at 0.9 KB/sec)
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-20151104.200545-4.pom

Como faço para forçar o Maven a verificar meu repositório ~ / .m2 / local primeiro, antes de tentar fazer o download dos repositórios remotos? Abaixo está onde tenho meus repositórios remotos definidos no meu arquivo ~ / .m2 / settings.xml…

<profile>
    <id>releases</id>
    <activation>
        <property>
            <name>!releases.off</name>
        </property>
    </activation>
    <repositories>
        <repository>
            <id>releases</id>
            <url>https://my.remoterepository.com/nexus/content/repositories/releases/</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
    </repositories>
</profile>
<profile>
    <id>snapshots</id>
    <activation>
        <property>
            <name>!snapshots.off</name>
        </property>
    </activation>
    <repositories>
        <repository>
            <id>snapshots</id>
            <url>https://my.remoterepository.com/nexus/content/repositories/snapshots/</url>
            <releases>
                <enabled>false</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </repository>
    </repositories>
</profile>

Edit: Em resposta à resposta dizendo que o download ocorre quando o artefato não está lá, abaixo está a saída do terminal em que provo que o arquivo estava lá no meu repositório, mas o Maven está tentando baixá-lo mesmo assim ...

Daves-MacBook-Pro-2:my-module davea$ ls -al ~/.m2/repository/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-SNAPSHOT.jar 
-rw-r--r--  1 davea  staff  10171 Nov  5 10:22 /Users/davea/.m2/repository/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-SNAPSHOT.jar
Daves-MacBook-Pro-2:my-module davea$ mvn clean install
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.mainco.subco:my-module:jar:87.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-antrun-plugin @ org.mainco.subco:my-module:[unknown-version], /Users/davea/Documents/sb_workspace/my-module/pom.xml, line 678, column 12
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building my-module 87.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: http://download.java.net/maven/2/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml (788 B at 0.8 KB/sec)
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-20151106.043202-8.pom
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-   module-87.0.0-20151106.043202-8.pom (3 KB at 21.9 KB/sec)
Downloading: http://download.java.net/maven/2/org/mainco/subco/subco/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/subco/87.0.0-SNAPSHOT/maven-metadata.xml
maven  repository  maven-3  artifacts 
— Dave
fonte
2
Maven faz verificar o seu repositório local antes de tentar baixar um artefato de um repositório remoto. Tem certeza de que seu local tinha esses artefatos antes de tentar esta construção? Você pode inspecionar seu repositório local agora e tentar outra construção novamente de qualquer maneira. Além disso, você pode especificar onde está seu repositório local settings.xml(veja aqui ).
— mystarrocks
Embora eu não tenha especificado meu repositório no arquivo settings.xml, é o padrão que o Maven configurou para mim - ~ / .m2 / repository. Tenho que especificá-lo mesmo quando é o padrão?
— Dave
Para mim, existem outros arquivos em meus repositórios locais, como * .sha1 ou * .lastUpdate. excluir outros arquivos, exceto * .jar e * .pom, impedirá que o maven baixe novamente o arquivo do repositório remoto
— Harun

Respostas:

45

A dependência possui uma versão de instantâneo. Para instantâneos, o Maven irá verificar o repositório local e se o artefato encontrado no repositório local for muito antigo, ele tentará encontrar um atualizado nos repositórios remotos. Provavelmente é isso que você está vendo.

Observe que esse comportamento é controlado pela updatePolicydiretiva na configuração do repositório (que é dailypor padrão para repositórios de instantâneos).

— Andreas Veithen
fonte
16
É possível "sobrescrever" isso pelo argumento de comando do console? Como: mvn clean install -FORCE_COMMAND
— Naxos84
21
"Muito velho" significa o quê? Ele escolhe o instantâneo mais recente que pode encontrar, seja local ou remoto? Isso seria um comportamento horrível, com certeza. Se acabei de criar um instantâneo, realmente quero usar esse, não aquele que o CI construiu um momento depois.
— Tom Quarendon,
Explique mais sobre o que significa "Muito velho".
— Đỗ Công Bằng
32

Use mvn --helpe você pode ver a lista de opções.

Existe uma opção como -nsu,--no-snapshot-updates Suppress SNAPSHOT updates

Portanto, o comando de uso mvn install -nsupode forçar a compilação com o repositório local.

— Zheng Zhongqi
fonte
10
Você também pode usar -opara comportamento de maven "offline"
— Sean
8
A opção -nsu não impede que o mvn tente e falhe ao baixar um artefato remotamente se ainda não tiver sido baixado em vez de usar a construção local, como quando o artefato foi construído e instalado localmente. -
— user1767316
Eu tive o mesmo problema com um artefato que ainda não estava sendo baixado e isso corrigiu para mim: maven.apache.org/general.html#importing-jars
— Luigi Cristalli
15

Para realmente forçar o maven a usar apenas seu repositório local, você pode executar com mvn <goals> -o. O -omaven diz para deixá-lo trabalhar "offline" e permanecerá fora da rede.

— Sean
fonte
5
A opção -o não evita que o mvn tente e falhe ao baixar um artefato remotamente se ele ainda não tiver sido baixado em vez de usar a construção local como quando o artefato foi construído e instalado localmente.
— user1767316
2
isso é verdade - se você não tiver uma cópia local, você está sem sorte. Isso é útil para projetos que você construiu antes, mas potencialmente têm alterações recentes de SNAPSHOT com as quais você não se importa.
— Sean
Ou mesmo se você nunca construiu o projeto, você pode se preparar para ele ser construído off-line commvn dependency:go-offline
— Aldian
E se você tiver uma cópia local que acabou de instalar (para que nunca seja implantada / disponível no repo de instantâneo remoto)?
— Vivek Chavda
1
Ah, acabei de criar um projeto pom com uma coleção de dependências, mas não especifiquei <type> pom </type> no projeto de consumo, então ele estava procurando por um jar (e é claro não conseguia encontrar, mesmo no modo offline)
— Vivek Chavda de
4

No meu caso, tive um projeto multimódulo como você. Tive que alterar um ID de grupo de uma das bibliotecas externas do meu projeto, conforme mostrado abaixo.

De:

<dependencyManagement>
    <dependency>
        <groupId>org.thirdparty</groupId>
        <artifactId>calculation-api</artifactId>
        <version>2.0</version>
        <type>jar</type>
        <scope>provided</scope>
    </dependency>
<dependencyManagement>

Para:

<dependencyManagement>
   <dependency>
      <groupId>org.thirdparty.module</groupId>
        <artifactId>calculation-api</artifactId>
        <version>2.0</version>
        <type>jar</type>
        <scope>provided</scope>
    </dependency>
<dependencyManagement>

Preste atenção na seção <groupId>. Acontece que eu estava esquecendo de modificar a seção correspondente dos submódulos que definem essa dependência em seus arquivos pom.

Isso me deixou muito louco porque o módulo estava disponível localmente.

— Willa
fonte
4

Siga as etapas abaixo:

    1. Certifique-se de excluir todo o conteúdo da pasta jar localizada em seu local, exceto o jar que você deseja manter.
      Por exemplo, arquivos como .repositórios, .pom, .sha1, .lastUpdated etc.
    1. Execute o mvn clean install -ocomando

Isso ajudará a usar arquivos jar do repositório local em vez de se conectar a qualquer repositório.

— Madhu
fonte
1
Removendo apenas *.repositoriese *.sha1arquivos funcionou para mim
— DLight
2

A opção -o não funcionou para mim porque o artefato ainda está em desenvolvimento e ainda não foi carregado e o maven (3.5.x) ainda tenta baixá-lo do repositório remoto porque é a primeira vez, de acordo com o erro que recebo.

No entanto, isso corrigiu para mim: https://maven.apache.org/general.html#importing-jars

Após esta instalação manual, não há necessidade de usar a opção offline.

ATUALIZAR

Acabei de reconstruir a dependência e tive que importá-la novamente: o regular mvn clean installnão era suficiente para mim

— Luigi Cristalli
fonte
-1

O Maven sempre verifica seu repositório local primeiro, entretanto, sua dependência precisa ser instalada em seu repo para que o maven o encontre.

Execute primeiro mvn installem seu módulo de dependência e, em seguida, crie seu módulo dependente.

— Oliver
fonte
1
Editei minha pergunta para mostrar que o artefato está no repo (observe o comando "ls -al" que executo. No entanto, o Maven está tentando baixá-lo mesmo assim. Alguma outra ideia?
— Dave
5
@Oliver: está faltando o fato de que para artefatos no repositório local, o Maven ainda pode consultar os repositórios remotos se o artefato for um instantâneo muito antigo.
— Andreas Veithen
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.