Добрый день.
В проекте есть набор xsd файлов из которых в процессе компиляции генерируются java файлы (код достался в наследство).
Сейчас понадобилось сделать так, чтобы некоторые генерируемые классы наследовали Serializable interface.

Проект собирается с помощью maven maven-jaxb2-plugin. Добавил в pom.xml

<bindingIncludes>
      <value>binding.xjb</value>
</bindingIncludes>

Файл binding.xjb содержит:

<?xml version="1.0" encoding="UTF-8"?>

<bindings xmlns="http://java.sun.com/xml/ns/jaxb"
          xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
          xmlns:xsd="http://www.w3.org/2001/XMLSchema"
          version="2.0">

    <bindings schemaLocation="xsd/definition.xsd">
        <bindings node="//xsd:element[@name='summaries']">
            <globalBindings>
                <xjc:serializable uid="-1"/>
            </globalBindings>
        </bindings>
    </bindings>
</bindings>

Файл definition.xsd

...
<xsd:element name="tradeSummaries">
   <xsd:complexType>
    <xsd:sequence>
       ....
    </xsd:sequence>
   </xsd:complexType>
</xsd:element>
...

Проблема в том, что игнорируются schemaLocation и node и Serializable получают все объекты всех схем.
Если же убрать globalBindings

    <bindings schemaLocation="xsd/definition.xsd">
        <bindings node="//xsd:element[@name='summaries']">
                <xjc:serializable uid="-1"/>
        </bindings>
    </bindings>
</bindings>

То Serializable не получает никто.
Вопрос в том, можно ли повесить intarface на один элемент или это невозможно?

Здравствуйте, 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. Грабли гарантированы, даже если необходимые ручные изменения описать в документации.

Пришёл к тому, что повесил Serializable на все объекты.

Изменение руками в моём случае неприемлемо по нескольким причинам:

1. Генерируемые классы не хранятся в version contolr репозитории
2. Build строится локально (пока что нет Hudson + global maven repo) и говорить всем участникам проекта — поправьте вот там не вариант

По-поводу пункта 2 можно сыпать пеплом на голову и говорить, что так нельзя, но факт остаётся фактом, так было за долго до моего прихода в проект,
возможно постепенно всё переедет на continious integration.