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

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

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

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

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

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

4
Kapsh 4 Июн 2009 в 15:57

6 ответов

Лучший ответ

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

6
Francois Gravel 4 Июн 2009 в 12:13

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

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

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

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

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

2
Daniel Earwicker 4 Июн 2009 в 12:11

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

1
skaffman 4 Июн 2009 в 12:08

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

0
Salandur 4 Июн 2009 в 12:18

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

6
Aaron Digulla 4 Июн 2009 в 12:01