Como você lida com diferentes IDEs Java e SVN?

Question

Como você garante que pode fazer check-out do código no Eclipse ou NetBeans e trabalhar lá com ele?

Editar:Se você não fizer o check-in dos arquivos relacionados ao ide, será necessário reconfigurar o buildpath, as inclusões e tudo mais, sempre que fizer o check-out do projeto.Não sei se o ant (especialmente um arquivo de construção ant que é criado/exportado do Eclipse) funcionará perfeitamente com outro ide.

Answer 1

A resposta espertinho é "ao fazê-lo" - a menos que você não está trabalhando com vários IDEs que você não sabe se você está realmente preparado para trabalhar com vários IDEs. Honesto. :)

Eu sempre vi várias plataformas como mais complicado, pois eles podem usar diferentes padrões de codificação (por exemplo, o Windows pode padrão para ISO-8859-1, Linux para UTF-8) - para mim codificação tem causado muito mais problemas do que IDEs.

Alguns mais ponteiros:

• Você pode querer ir com Maven ( http://maven.apache.org ), deixe-o gerar arquivos específicos IDE e nunca cometê-los ao controle de origem.
• A fim de ter certeza de que você está gerando os artefatos corretas, você deve ter uma compilação servidor dedicado suas entregas (por exemplo cruisecontrol), seja com a ajuda de formiga, perito ou qualquer outra ferramenta. Estes resultados são aqueles que são testados fora de máquinas de desenvolvimento. Grande maneira de fazer as pessoas conscientes de que existe um outro mundo fora da sua própria máquina.
• Proibir qualquer caminho máquina específica para ser contido em qualquer arquivo IDE específico encontrado no controle de origem. Sempre referenciar bibliotecas externas por nomes de caminhos lógicos, de preferência contendo a sua versão (se você não usar maven)

Answer 2

Na verdade, manter um Netbeans e um projeto Eclipse para o nosso código no SVN agora sem problemas em tudo. Os arquivos Netbeans não pisar nos arquivos do Eclipse. Temos nossos projetos estruturados da seguinte forma:

sample-project   
+ bin
+ launches  
+ lib  
+ logs
+ nbproject  
+ src  
  + java
.classpath
.project
build.xml

Os maiores pontos parecem ser:

• proibir qualquer caminhos absolutos no arquivos de projeto para qualquer IDE.
• Defina os arquivos de projeto para a saída do arquivos de classe para o mesmo diretório.
• svn: ignorar o privado diretório no .nbproject diretório.
• svn: ignorar o diretório utilizado para saída de arquivo de classe das IDEs e quaisquer outros diretórios tempo de execução gerados como o diretório de logs acima.
• tem pessoas usando tanto consistentemente de modo que as diferenças são resolvidos rapidamente.
• Também manter um sistema de compilação independente das IDES tais como cruisecontrol.
• Use UTF-8 e corrigir quaisquer problemas de codificação imediatamente.

Estamos a desenvolver no Fedora 9 de 32 bits e 64 bits, Vista e Windows XP e cerca de metade dos desenvolvedores usar um IDE ou outro. A utilização poucos ambos e alternar regularmente.

Answer 3

A melhor coisa é, provavelmente, a não cometer qualquer arquivo relacionado IDE (como .project do Eclipse), que forma, todos podem fazer o checkout do projeto e fazer o seu coisa que ele quer.

Dito isto, eu acho que a maioria das IDEs tem seu próprio esquema de arquivo de configuração, então talvez você pode comprometer tudo isso sem ter qualquer conflito, mas se sente confuso imo.

Answer 4

Para a maior parte eu concordo com seldaek, mas também estou inclinado a dizer que você deve pelo menos dar um arquivo que diz quais são as dependências, qual a versão Java para uso para compilar, etc, e extra qualquer coisa que uma NetBeans / desenvolvedor Eclipse pode precisar compilar em seu IDE.

Atualmente só usar o Eclipse e assim nós nos comprometemos todos os Eclipse .classpath .project arquivos para o SVN que eu acho que é a melhor solução, porque então todo mundo é capaz também reproduzir os erros e que-não é fácil, em vez de faffing aproximadamente com especificidades IDE.

Answer 5

Eu sou da filosofia que a construção deve ser feito com uma abordagem de "menor denominador comum". O que vai para o controle de origem é o que é necessário para fazer a compilação. Enquanto eu desenvolver exclusivamente com Eclipse, meu construir é com formiga na linha de comando.

Com relação ao controle de origem, eu só verificar em arquivos que são essenciais para a construção da linha de comando. arquivos sem Eclipse. Quando eu configurar uma nova máquina de desenvolvimento (parece que duas vezes por ano), é preciso um pouco de esforço para obter Eclipse para importar o projeto a partir de um arquivo de construção Ant mas nada assustador. (Em teoria, isso deve funcionar o mesmo para outros IDEs, não? Intratável que eles devem ser capazes de importação da formiga?)

Eu também documentou como configurar um ambiente de construção mínimo.

Answer 6

I utilizar o Maven, e check-in apenas o pom & fonte.
Depois de verificar um projeto, eu corro mvn eclipse: eclipse
Digo SVN para ignorar o .project gerado, etc.

Answer 7

Aqui está o que eu faço:

1. Apenas manter no controle de origem o seu script de construção Ant e classpath associado. Classpath pode ser expressa no script ant, um arquivo de propriedade ou geridos por hera.
2. escrever um alvo formiga para gerar arquivos do Eclipse .classpath da formiga classpath
3. O NetBeans irá utilizar o seu script de construção e classpath, apenas configurá-lo para fazê-lo através de um projeto de forma livre.

Desta forma você obter scripts de construção IDE independentes e desenvolvedores felizes:)

Há um blog no local netbeans sobre como fazer 3. mas eu não posso encontrá-lo agora. Eu coloquei algumas notas sobre como fazer o descrito acima no meu site - texto do link (embora rápido e feio, sorry)

Note que se você estiver usando Ivy (uma boa idéia) e Eclipse que você pode ser tentado a usar o eclipse hera plugin. Eu usei-o e achei que era ser terrivelmente buggy e não confiável. Melhor usar 2. acima.