O Maven2 está me deixando louco durante a fase de experimentação / maquete rápida e suja do desenvolvimento.

Eu tenho um pom.xmlarquivo que define as dependências para a estrutura de aplicativos da web que eu quero usar e posso gerar rapidamente projetos iniciais a partir desse arquivo. No entanto, às vezes eu quero vincular a uma biblioteca de terceiros que ainda não tenha um pom.xmlarquivo definido, então, em vez de criar o pom.xmlarquivo para a lib de terceiros manualmente, instalá-lo e adicioná-lo à dependência pom.xml, gostaria de para dizer ao Maven: "Além das minhas dependências definidas, inclua os frascos que também estiverem /lib".

Parece que isso deveria ser simples, mas se for, estou perdendo alguma coisa.

Quaisquer sugestões sobre como fazer isso são muito apreciadas. Além disso, se houver uma maneira simples de apontar para um /libdiretório e criar facilmente um pom.xmlcom todos os frascos fechados mapeados para uma única dependência que eu poderia nomear / instalar e vincular de uma só vez, também seria suficiente.

Problemas de abordagens populares

A maioria das respostas encontradas na Internet sugere que você instale a dependência no seu repositório local ou especifique um escopo de "sistema" no pome distribua a dependência com a fonte do seu projeto. Mas essas duas soluções são realmente falhas.

Por que você não deve aplicar a abordagem "Instalar no repositório local"

Quando você instala uma dependência em seu repositório local, ela permanece lá. Seu artefato de distribuição funcionará bem desde que tenha acesso a este repositório. O problema é que, na maioria dos casos, esse repositório residirá em sua máquina local, portanto não haverá maneira de resolver essa dependência em qualquer outra máquina. Claramente, fazer com que seu artefato dependa de uma máquina específica não é uma maneira de lidar com as coisas. Caso contrário, essa dependência precisará ser instalada localmente em todas as máquinas que trabalham com esse projeto, o que não é melhor.

Por que você não deve aplicar a abordagem "System Scope"

Os jars dos quais você depende com a abordagem "System Scope" não são instalados em nenhum repositório ou anexados aos seus pacotes de destino. É por isso que seu pacote de distribuição não terá uma maneira de resolver essa dependência quando usado. Acredito que esse foi o motivo pelo qual o uso do escopo do sistema ficou obsoleto. De qualquer forma, você não deseja confiar em um recurso obsoleto.

A solução estática de repositório no projeto

Depois de colocar isso no seu pom:

<repository>
    <id>repo</id>
    <releases>
        <enabled>true</enabled>
        <checksumPolicy>ignore</checksumPolicy>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
    <url>file://${project.basedir}/repo</url>
</repository>

para cada artefato com um ID de grupo do formulário, o x.y.zMaven incluirá o seguinte local dentro do diretório do projeto em sua busca por artefatos:

repo/
| - x/
|   | - y/
|   |   | - z/
|   |   |   | - ${artifactId}/
|   |   |   |   | - ${version}/
|   |   |   |   |   | - ${artifactId}-${version}.jar

Para elaborar mais sobre isso, você pode ler esta postagem do blog .

Use o Maven para instalar para projetar repo

Em vez de criar essa estrutura manualmente, recomendo usar um plug-in Maven para instalar seus jars como artefatos. Portanto, para instalar um artefato em um repositório no projeto na repopasta, execute:

mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]

Se você escolher essa abordagem, poderá simplificar a declaração do repositório em pom:

<repository>
    <id>repo</id>
    <url>file://${project.basedir}/repo</url>
</repository>

Um script auxiliar

Como executar o comando de instalação para cada biblioteca é meio irritante e definitivamente propenso a erros, eu criei um script utilitário que instala automaticamente todos os jars de uma libpasta para um repositório de projetos, enquanto resolve automaticamente todos os metadados (groupId, artifactId e etc.) de nomes de arquivos. O script também imprime as dependências xml para você copiar e colar no seu pom.

Inclua as dependências no seu pacote de destino

Quando você criar seu repositório no projeto, terá resolvido um problema de distribuição das dependências do projeto com sua origem, mas desde então o artefato de destino do seu projeto dependerá de jarros não publicados, portanto, quando você instalar para um repositório, ele terá dependências não resolvíveis.

Para superar esse problema, sugiro incluir essas dependências no pacote de destino. Isso você pode fazer com o Plug - in Assembly ou melhor com o Plug-in OneJar . A documentação oficial do OneJar é fácil de entender.

