Dicas para manter um repositório interno Maven?

Question

Estou interessado em manter um Maven 2 repositório para minha organização. Quais são os alguns dos ponteiros e armadilhas que poderiam ajudar.

O que são as orientações para os usuários a seguir ao configurar padrões para download a partir de ou publicar seus próprios artefatos para o repositório ao liberar seu código? Que tipos de governança / regras que você tem no lugar para este tipo de coisa? O que você incluir sobre isso no guia / documentação do desenvolvedor?

Atualizar : Nós levantou-se Nexus e têm sido muito feliz com isso - seguido a maioria das diretrizes do Sal e não tive nenhum problema. Além disso, temos acesso restrito implantar e automatizado build / implantação de artefatos de instantâneo através de um servidor Hudson CI. Hudson possa analisar todas as montante / dependências do projeto a jusante, por isso, se um problema de compilação, falha no teste, ou alguma outra violação faz com que o acúmulo de quebrar, nenhuma implantação ocorrerá. Seja cansado de fazer implantações instantâneo em Maven2 / Maven3, como os metadados mudou entre as duas versões. O "único Hudson" estratégia de implantação snapshot irá atenuar isso. Nós não utilizar o plugin Release, mas ter escrito algum encanamento em torno dos versões plug-in quando indo para mover um instantâneo para liberação. Nós também usamos m2eclipse e parece funcionar muito bem com Nexus, a partir de arquivo de configurações pode ver Nexus e sabe a informação do índice artefato para pesquisa de lá. (Embora eu tive que ajustar algumas dessas configurações para tê-lo índice plenamente os nossos snapshots internos.) Eu também recomendo que você implantar um frasco fonte com seus artefatos como uma prática padrão, se você estiver interessado em fazer isso. Nós configurar isso em um super POM.

UPDATE2 : noreferrer eu me deparei este Sonatype whitepaper que detalha diferentes estágios de adoção / maturidade, cada um com diferentes objetivos de uso para um gerente de repositório Maven.

Answer 1

Eu recomendaria a criação de um servidor nexo com pelo menos quatro repositórios. Eu não recomendaria artifactory. A versão gratuita do nexo é perfeitamente bem para uma equipe de desenvolvimento inferior a 20 em menos de três grupos. Se você tem mais usuários do que isso, faça um favor e pagar para a liberação Sonatype. A integração LDAP paga por si mesmo.

1. Release Interno
2. Snapshot Interno
3. 3rd Party Interno para o código usado em casa que vem de fontes externas, ou para versões 3rd party endossados. Coloque o JDBC motoristas, javax. * Coisas e coisas de clientes e parceiros aqui.
4. Proxies Externa procuração comum para todas as fontes habituais como m2, codehaus etc

Configurar o Nexus fazer o seguinte para repos Interno

1. Snapshots velhos Excluir em intervalos regulares
2. Snapshots Excluir no lançamento
3. arquivos de índice de construção. Isso acelera constrói local também

Tenha um arquivo settings.xml comum que usa esses quatro e apenas estas quatro fontes. Se você precisa para personalizar além desta tentativa de manter um parte comum dos ajustes processo e utilização perfis para as diferenças. não deixe que seus clientes apenas rolar suas próprias configurações ou você vai acabar com código que constrói em uma máquina, mas não em qualquer outra máquina.

Fornecer um proxy comum para seus clientes. Em Nexus, você pode adicionar um monte de proxies para as fontes Maven comuns (Apache, JBoss, Codehaus) e têm um único proxy expostos aos clientes internos . Isso faz com que adicionar e remover fontes de seus clientes muito mais fácil.

Não misture Interno e artefatos 3rd party no mesmo repositório. Nexus permite que você adicione frascos para um repositório interno através de um gui web. Eu recomendo este como a maneira de adicionar seus drivers JDBC e outro código externo para 3rd party. A interface é bastante agradável de usar quando comparado com a maioria software empresarial .

