Проект Maven для Spring WS, JAXB/XSD для создания сервера WAR/EAR и клиентского JAR, а также автоматического создания классов из XSD

Может быть сложно объяснить, чего именно я хочу, поэтому, пожалуйста, позвольте мне сделать это шаг за шагом.

У нашей компании есть долгоживущий проект Java, который использует файлы Spring WS, XSD для создания WSDL и этих bean-компонентов из WSDL. Проект компилируется/собирается с использованием ANT с различными целями (одна цель для создания классов из XSD, другая для создания клиентского JAR, еще одна для создания сервера WAR/EAR). Этот проект использовался для запуска SOAP-сервера, а также для создания клиентского JAR-файла. Но единого исходного кода больше нет, и количество предварительно сгенерированных клиентских JAR-файлов постоянно летает. Мне нужно очистить этот беспорядок, используя Maven.

Я создал модульный проект Maven, но, по сути, единственный настоящий дочерний проект — это тот, который содержит весь пользовательский код, все XSD и т. д. (другой дочерний проект просто упаковывает EAR из WAR, сгенерированного первым проектом). Поскольку в этом проекте используется Spring WS, окончательный файл WSDL создается динамически при запуске на сервере.

До сих пор мне удалось сделать следующее:

  • сгенерируйте классы из XSD вручную, добавьте эти классы в /src/main/java, чтобы они хранились постоянно, пусть Maven сгенерирует остальную часть архитектуры на стороне службы (WAR/EAR).
  • отдельно, используя файл WSDL, импортированный с работающего сервера, сгенерируйте файл JAR клиента с помощью плагина eclipse WTP (создайте новый проект, поместите в него WSDL, используйте плагин WTP для создания файлов, затем экспортируйте проект в окончательный файл JAR), а затем распространите этот JAR на заинтересованные стороны.

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

То, что я хотел бы сделать, это что-то вроде этого:

  • создать проект Maven, в котором размещаются файлы XSD
  • используйте его для создания классов и клиентского JAR
  • обратитесь к этому проекту из проекта на стороне сервера, чтобы на сгенерированные классы можно было ссылаться с помощью кода на стороне сервера
  • проект на стороне сервера - это тот, который будет использовать Spring WS и сможет генерировать файл EAR.

Проблема, с которой я столкнулся, проста: файлы XSD для динамического создания WSDL должны действительно находиться в этом серверном проекте, а не в клиентском проекте. Эти файлы должны находиться в /src/main/resources, чтобы они были перемещены в путь к классам встроенного файла WAR/EAR. Я мог бы использовать две разные копии XSD - одну в проекте на стороне клиента, другую в проекте на стороне сервера, но это звучит неправильно.

Итак, мой главный вопрос на самом деле заключается в том, как мне подойти к этой архитектуре проекта с помощью Maven, чтобы я использовал только один экземпляр любого исходного файла (XSD, Java и т. д.), и я мог удобно генерировать классы из XSD, создавать клиентский JAR и сервер ВОЙНА/УХО. Я согласен с двумя или более отдельными командами сборки - одна генерирует JAR, другая генерирует EAR из соответствующих источников проекта.

Да, кстати, о рефакторинге файлов XSD не может быть и речи — они нам даны и должны использоваться КАК ЕСТЬ.

Спасибо, Николай


person Nikolay    schedule 15.12.2011    source источник


Ответы (2)


Используйте отдельный проект только для XSD и создайте другой JAR только с классами, сгенерированными из XSD. В итоге у вас будет 3 проекта:

  • Проект схемы XSD
  • JAR клиента
  • серверный проект

где клиентские JAR-файлы и серверные проекты зависят от проекта схемы XSD.

Вы можете построить все это за один раз, используя родительский проект со всеми этими проектами как дочерние модули.

Если вы обеспокоены тем, что JAR-файл вашего клиента теперь состоит из двух JAR-файлов (плюс, возможно, больше зависимостей), вы можете использовать плагин затенения для объединения содержимого JAR проекта схемы XSD в клиентский JAR.

Создание большего количества проектов/модулей почти всегда лучше, чем дублирование кода.