Apenas para jogar fora o código

defina o sistema scope == e apenas crie um groupId, artifactId e version

<dependency>
    <groupId>org.swinglabs</groupId>
    <artifactId>swingx</artifactId>
    <version>0.9.2</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/swingx-0.9.3.jar</systemPath>
</dependency>

Nota: as dependências do sistema não são copiadas no jar / war resultante
(consulte Como incluir dependências do sistema na guerra criada usando o maven )

Você pode criar um repositório local no seu projeto

Por exemplo, se você possui uma libspasta na estrutura do projeto

• Na libspasta, você deve criar uma estrutura de diretórios como:/groupId/artifactId/version/artifactId-version.jar

• No seu pom.xml, você deve registrar o repositório

  <repository>
      <id>ProjectRepo</id>
      <name>ProjectRepo</name>
      <url>file://${project.basedir}/libs</url>
  </repository>
  

• e adicione dependência como de costume

  <dependency>
      <groupId>groupId</groupId>
      <artifactId>artifactId</artifactId>
      <version>version</version>
  </dependency>
  

Isso é tudo.

Para obter informações detalhadas: Como adicionar bibliotecas externas no Maven

Nota: Ao usar o escopo do sistema ( conforme mencionado nesta página ), o Maven precisa de caminhos absolutos.

Se seus jars estiverem na raiz do seu projeto, você deverá prefixar os valores systemPath com $ {basedir}.

Isto é o que eu fiz, ele também resolve o problema do pacote e funciona com o código do check-out.

Criei uma nova pasta no projeto, no meu caso, usei repo, mas fique à vontade para usarsrc/repo

No meu POM, eu tinha uma dependência que não está em nenhum repositório público de máquinas

<dependency>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <version>1.0.1</version>
    <scope>runtime</scope>
</dependency>

Criei os seguintes diretórios repo/com/dovetail/zoslog4j/1.0.1e copiei o arquivo JAR para essa pasta.

Eu criei o seguinte arquivo POM para representar o arquivo baixado (esta etapa é opcional, mas remove um AVISO) e ajuda o próximo cara a descobrir onde eu peguei o arquivo.

<?xml version="1.0" encoding="UTF-8" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <packaging>jar</packaging>
    <version>1.0.1</version>
    <name>z/OS Log4J Appenders</name>
    <url>http://dovetail.com/downloads/misc/index.html</url>
    <description>Apache Log4j Appender for z/OS Logstreams, files, etc.</description>
</project>

Dois arquivos opcionais que eu crio são as somas de verificação SHA1 para o POM e o JAR para remover os avisos de soma de verificação ausentes.

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar.sha1

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom.sha1

Finalmente, adiciono o seguinte fragmento ao meu pom.xml, que me permite consultar o repositório local

<repositories>
    <repository>
        <id>project</id>
        <url>file:///${basedir}/repo</url>
    </repository>
</repositories>

Você realmente deve implementar uma estrutura através de um repositório e identificar suas dependências antecipadamente. Usar o escopo do sistema é um erro comum que as pessoas usam, porque "não se importam com o gerenciamento de dependências". O problema é que, ao fazer isso, você acaba com uma construção pervertida do maven que não mostrará o maven em condições normais. Você seria melhor seguir uma abordagem como esta .

É assim que adicionamos ou instalamos um jar local

    <dependency>
        <groupId>org.example</groupId>
        <artifactId>iamajar</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/lib/iamajar.jar</systemPath>
    </dependency>

Eu dei alguns groupId padrão e artifactId porque eles são obrigatórios :)

O plug - in de instalação do Maven possui uso de linha de comando para instalar um jar no repositório local; o POM é opcional, mas você precisará especificar o GroupId, ArtifactId, Version e Packaging (todos os itens do POM).

Usar <scope>system</scope>é uma péssima idéia por motivos explicados por outros, instalar o arquivo manualmente no repositório local torna a compilação improdutível e usar <url>file://${project.basedir}/repo</url>também não é uma boa ideia porque (1) pode não ser uma fileURL bem formada (por exemplo, se o projeto é verificado em um diretório com caracteres incomuns), (2) o resultado é inutilizável se o POM deste projeto for usado como uma dependência do projeto de outra pessoa.

