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

Question

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

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

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

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

РЕДАКТИРОВАТЬ:Я вижу «генерацию во время процесса сборки» во многих ответах ниже.Хотя я вижу преимущества этого, я не совсем понимаю, как можно отказаться от проверки репозитория.

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

Answer 1

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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