.classpath e .project - verifique o controle de versão ou não?

Estou executando um projeto Java de código aberto que consiste em vários módulos em uma árvore de dependências. Todos esses módulos são subdiretórios em um repositório subversion. Para os iniciantes em nosso projeto, é muito trabalhoso configurar tudo isso manualmente no Eclipse.

Nem todos os nossos desenvolvedores usam eclipse. No entanto, estamos considerando apenas verificar os arquivos .classpath e .project para ajudar os novatos a começar. isso é uma boa ideia? Ou isso levaria a conflitos constantes nesses arquivos? Existe uma maneira alternativa de tornar o projeto mais fácil de configurar no Eclipse?

Definitivamente sim, como eu disse em " Você mantém seus arquivos de projeto sob controle de versão? "

"Carregue, configure, vá."

Mas ... isso é verdade apenas para configurações recentes do Eclipse3.5, onde os caminhos de construção suportam caminhos relativos :

E Eclipse3.6 seria melhor, pois oferece suporte a caminhos relativos para variáveis ​​de caminho em Linked Resources:

(desde 3.6M5)

Definitivamente não - geralmente é uma ideia terrível distribuir arquivos de projeto via subversion. Especialmente porque alguém pode modificá-los de uma maneira estranha. Uma boa página na documentação do projeto é uma ideia muito melhor. Nosso projeto também possui muitos módulos e uma configuração complexa. Configuramos uma página de confluência que descreve como começar com o projeto em cada IDE populer - IntelliJ, Eclipse, NetBeans. Um arquivo README no Subversion contém as mesmas informações.

Eu voto não, mas isso é porque eu geralmente geraria esses arquivos do maven

Na minha experiência, excluindo os casos limitados em que configurações puramente locais estão envolvidas, tudo deve estar no controle de origem. A lei do controle de origem é que tudo o que foi inserido deve funcionar por aqueles que o retiraram. Infelizmente, o eclipse costuma fazer com que coisas assim ocorram .classpath:

    <classpathentry kind="con" 
      path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

Portanto, no meu Mac isso funciona, e talvez alguém em um Mac tenha o mesmo JRE, mas não funcionará para mais ninguém.

Além disso, não há maneira fácil de contornar isso. O Eclipse sempre adicionará isso. EU QUERO ter o arquivo .classpath lá, porque existem alguns JARs de terceiros em nossa pasta lib onde nos preocupamos com o controle de versão, então nós os deixamos lá para que novos desenvolvedores não tenham que obtê-los . Estamos mudando para um sistema gerenciado, mas ainda temos dependências gerenciadas + não gerenciadas verificadas. Isso significa que todos os desenvolvedores precisam apenas garantir que dois diretórios estejam em seus.classpath s. Mas é melhor do que ter que corrigir seu JRE toda vez que você puxa e ter uma mudança em seu .classpath toda vez que você efetua um commit.

Eclipse faz algumas outras coisas boas para você, no entanto. O arquivo .project geralmente será o mesmo nas instâncias, então inclua-o. Mas a melhor coisa sobre o controle de origem do eclipse são as configurações de Run Configurations. Na guia "Comum" na caixa de diálogo Configurações de execução, salve as configurações para que apareçam para seus colegas nas listas de favoritos para Depurar e Executar. Para mim, vários .launcharquivos vão para o .settingsdiretório, para que todos possamos usá-los.

Então eu digo: o .settingsdiretório entra no controle de origem para configurações de inicialização (exceto * .prefs)

.classpath fica fora

.project entra

Eu verificaria esses arquivos para facilitar ao máximo o início de novos usuários. Na melhor das hipóteses, o usuário deve verificar o projeto e ser capaz de executá-lo sem conhecimento extra. Para esses arquivos, as regras são as mesmas que para outros arquivos no projeto: manuseie-os com cuidado. Você não deve colocar caminhos absolutos no código-fonte, nem nos arquivos de configuração.

Se os arquivos forem verificados de forma que o projeto seja executado do zero, não haverá muitas forças para alterá-los.

Eu recomendaria que você verifique os arquivos no subversion SE eles não contiverem caminhos absolutos e outros dados que os vinculariam diretamente ao ambiente de um único desenvolvedor.

Se os arquivos contiverem caminhos absolutos e semelhantes, um README seria uma escolha melhor.

Sim, definitivamente verifique-os, mas certifique-se de documentar quaisquer dependências de caminho e evitar caminhos absolutos, se possível.

Se você não fizer o check-in, qualquer pessoa que fizer check-out do projeto precisará recriar todas essas configurações, o que é irritante e potencialmente sujeito a erros.

Algumas configurações complexas podem ser melhor tratadas por um script para gerar esses arquivos, mas geralmente é melhor apenas registrá-los.