Supondo que você não esteja disposto a carregar o artefato em um repositório público, a sugestão de Simeon de um módulo auxiliar faz o trabalho. Mas existe uma maneira mais fácil agora ...

A Recomendação

Use non-maven-jar-maven-plugin . Faz exatamente o que você estava pedindo, sem nenhuma das desvantagens das outras abordagens.

Eu encontrei outra maneira de fazer isso, veja aqui em um post do Heroku

Para resumir (desculpe por copiar e colar)

• Crie um repodiretório na sua pasta raiz:

seu projecto
+ - pom.xml
+ - src
+ - repo

• Execute isso para instalar o jar no diretório de repositório local

mvn deploy: deploy-file -Durl = file: /// caminho / para / yourproject / repo / -Dfile = mylib-1.0.jar -DgroupId = com.example -DartifactId = mylib -Dpackaging = jar -Dversion = 1.0

• Adicione este seu pom.xml:

<repositories>
    <!--other repositories if any-->
    <repository>
        <id>project.local</id>
        <name>project</name>
        <url>file:${project.basedir}/repo</url>
    </repository>
</repositories>


<dependency>
    <groupId>com.example</groupId>
    <artifactId>mylib</artifactId>
    <version>1.0</version>  
</dependency>

Depois de uma longa discussão com o pessoal do CloudBees sobre o empacotamento adequado desse tipo de JARs, eles fizeram uma boa proposta interessante para uma solução:

Criação de um projeto Maven falso que anexa um JAR preexistente como um artefato primário, executando a instalação do POM pertencente: execução do arquivo install. Aqui está um exemplo desse kinf do POM:

 <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <version>2.3.1</version>
            <executions>
                <execution>
                    <id>image-util-id</id>
                    <phase>install</phase>
                    <goals>
                        <goal>install-file</goal>
                    </goals>
                    <configuration>
                        <file>${basedir}/file-you-want-to-include.jar</file>
                        <groupId>${project.groupId}</groupId>
                        <artifactId>${project.artifactId}</artifactId>
                        <version>${project.version}</version>
                        <packaging>jar</packaging>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Mas, para implementá-lo, a estrutura existente do projeto deve ser alterada. Primeiro, você deve ter em mente que, para cada tipo de JAR, deve ser criado um projeto falso diferente do Maven (módulo). E deve ser criado um projeto Maven pai, incluindo todos os submódulos que são: todos os wrappers JAR e o projeto principal existente. A estrutura pode ser:

projeto raiz (este contém o arquivo POM pai inclui todos os submódulos com elemento XML do módulo ) (empacotamento POM)

Projeto filho do Maven do wrapper JAR 1 (empacotamento POM)

Projeto filho do Maven do wrapper JAR 2 (embalagem POM)

principal projeto filho existente do Maven (WAR, JAR, EAR .... embalagem)

Quando o pai executando através do mvn: install ou mvn: o empacotamento é forçado e os submódulos serão executados. Isso pode ser considerado um ponto negativo aqui, já que a estrutura do projeto deve ser alterada, mas oferece uma solução não estática no final

O que me parece mais simples é apenas configurar o plugin maven-compiler-plugin para incluir seus jars personalizados. Este exemplo carregará qualquer arquivo jar em um diretório lib.

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <includes>
                    <include>lib/*.jar</include>
                </includes>
            </configuration>
        </plugin>

O problema systemPathé que os frascos das dependências não serão distribuídos pelos seus artefatos como dependências transitivas. Experimente o que eu publiquei aqui: É melhor Mavenize seus arquivos jar do projeto ou colocá-los em WEB-INF / lib?

Em seguida, declare as dependências como de costume.

E leia a nota de rodapé.

Uma solução estranha que encontrei:

usando o Eclipse

• criar projeto java simples (não-maven)
• adicionar uma classe principal
• adicione todos os frascos ao caminho de classe
• exportar JAR Runnable (é importante, porque não há outra maneira de fazê-lo)
• selecione Extrair bibliotecas necessárias no JAR gerado
• decidir os problemas de licença
• tadammm ... instale o jar gerado no seu m2repo
• adicione essa dependência única aos seus outros projetos.

Saúde, Balint

Se você deseja uma solução rápida e suja, pode fazer o seguinte (embora eu não recomende isso para nada além de projetos de teste, o maven reclamará por muito tempo que isso não é apropriado).

Adicione uma entrada de dependência para cada arquivo jar necessário, de preferência com um script perl ou algo semelhante e copie / cole-o no seu arquivo pom.

#! /usr/bin/perl

foreach my $n (@ARGV) {

    $n=~s@.*/@@;

    print "<dependency>
    <groupId>local.dummy</groupId>
    <artifactId>$n</artifactId>
    <version>0.0.1</version>
    <scope>system</scope>
    <systemPath>\${project.basedir}/lib/$n</systemPath>
