Um bom lugar para colocar auto código gerado?

Question

Temos monte de aulas Autogenerated que na maioria são canhotos de Axis2, esqueletos etc. Para alguns WSDLs complicado, Axis2 gera uma tonelada de java em grão, topos etc. E eu tenho certeza que existem outros casos também quando a geração de auto é usado.

Por agora, tratá-los como outros membros de primeira classe da nossa base de código e eles são armazenados nos mesmos pacotes.

No entanto ao fazer refactoring, limpezas etc, torna-se difícil de eliminar os avisos que são provenientes dessas classes geradas automaticamente. Por exemplo, se eu estou tentando limpar o código, de modo a usar os genéricos Java1.5, não há nenhuma boa maneira de saber quantas dessas classes ofensivas são nossos vs sendo gerado auto.

Eu deveria estar separando estas peças Autogenerated fora em um pacote diferente? Como vocês armazenar esses artefatos no repositório?

EDIT: Vejo 'gerar durante o processo de compilação' em algumas respostas abaixo. Enquanto eu ver os benefícios de fazer isso, eu não vejo como eu posso ficar longe de um check-in repositório.

Meu código tem dependências de tempo de compilação de algumas dessas classes e para mim, uma compilação durante o desenvolvimento é um 'ctrl-s' em eclipse. Usamos formiga-scripts para gerar a compilação, executar testes e gerar resultados.

Answer 1

Você pode manter os mesmos pacotes, mas usar uma pasta de origem diferente (algo como gerado-src), que é o que fazemos. Na verdade, estou em cima do muro sobre a idéia de salvar o código gerado no repositório de código-fonte. Fazemos isso como uma conveniência para outros desenvolvedores do projeto, mas, geralmente, faz sentido para regenerar o código-fonte como parte do processo de construção. Se este código gerado é improvável que a mudança, em seguida, usando um projeto separado e gerando um frasco pode ser mais prático.

Answer 2

Resumo de melhores práticas:

• Faça isso repetível
  • Criar código gerado como parte de um processo de construção.
  • Não verificar código gerado no controle de origem. (Verificação Do na fonte. Por exemplo WSDL)
• Mantenha gerado código separado do código gerenciado
  • Use uma pasta de origem diferente para saída gerada.
  • Entregar um .jar separado para que este código gerado torna-se uma dependência.
  • Considere o uso de um projeto IDE diferente (ou módulo maven)

Answer 3

Eu coloquei esses arquivos em um projeto próprio. Dessa forma, eu posso adicionar o arquivo de construção, todos os patches que eu preciso, etc. em um único lugar e desligue todos os avisos para o código gerado.

Answer 4

Se você está verificando-los em seu sistema de controle de origem, não . Fazê-los se re-gerado por uma etapa de compilação. Se eles são geradas a partir de um WSDL, o check-in o WSDL, não o código resultante.

Eu recomendo ter essa etapa de compilação gerar um .jar completamente separado para o código gerado, e excluindo os arquivos de origem, apenas para torná-lo tão improvável quanto possível que mantenedores vai tentar editar lado a fonte gerado automaticamente.

Assim, suas atividades de refatoração vai ver o código gerado automaticamente como como uma biblioteca de terceiros em vez de fonte a ser manipulado.

Answer 5

Para cada conjunto de artefatos gerados, criar um novo projeto que realiza a geração, em seguida, agrupa os artefatos em arquivos ZIP JAR e de origem, e em seguida, referenciá-los a partir de sua aplicação. Mantém as coisas agradáveis ??e independente, e enfatiza o fato de que os artefatos gerados não são para mudar pelo IDE.

Answer 6

com o Maven e axistools-maven-plugin, as fontes gerados são lugares em uma pasta de origem diferente no diretório 'target'. este diretório de destino é onde Maven gera todos os arquivos e outras coisas, para que ele possa ser limpo.
Isto é muito conviniened, porque os arquivos gerados também aparece em uma pasta de origem diferente dentro do IDE.