Хорошее место для размещения сгенерированного кода?

Question

У нас есть группа автоматически сгенерированных классов, которые в основном представляют собой заглушки, скелеты Axis2 и т. Д. Для некоторых сложных wsdls Axis2 генерирует TON java-бинов, заглушек и т. Д. И я уверен, что есть и другие случаи, когда используется автогенерация.

Пока мы относимся к ним как к другим первоклассным членам нашей кодовой базы, и они хранятся в тех же пакетах.

Однако при рефакторинге, очистках и т. Д. Становится трудно отсеять предупреждения, поступающие от этих автоматически сгенерированных классов. Например, если я пытаюсь очистить код для использования обобщений Java1.5, нет никакого хорошего способа узнать, сколько из этих нарушающих классов у нас по сравнению с автоматически генерируемыми.

Должен ли я разделить эти автоматически сгенерированные детали в другую упаковку? Как вы, ребята, храните такие артефакты в хранилище?

EDIT: Я вижу «генерировать во время процесса сборки» в нескольких ответах ниже. Хотя я вижу преимущества этого, я не совсем понимаю, как я могу избежать повторной регистрации в репозитории.

Мой код имеет зависимости времени компиляции от некоторых из этих классов, и для меня сборка во время разработки - это ctrl-s в eclipse. Мы используем ant-скрипты для генерации компиляции, запуска тестов и генерации результатов.

Answer 1

Краткое изложение лучших практик:

• Сделай это повторяемым
  • Создать сгенерированный код как часть процесса сборки.
  • Не проверять сгенерированный код в системе контроля версий. (Проверьте источник. Например, WSDL)
• Хранить сгенерированный код отдельно от управляемого кода
  • Использовать другую исходную папку для сгенерированного вывода.
  • Поставьте отдельный файл .jar, чтобы этот сгенерированный код стал зависимостью.
  • Рассмотрите возможность использования другого проекта IDE (или модуля maven)

Answer 2

Вы можете сохранить те же пакеты, но использовать другую исходную папку (что-то вроде generate-src), что мы и делаем. Я на самом деле стою на пороге всей идеи сохранения сгенерированного кода в хранилище исходного кода. Мы делаем это для удобства других разработчиков проекта, но обычно имеет смысл восстановить исходный код как часть процесса сборки. Если этот сгенерированный код вряд ли изменится, то использование отдельного проекта и создание jar может быть более практичным.

Answer 3

Я поместил эти файлы в собственный проект. Таким образом, я могу добавить файл сборки, все необходимые мне патчи и т. Д. В одном месте и отключить все предупреждения для сгенерированного кода.

Answer 4

Если вы проверяете их в своей системе контроля версий, не . Заставьте их воссоздать шаг сборки. Если они сгенерированы из WSDL, проверьте WSDL, а не полученный код.

Я бы порекомендовал, чтобы на этом этапе сборки был сгенерирован совершенно отдельный файл .jar для сгенерированного кода, а затем были удалены исходные файлы, просто чтобы было настолько маловероятно, что сопровождающие попытаются вручную отредактировать автоматически сгенерированный источник.

Таким образом, ваши действия по рефакторингу будут восприниматься автоматически сгенерированным кодом как сторонняя библиотека, а не как источник, которым нужно манипулировать.

Answer 5

Для каждого набора сгенерированных артефактов создайте новый проект, который выполняет генерацию, затем объедините артефакты в файлы JAR и исходные ZIP-файлы, а затем сделайте ссылку на них из своего приложения. Делает вещи красивыми и раздельными и подчеркивает тот факт, что сгенерированные артефакты не подлежат изменению в IDE.

Answer 6

с помощью maven и axistools-maven-plugin сгенерированные источники помещаются в другую исходную папку в каталоге 'target'. В этом целевом каталоге maven создает все файлы и прочее, поэтому его можно очистить.
Это очень удобно, поскольку сгенерированные файлы также появляются в другой исходной папке в среде IDE.