</dependency>
";

Uma solução em lote rápida e suja (com base na resposta de Alex):

libs.bat

@ECHO OFF
FOR %%I IN (*.jar) DO (
echo ^<dependency^>
echo ^<groupId^>local.dummy^</groupId^>
echo ^<artifactId^>%%I^</artifactId^>
echo ^<version^>0.0.1^</version^>
echo ^<scope^>system^</scope^>
echo ^<systemPath^>${project.basedir}/lib/%%I^</systemPath^>
echo ^</dependency^>
)

Executá-lo como este: libs.bat > libs.txt. Em seguida, abra libs.txte copie seu conteúdo como dependências.

No meu caso, eu só precisava das bibliotecas para compilar meu código, e essa solução foi a melhor para esse fim.

Mesmo que não se ajuste exatamente ao seu problema, deixarei isso aqui. Meus requisitos eram:

1. Os frascos que não podem ser encontrados em um repositório online do maven devem estar no SVN.
2. Se um desenvolvedor adicionar outra biblioteca, os outros desenvolvedores não deverão se preocupar em instalá-los manualmente.
3. O IDE (NetBeans no meu caso) deve ser capaz de encontrar as fontes e os javadocs para fornecer preenchimento automático e ajuda.

Vamos falar sobre (3) primeiro: apenas ter os jars em uma pasta e, de alguma forma, mesclá-los no jar final, não funcionará aqui, pois o IDE não entenderá isso. Isso significa que todas as bibliotecas precisam ser instaladas corretamente. No entanto, não quero que todos o instalem usando "mvn install-file".

No meu projeto, eu precisava de metawidget. Aqui vamos nós:

1. Crie um novo projeto maven (nomeie "shared-libs" ou algo parecido).
2. Faça o download do metawidget e extraia o zip para src / main / lib.
3. A pasta doc / api contém os javadocs. Crie um zip do conteúdo (doc / api / api.zip).
4. Modifique o pom assim
5. Crie o projeto e a biblioteca será instalada.
6. Adicione a biblioteca como uma dependência ao seu projeto ou (se você incluiu a dependência no projeto de bibliotecas compartilhadas) adicione bibliotecas compartilhadas como dependência para obter todas as bibliotecas de uma só vez.

Toda vez que você tiver uma nova biblioteca, basta adicionar uma nova execução e solicitar a todos que construam o projeto novamente (você pode melhorar esse processo com hierarquias do projeto).

Para instalar o jar de terceiros que não está no repositório maven, use maven-install-plugin.

Abaixo estão as etapas:

1. Faça o download do arquivo jar manualmente a partir da fonte (site)
2. Crie uma pasta e coloque seu arquivo jar nela
3. Execute o comando abaixo para instalar o jar de terceiros no seu repositório maven local

Instalação do mvn: install-file -Dfile = -DgroupId = -DartifactId = -Dversion = -Dpackaging =

Abaixo está o exemplo que usei para o simonsite log4j

mvn install: install-file -Dfile = / Usuários / athanka / git / MyProject / repo / log4j-rolling-appender.jar -DgroupId = uk.org.simonsite -DartifactId = log4j-rolling-appender -Dversion = 20150607-2059 - Dpackaging = jar

4. No pom.xml, inclua a dependência conforme abaixo

     <dependency> 
           <groupId>uk.org.simonsite</groupId>
           <artifactId>log4j-rolling-appender</artifactId>
           <version>20150607-2059</version> 
     </dependency>

5. Execute o comando mvn clean install para criar sua embalagem

Abaixo está o link de referência:

https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html