Изменить: для создания классов из WSDL и XML-схемы вы можете использовать Maven JAX- Плагин WS (цель wsimport) и/или плагин Maven JAXB.

person prunge    schedule 16.12.2011
comment
Спасибо за хорошую ссылку (тень), это может помочь связать окончательные файлы JAR/EAR. Мне все еще нужно будет понять, как сгенерировать wsdl (у tdrury@ есть предложение) и выяснить, как автоматически сгенерировать фактический клиент SOAP - помните, я сказал, что для этого мы используем плагин Eclipse WTP? На самом деле он генерирует некоторые заглушки, которые раньше вызывали сервер, а не только классы из WSDL. Я бы хотел, чтобы эта автогенерация также вызывалась Maven. Спасибо за ваш вклад! - person Nikolay; 16.12.2011
comment
@Nikolay добавил ссылку на плагины JAX-WS/JAXB, они должны помочь с созданием классов из схемы WSDL/XML. - person prunge; 19.12.2011
comment
Оказывается, все наши веб-клиенты используют Service Client, сгенерированный с помощью AXIS. JAX-WS из jax-ws-commons использует другие библиотеки, что делает сгенерированный клиентский JAR несовместимым с осью. Я должен найти способ использовать ось. - person Nikolay; 20.12.2011
comment
Я нашел этот довольно устаревший плагин, который использует версию 1 оси: org.codehaus.mojo -> axistools-maven-plugin версии 1.4. Он делает именно то, что делает плагин WTP для eclipse, генерируя код/заглушки вплоть до имени последнего пакета/подпакета. По крайней мере, теперь я могу сгенерировать JAR-файл клиента только из wsdl (а не из файлов xsd, как хотелось) с помощью maven без использования плагина eclipse +. Это соответствует нашим многочисленным существующим клиентским JAR-файлам, распространяемым повсюду через кодовую базу компании. - person Nikolay; 20.12.2011
comment
Я думаю, что я бы предпочел использовать maven-jaxb2-plugin вместо того, чтобы напрямую генерировать bean-компоненты из XSD, но этот не генерирует клиентские заглушки, а только bean-компоненты. Другой плагин jaxws-maven-plugin, упомянутый prunge@, на самом деле генерирует заглушки и bean-компоненты, но также использует wsdl вместо файлов xsd (по крайней мере, он может загружать wsdl с предоставленного URL-адреса). Но поскольку он генерирует совершенно другой клиентский код, я не могу его использовать в данный момент. Возможно, в будущем я перейду на этот плагин. Спасибо, Николай P.S. Мне все еще нужно выполнить код на стороне сервера, но это более привычная задача. - person Nikolay; 20.12.2011

Мы генерируем довольно много кода из XSD. Поскольку мы не хотели дублировать код, мы используем XML-каталоги и пользовательский преобразователь схемы, который может разрешать схемы из пути к классам; Я почти уверен, что у apache есть преобразователь схемы, который тоже это сделает — я помню, как нашел его после того, как мы написали наш. Таким образом, один модуль может ссылаться на схему из артефакта другого модуля, объявив ее как зависимость.

person tdrury    schedule 16.12.2011
comment
Вы предлагаете использовать этот преобразователь схемы для создания окончательного wsdl на работающем сервере? В настоящее время мы используем Spring CommonsXsdSchemaCollection, который реализует XsdSchemaCollection от Apache. Я проверю, может ли этот класс действительно искать путь к классу вместо местоположения файла (которое мы сейчас используем), чтобы получить исходные файлы XSD. Если это сработает, это может быть нашим решением! Спасибо - person Nikolay; 16.12.2011
comment
Как создать WSDL из схемы? Этот аспект вашего вопроса меня смущает. - person tdrury; 16.12.2011
comment
Spring делает во время выполнения. Я предполагаю, что класс CommonsXsdSchemaCollection (или какой-либо другой компонент) отвечает за это, поскольку он настроен как компонент с этими XSD. Я унаследовал этот проект и до сих пор пытаюсь понять, как улучшить - person Nikolay; 17.12.2011