.classpath e .project – verifica o version control ou não?

Estou executando um projeto java open source que consiste em vários módulos em uma tree de dependencies. Todos esses módulos são subdiretórios em um repository de subversão. Para os recém-chegados ao nosso projeto, é muito trabalhoso configurar tudo manualmente no eclipse.

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

Definitivamente sim, como eu disse em ” Você mantém seus arquivos de projeto sob version control? ”

“Carregue, configure, vá.”

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

O caminho de construção suporta caminhos relativos


E o Eclipse3.6 seria melhor, já que suporta caminhos relativos para variables ​​de caminho em Linked Resources :

variável de caminho com caminho relativo
(desde 3.6M5)

Definitivamente não – é uma péssima idéia distribuir arquivos de projeto via subversão. 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 descrevendo como começar a usar o projeto em cada populador IDE – 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

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

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

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

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

Na minha experiência, excluindo os casos limitados em que configurações locais estão envolvidas, tudo deve estar no controle de origem. A lei de controle da fonte é que tudo que é empurrado deve funcionar pelos que saem. Infelizmente, o eclipse muitas vezes faz com que coisas como esta estejam no .classpath :

   

Então, no meu Mac isso funciona, e talvez alguém em um Mac tenha o mesmo JRE, mas isso 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 versionamento, então os deixamos lá para que novos desenvolvedores não precisem obtê-los . Estamos mudando para um sistema gerenciado, mas ainda gerenciamos as + dependencies não gerenciadas. Isso significa que todos os desenvolvedores precisam apenas garantir que dois diretórios estejam em seus .classpath s. Mas é melhor do que ter que consertar seu JRE toda vez que você puxar e tiver uma mudança em seu .classpath toda vez que você cometer.

O Eclipse faz algumas outras coisas boas para você. O arquivo .project geralmente será o mesmo entre instâncias, então inclua isso. Mas a melhor coisa sobre o controle de origem do eclipse são as configurações Run Configurations. Sob a aba “Common” na checkbox de diálogo Run Configurations, salve as configurações para que elas apareçam para seus colegas nas listas de favoritos para Debug e Run. Para mim, um monte de arquivos .launch vão no diretório .settings , então todos nós podemos usá-los.

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

.classpath fica de fora

.project entra.

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

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

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