Para aqueles que não encontraram uma boa resposta aqui, é isso que estamos fazendo para obter um jar com todas as dependências necessárias. Esta resposta ( https://stackoverflow.com/a/7623805/1084306 ) menciona o uso do plug-in Maven Assembly, mas na verdade não fornece um exemplo na resposta. E se você não ler todo o caminho até o final da resposta (é bastante demorado), poderá perder. Adicionar o seguinte ao seu pom.xml irá gerartarget/${PROJECT_NAME}-${VERSION}-jar-with-dependencies.jar

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>2.4.1</version>
            <configuration>
                <!-- get all project dependencies -->
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <!-- MainClass in mainfest make a executable jar -->
                <archive>
                  <manifest>
                    <mainClass>my.package.mainclass</mainClass>
                  </manifest>
                </archive>

            </configuration>
            <executions>
              <execution>
                <id>make-assembly</id>
                <!-- bind to the packaging phase -->
                <phase>package</phase> 
                <goals>
                    <goal>single</goal>
                </goals>
              </execution>
            </executions>
        </plugin>

Eu aludi a algum código python em um comentário à resposta do @alex lehmann's, então estou postando aqui.

def AddJars(jarList):
  s1 = ''
  for elem in jarList:
   s1+= """
     <dependency>
        <groupId>local.dummy</groupId>
        <artifactId>%s</artifactId>
        <version>0.0.1</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/manual_jars/%s</systemPath>
     </dependency>\n"""%(elem, elem)
  return s1

Isso não responde como adicioná-los ao seu POM, e pode ser um acéfalo, mas apenas adicionaria o diretório lib ao seu trabalho de caminho de classe? Sei que é isso que faço quando preciso de um jar externo que não queira adicionar aos meus repositórios do Maven.

Espero que isto ajude.

O que funciona em nosso projeto é o que Archimedes Trajano escreveu, mas tínhamos em .m2 / settings.xml algo como isto:

 <mirror>
  <id>nexus</id>
  <mirrorOf>*</mirrorOf>
  <url>http://url_to_our_repository</url>
 </mirror>

e o * deve ser alterado para central. Portanto, se a resposta dele não funcionar para você, verifique suas configurações.xml

Eu só queria uma solução rápida e suja ... Não consegui executar o script de Nikita Volkov: erro de sintaxe + requer um formato estrito para os nomes dos jar.

Eu criei esse script Perl que funciona com qualquer formato para os nomes de arquivos jar e gera as dependências em um xml para que possa ser copiado e colado diretamente em um pom.

Se você deseja usá-lo, certifique-se de entender o que o script está fazendo, talvez seja necessário alterar a libpasta e o valor para o groupIdou artifactId...

#!/usr/bin/perl

use strict;
use warnings;

open(my $fh, '>', 'dependencies.xml') or die "Could not open file 'dependencies.xml' $!";
foreach my $file (glob("lib/*.jar")) {
    print "$file\n";
    my $groupId = "my.mess";
    my $artifactId = "";
    my $version = "0.1-SNAPSHOT";
    if ($file =~ /\/([^\/]*?)(-([0-9v\._]*))?\.jar$/) {
        $artifactId = $1;
        if (defined($3)) {
            $version = $3;
        }
        `mvn install:install-file -Dfile=$file -DgroupId=$groupId -DartifactId=$artifactId -Dversion=$version -Dpackaging=jar`;
        print $fh "<dependency>\n\t<groupId>$groupId</groupId>\n\t<artifactId>$artifactId</artifactId>\n\t<version>$version</version>\n</dependency>\n";
        print " => $groupId:$artifactId:$version\n";
    } else {
        print "##### BEUH...\n";
    }
}
close $fh;

A solução para a abordagem scope = 'system' em Java:

public static void main(String[] args) {
        String filepath = "/Users/Downloads/lib/";
        try (Stream<Path> walk = Files.walk(Paths.get(filepath))) {

        List<String> result = walk.filter(Files::isRegularFile)
                .map(x -> x.toString()).collect(Collectors.toList());

                String indentation = "    ";
                for (String s : result) {
                    System.out.println(indentation + indentation + "<dependency>");
                    System.out.println(indentation + indentation + indentation + "<groupId>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</groupId>");
                    System.out.println(indentation + indentation + indentation + "<artifactId>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</artifactId>");
                    System.out.println(indentation + indentation + indentation + "<version>"
                            + s.replace(filepath, "").replace(".jar", "")
                            + "</version>");
                    System.out.println(indentation + indentation + indentation + "<scope>system</scope>");
                    System.out.println(indentation + indentation + indentation + "<systemPath>" + s + "</systemPath>");
                    System.out.println(indentation + indentation + "</dependency>");
                }

    } catch (IOException e) {
        e.printStackTrace();
    }
}