Multi-Suporte a IDE em Java para uma equipe

Question

Qual é a melhor maneira de permitir que uma equipe de programadores para usar o NetBeans, Eclipse e IntelliJ no mesmo projeto, eliminando assim a "que IDE é melhor" a questão.

Quais arquivos devem ou não ser verificado no controle de código fonte?

Answer 1

Eu acho que a melhor maneira é fazer o independente processo de construção de IDE. Isso significa que o seu projecto não deve confiar em quaisquer arquivos específicos do IDE para construir, mas sim usar um sistema de compilação externo, como Apache Maven , Apache Ant , ou até mesmo fazer ou scripts personalizados. Maven é suportado por mais popular Java IDEs, diretamente ou através de plug-ins.

Se você não quiser usar um sistemas de compilação externos, você deve pelo menos fazer o projeto como fácil de configurar quanto possível (ou seja, por ter pastas padrão para bibliotecas compartilhadas e outras dependências). Quando eu tiver trabalhando em equipes com vários IDEs no passado, eu passei por muito mais tempo na resolução de dependências como os pré-requisitos para a construção do projeto mudou ao longo do tempo. No pior caso, você pode até mesmo acabar com os desenvolvedores não se preocupar em obter a última versão do repositório de controle de versão, uma vez que eles acham que a criação do novo projeto é como um aborrecimento.

Se o seu projeto tem muitas dependências da biblioteca, eu acho que é uma boa idéia para torná-los disponíveis em forma binária no repositório de controle de versão. Dessa forma, as pessoas não têm para resolver todas as dependências das dependências e assim por diante apenas para construir um único projeto. Isso, contudo, exigir que você tem alguém responsável por manter os binários "oficiais" up-to-date sempre que mudar. (Esta é praticamente a mesma filosofia utilizada pelo repositório Maven, mas os princípios podem ser aplicados manualmente mesmo quando não estiver usando Maven.)

Answer 2

Bem, essa é uma pergunta bastante auto-atendimento.

Os arquivos não verificar em controle de origem são arquivos que têm a ver com os IDEs si mesmos.

Deixe isso para os desenvolvedores para gerar esses arquivos.

Se você usar o Maven, pode gerar os arquivos como .project e .classpath do Eclipse para você. Eclipse em geral é muito fácil de usar com uma estrutura de arquivo básico (com a nova opção Java Project).

Eu acho que Maven tem suporte Netbeans bem, não tenho certeza sobre IntelliJ embora.

site da Maven é maven.apache.org .

Answer 3

Para cada IDE que tem mais de um desenvolvedor, check-in-todos os arquivos de suporte. Por que re-inventar a roda em cada mesa de trabalho.

Eu tenho feito isso com muitas IDEs diferentes, e eu ainda tenho que ver um conflito nome de arquivo.

Na verdade, mesmo quando apenas um único desenvolvedor usa um IDE particular, é para seu / sua vantagem para a versão dos arquivos de apoio, para a mesma razão que você versão os outros arquivos em seu ambiente de desenvolvimento: história, diffing, comentários , etc.

Answer 4

Para Eclipse, que seria .classpath e .project.

A minha equipe usa Maven, e os desenvolvedores são desencorajados de check-in arquivos específicos do Eclipse. Porque eles podem ser gerados a partir Maven, esses arquivos são redundantes.

Além disso, verificando arquivos específicos do projeto parece que ele iria economizar tempo, mas, geralmente, acaba sendo uma dor por causa de variações nas estações de trabalho diferentes dos desenvolvedores, resultando em desperdício de tempo resolver conflitos nos arquivos específicos do IDE. A única maneira de contornar isso é a força de todos para configurar seu ambiente da mesma forma, o que vai contra a abordagem IDE-agnóstico.

Answer 5

Existem muitas considerações ao usar vários conjuntos de ferramentas dentro da mesma equipe do projeto. Por exemplo, a minha equipa tem desenvolvedores Java usando a maior parte do front-end desenvolvedores (JSP / CSS / HTML) IntelliJ e usando eclipse. Estamos no processo de migração dos usuários do Eclipse para IntelliJ por causa de alguns plugins IntelliJ que desenvolvemos que fornecem suporte estendido para o nosso ambiente. Nós não estamos indo para desenvolver os plugins para múltiplas plataformas, por isso estamos padronizando o IntelliJ em toda a linha.

Em termos de arquivos específicos, posso falar com IntelliJ. Temos verificado em nossos arquivos .ipr e nossos arquivos .iml. Não check-in arquivos .iws. Se você também tem usuários do Eclipse, configure seu projeto IntelliJ para ler / informações de dependência loja no arquivo .classpath e comprometer isso a seu VCS.

Answer 6

Nós intencionalmente suportar múltiplos IDEs do mesmo repositório SVN. Nosso pensamento era que nós queremos garantir que, se uma nova pessoa se juntou à equipe ou alguém teve que começar a trabalhar em uma nova máquina, que queria que eles fossem capazes de fazer o checkout da base de código, importá-lo para o IDE e imediatamente ter um Work- configuração de poder.

O que isto significa na extremidade desenvolvedor é que eles não devem commit suas alterações nos arquivos IDE. Tudo o resto (por exemplo, src, teste, lib e assim por diante) torna-se o conjunto que normalmente atualizar e comprometer todos os dias.

O outro benefício é que temos completamente eliminado as guerras IDE aqui: Netbeans e Eclipse pessoas vivem em perfeita harmonia (olhando de soslaio para as pessoas IntelliJ, mas hey ...; -)

.

Answer 7

Para mais comentários e respostas sobre este tema, consulte esta pergunta (Como você lida com diferentes Java IDEs e svn?)

Answer 8

Nós renomear nossos arquivos IDE para check-in com um .deletethis extensão extra ou similar. Quando uma nova pessoa verifica o projeto, eles simplesmente retirar a extensão extra e é bom para ir. Desta forma, os conflitos de controle de origem evitar com os arquivos do projeto como pessoas ajustar seus ambientes. E você não precisa se preocupar com formação de novos desenvolvedores para não verificar nesses arquivos.

Answer 9

Normalmente, eu consideraria isso uma má idéia. Eu não tenho certeza que tipo de ambiente é (talvez open source?), Mas seria realmente sugar para suportar múltiplos IDEs. Uma coisa que eu recomendo, se isso for inevitável, seria padronizar seu constrói em scripts ant. Se você tem um grande conjunto de dependências, esta pode ser a maneira mais fácil de obter uma compilação previsível em todas as plataformas.

Se um dos IDEs passa a ser RAD (baseado em eclipse), há uma pasta inteira .settings chamado que você não gostaria de incluir no SCM.