Хорошее место для размещения автоматически сгенерированного кода?
-
09-09-2019 - |
Вопрос
У нас есть куча автоматически сгенерированных классов, которые в основном представляют собой заглушки, скелеты и т. д. Axis2.Для некоторых сложных wsdls Axis2 генерирует ТОННУ Java-компонентов, заглушек и т. д.И я уверен, что есть и другие случаи, когда используется автогенерация.
На данный момент мы рассматриваем их как других первоклассных членов нашей кодовой базы, и они хранятся в тех же пакетах.
Однако при рефакторинге, очистке и т. д. становится сложно отсеять предупреждения, исходящие от этих автоматически сгенерированных классов.Например, если я пытаюсь очистить код, чтобы использовать дженерики Java1.5, нет хорошего способа узнать, сколько из этих классов-нарушителей являются нашими, а сколько автоматически сгенерированных.
Должен ли я разделить эти автоматически сгенерированные части в другой пакет?Ребята, как вы храните такие артефакты в репозитории?
РЕДАКТИРОВАТЬ:Я вижу «генерацию во время процесса сборки» во многих ответах ниже.Хотя я вижу преимущества этого, я не совсем понимаю, как можно отказаться от проверки репозитория.
Мой код зависит от времени компиляции некоторых из этих классов, и для меня сборка во время разработки — это сочетание клавиш «ctrl-s» в eclipse.Мы используем ant-скрипты для генерации компиляции, запуска тестов и генерации результатов.
Решение
Вы можете сохранить те же пакеты, но использовать другую папку с исходным кодом (что-то вроде сгенерированного-src), что мы и делаем.На самом деле я сомневаюсь в самой идее сохранения сгенерированного кода в репозитории исходного кода.Мы делаем это для удобства других разработчиков проекта, но обычно имеет смысл повторно создать исходный код в рамках процесса сборки.Если этот сгенерированный код вряд ли изменится, то использование отдельного проекта и создание jar-файла может оказаться более практичным.
Другие советы
Краткое изложение лучших практик:
- Сделайте это повторяемым
- Создайте сгенерированный код как часть процесса сборки.
- Не проверяйте сгенерированный код в системе контроля версий.(Проверьте источник.напримерWSDL)
- Храните сгенерированный код отдельно от управляемого кода.
- Используйте другую исходную папку для сгенерированного вывода.
- Доставьте отдельный .jar, чтобы этот сгенерированный код стал зависимостью.
- Рассмотрите возможность использования другого проекта IDE (или модуля maven).
Я поместил эти файлы в отдельный проект.Таким образом, я могу добавить файл сборки, все необходимые мне патчи и т. д.в одном месте и отключите все предупреждения для сгенерированного кода.
Если вы проверяете их в своей системе контроля версий, не.Заставьте их заново генерироваться на этапе сборки.Если они сгенерированы из WSDL, проверяйте WSDL, а не результирующий код.
Я бы порекомендовал на этом этапе сборки создать совершенно отдельный .jar для сгенерированного кода, а затем удалить исходные файлы, просто чтобы свести к минимуму вероятность того, что сопровождающие попытаются вручную отредактировать автоматически сгенерированный исходный код.
Таким образом, ваши действия по рефакторингу будут рассматривать автоматически сгенерированный код как стороннюю библиотеку, а не как исходный код, которым можно манипулировать.
Для каждого набора сгенерированных артефактов создайте новый проект, который выполняет генерацию, затем объединяет артефакты в файлы JAR и исходные ZIP-файлы, а затем ссылается на них из вашего приложения.Сохраняет все красиво и отдельно и подчеркивает тот факт, что сгенерированные артефакты не предназначены для изменения в среде IDE.
с помощью maven и axistools-maven-plugin сгенерированные источники помещаются в другую исходную папку в «целевом» каталоге.в этом целевом каталоге maven генерирует все файлы и прочее, поэтому его можно очистить.
Это очень удобно, поскольку сгенерированные файлы также появляются в другой исходной папке в IDE.