Как вы справляетесь с сгенерированным кодом?

Question

Какова хорошая стратегия для работы с сгенерированным кодом? Один из наших проектов использует инструмент Apache CXF wsdl2java для создания заглушек JAX-WS для набора wsdls. Как следует обращаться с этим кодом?

Есть два варианта, которые я вижу:

1. Создайте заглушки один раз и сохраните их в системе контроля версий. При этом вам не придется иметь дело с проблемами пути к классам IDE, поскольку у вас есть исходные файлы прямо в вашем дереве (или поблизости). Тем не менее, у вас есть много лишних помех в управлении версиями в дополнение к искушению кого-то обезьяны сгенерированным кодом

2. Заглушки генерируются каждый раз во время сборки. Это меняет плюсы и минусы для # 1 в том, что разработчик теперь должен запустить скрипт сборки и добавить получившиеся jar-файлы в его / ее classpath.

Мы пошли с # 2, потому что раздражение проблем, связанных с classpath, казалось, перевешивало проблемы, подробно описанные в # 1.

Что делают другие люди? У кого-нибудь есть рекомендации по оптимизации этого процесса?

Answer 1

Я считаю, что сгенерированный код практически никогда не должен храниться в системе контроля версий. Для этого должна быть веская причина. Я обычно создаю задачу ant "build-for-eclipse", которая собирает весь сгенерированный код. Я запускаю его, обновляю каталог, в котором создается сгенерированный код, и вуаля, я готов идти.

Цель состоит в том, чтобы у вас была тривиальная задача «одной кнопкой», которую может выполнить любой разработчик, чтобы у них были все источники - сгенерированные, а не - в их IDE, но без вывода что-либо хранится в системе контроля версий. Если это выход генератора, то по определению это не источник . : -)

Это должно безопасно удовлетворять потребности каждого.

Answer 2

Я предпочитаю вариант № 3, который имеет плюсы 1 и 2, но не имеет минусов: никогда не передавайте сгенерированные файлы в систему контроля версий, но создайте полностью автоматизированный и переносимый процесс сборки (одна команда оболочки запускает все это на каждом рабочее место).

В SO (и в Интернете) много обсуждается в обоих аспектах. Достаточно сказать, что: управление исходным кодом предназначено для SOURCE, а не для сгенерированного кода или двоичных файлов, и что такой источник содержит сценарии, которые автоматизируют повторяющуюся сборку.

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

С наилучшими пожеланиями.

Answer 3

Я пробовал это в обоих направлениях и остановился на том, чтобы не хранить сгенерированный код как общее правило. Это может быть проблемой, когда есть небольшие, тривиальные различия, и похоже, что есть изменения в управлении ревизиями, и на самом деле там нет ничего важного. Кроме того, с # 1, вы можете положить много мусора в свои репозитории, особенно в ситуациях, когда сгенерированный код является двоичным. Большинство репозиториев хранят не разностные двоичного кода, а полные копии.

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

Answer 4

Большую часть времени я бы выбрал вариант № 2. Причины довольно очевидны, и я уже вижу достаточную поддержку этого выбора от других.

В моей книге есть исключение. Если применимо большинство / все из следующего:
(как в «основном», вы знаете - это критерий мышления, а не что-то написанное в камне ...)

1. Код заглушки восстанавливается долго (*)
2. Не существует эффективного способа заранее определить, изменился ли источник ( a-la MAKE), поэтому вам придется каждый раз перестраивать заглушки.
3. Ожидается, что код заглушки будет меняться очень редко (поскольку источник, из которого генерируются заглушки, изменяется очень редко)
4. Любые изменения в коде заглушки обычно требуют ручного изменения остальной части программы в любом случае

Я обычно буду писать сценарий шага генерации (и документировать их также в Source Control), но только буду производить генерацию прокси вручную.

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

** (Сколько стоит «слишком долго»? Это зависит; в высокоинтерактивных средах одна минута может быть «слишком длинной». Как я уже сказал, это критерий, о котором вы должны думать. реальной жизни, вы должны выбрать свое зло). *

Answer 5

Мы используем Eclipse в качестве основной IDE / инструмента. Мы определяем новый проект Java для каждого сгенерированного кода. Например, если я работаю в веб-проекте с Hibernate и Axis Web Services. У нас есть эта структура в нашем рабочем пространстве:

projectWeb: Это основной проект, обычно динамический веб-проект. Все кодеры работают здесь: -)

projectORM: код, созданный с помощью инструментов гибернации.

projectWS: код, созданный с помощью Java2WDSL.

projectWSClient: код, созданный с помощью WDSL2Java.

Каждый проект находится под контролем ревизии (SVN). Мы используем Maven 2 в качестве инструмента зависимости / сборки, а двоичные файлы из сгенерированного кода сохраняются в виде jar-файлов в нашем хранилище Maven 2. До этого один человек (или более) из группы отвечал за работу с сгенерированным кодом и тестировал его после каждого поколения (например, при изменении модели).

Привет

Answer 6

Номер 2 в любой день лучше. Также с # 2 вы можете использовать улучшения, сделанные в генераторе кода (Apache CXF в вашем случае). Вам не нужно заново генерировать и регистрировать каждый раз, когда вы начинаете использовать новую версию CXF. И да, система сборки одним щелчком мыши, которая делает все: -)

Answer 7

Я думаю, вы обнаружите, что толпа J2EE / EJB 2.x имела дело с подобной проблемой с XDoclet . По своему опыту я видел, что это происходит в обоих направлениях - люди, хранящие сгенерированный код в контроле версий и люди, которые генерируют код во время сборки.

Пока у вас есть хорошая система для тестирования, я думаю, # 1 предпочтительнее. Если у вас есть действительно хороший инструмент, который может работать со стилем №2 (например, функциональность Xdoclet в Eclipse), тогда используйте это. Однако будьте внимательны - # 2 часто может заполнить постоянную генерацию JVM, если вы долго собираете и перестраиваете, и перезапускаете IDE / JVM, что часто является проблемой.