Definir um POM pai comum que define os instantâneos e libertação repos interno através da tag distributionManagement . Eu sei que muitas pessoas dizer-lhe para não fazer isso. E enquanto Admito que existem todos os tipos de problemas com isso, ele funciona bem se os clientes só estará construindo releases e snapshots a ser implantado em um único repositório interno.

Se você tem uma existentes mis de gestão Maven repositório , criar um 5º repos chamado legados e colocar toda a repos lá. Configurar uma tarefa cron para apagar arquivos antigos do legado uma vez que eles são um ano de idade. Isso dá a todos um ano para mover fora dele e atualizar seus poms.

Estabelecer um fácil de furar a convenção de nomenclatura para artefatos internos. Eu prefiro GroupID de Department.Function.Project e um ArtifactId para que componentName . Para repositórios internos, com / org / net eo nome da empresa são susceptíveis de ser irrelevante. E errado se a empresa muda seu nome. É muito menos provável que as vendas, contabilidade ou departamento de inventário será renomeado.

Answer 2

Nexus . : P

Eu usei tanto Nexus e Artifactory. A interface para o Nexus é muito mais robusto, é muito mais configurável, e, claro, escrito por Sonatype , que repesents praticamente tudo Maven bem.

Dito isto, Artifactory é decente e viável.

• Uma revisão de Nexus vs. Artifactory
• Oh meu! Claro, aqui está uma quesiton SO sobre o assunto.
• Sonatype faz uma comparação de recursos
• jFrog (fabricante de Artifactory) faz uma comparação de recursos

Answer 3

Use Artifactory .

Answer 4

Eu estou usando Artifactory mim mesmo, e amo a interface do usuário e facilidade de implementação / manutenção. Dito isto, eu nunca usei Nexus, e não pode realmente ajudá-lo com uma comparação de recursos adequada.

Aqui estão algumas coisas em cima da minha cabeça que eu realmente gosto sobre Artifactory (tenha em mente Nexus pode ter esses recursos também):

1. Interface agradável Web 2.0.
2. A capacidade de importar seu repositório local Maven para ajudar você a começar.
3. facilidade de integração com servidores LDAP existentes para a segurança (eu sou um grande fã de um único repositório para armazenar credenciais).

Tendo em conta que não há realmente apenas dois implementação grande repositório Maven lá fora, se você realmente quer ter certeza de que você fez a escolha certa, eu recomendo a tentar ambos para fora, e decidir por si mesmo qual você gosta mais.

Answer 5

Talvez isso é óbvio, mas, para a reprodutibilidade, os desenvolvedores devem artefatos Nunca substituir, eles devem ser novas versões.

Isto também se aplica para montante repositórios. Se você baixar apache-commons versão 1.2.3, você deve realmente não baixá-lo novamente. Correções vêm de últimas versões, não aplicado a versões existentes.

Answer 6

Outra coisa a considerar:

http://archiva.apache.org/

Answer 7

Como o PERGUNTA ORIGINAL (questões técnicas a considerar ao construir um repositório M2), eu recomendaria a criação de utilizador só de leitura para navegar o repositório e usuário administrativo por administrador (que dizia: uma leitura user -apenas para todos aqueles usuários que não são administradores). Além disso, eu recomendaria a geração de imagens de backup periodicamente (uma vez por dia, talvez?). Muito importante tanto se o seu repositório é grande ou instalar seus próprios artefatos ao longo do tempo.

Por último, mas não menos importante, ao adicionar novos repositórios remotos, você deve adicionar filtros de inclusão / exclusão para que uma pesquisa de artefato no repositório seria feito mais rapidamente.

Existem muitas outras questões a considerar, mas estas são as questões principais que eu encontrei enquanto gerencia um repositório interno Maven.

Para o registro, eu estou usando tanto Nexus e Artifactory; Eu posso indicar claramente que enquanto Nexus é muito simples e operativa (embora às vezes tenho problemas com o processo de instalação no Ubuntu), sua versão gratuita não pode competir com a comunidade de Artifactory edição (gratuito). incrível web 2 UI de Excluindo Artifactory, suas principais características, tais como gerenciamento de segurança, backups periódicos, e as questões de acessibilidade estão muito além daqueles de Nexus.