Пришёл к тому, что повесил Serializable на все объекты.
Изменение руками в моём случае неприемлемо по нескольким причинам: 1. Генерируемые классы не хранятся в version contolr репозитории
2. Build строится локально (пока что нет Hudson + global maven repo) и говорить всем участникам проекта — поправьте вот там не вариант
По-поводу пункта 2 можно сыпать пеплом на голову и говорить, что так нельзя, но факт остаётся фактом, так было за долго до моего прихода в проект,
возможно постепенно всё переедет на continious integration.
Добрый день.
В проекте есть набор xsd файлов из которых в процессе компиляции генерируются java файлы (код достался в наследство).
Сейчас понадобилось сделать так, чтобы некоторые генерируемые классы наследовали Serializable interface.
Проект собирается с помощью maven maven-jaxb2-plugin. Добавил в pom.xml
Здравствуйте, Denis_Orlov, Вы писали:
D_O>Сейчас понадобилось сделать так, чтобы некоторые генерируемые классы наследовали Serializable interface.
Удивлен что этого нет по-умолчанию.
D_O>Проблема в том, что игнорируются schemaLocation и node и Serializable получают все объекты всех схем.
А почему это проблема?
D_O>Вопрос в том, можно ли повесить intarface на один элемент или это невозможно?
Возможно, но, думаю, не так просто. А почему бы не убрать перекомпиляцию из процесса сборки?
Здравствуйте, Blazkowicz, Вы писали:
D_O>>Вопрос в том, можно ли повесить intarface на один элемент или это невозможно? B>Возможно, но, думаю, не так просто. А почему бы не убрать перекомпиляцию из процесса сборки?
Поменяли xsd, перегенерировали классы, забыли поправить конкретный класс.
Если что-то уже генерируется автоматом, править там руками следует только в крайнем случае.
Здравствуйте, Donz, Вы писали:
D>Поменяли xsd, перегенерировали классы, забыли поправить конкретный класс. D>Если что-то уже генерируется автоматом, править там руками следует только в крайнем случае.
Любые изменения в коде тестируются. Если не юнит тестами, то хотя бы руками.
Перегенерил классы — будь, добр проверь. Ну, или если совсем всё запущено, то прям в билд скрипте валидацию для этого класса прописать.
Здравствуйте, Blazkowicz, Вы писали:
D>>Поменяли xsd, перегенерировали классы, забыли поправить конкретный класс. D>>Если что-то уже генерируется автоматом, править там руками следует только в крайнем случае. B>Любые изменения в коде тестируются. Если не юнит тестами, то хотя бы руками.
Наличие тестов — это не повод создавать проблемную ситуацию.
B>Перегенерил классы — будь, добр проверь. Ну, или если совсем всё запущено, то прям в билд скрипте валидацию для этого класса прописать.
Какой смысл описывать структуры данных в XSD и автоматическом генераторе, если потом все равно править руками? То, что заложено в контракте, не будет соответствовать тому, что есть в коде. Тут ни contract first, ни code first. Грабли гарантированы, даже если необходимые ручные изменения описать в документации.