Как сохранить группу приложений с общими библиотеками, которые часто меняются?

Question

У меня есть много приложений командной строки Java небольшого размера, которым приходится использовать набор jar-файлов поставщика для подключения к серверам, и хотя написание этих приложений было довольно простым, поддерживать их оказывается не быть.

Я построил их, используя Maven и некоторые шаблоны, которые позволили мне довольно быстро изменить время разработки, но пока это все автономные приложения командной строки.

Боль от обновлений на серверах поставщиков. Всякий раз, когда это происходит, это заставляет меня перекомпилировать все эти приложения с новыми играми в банке, в противном случае я получу SerialVersionUID Исключения и потерянные приложения.

Что я рассматриваю

Я думал, что можно будет использовать Maven для генерации приложения, а затем выбросить его на сервер приложений с сервером, предоставляющим набор общего поставщика .jars в любом /shared classpath это обеспечивает. Таким образом, я мог бы просто обновить .jars, перезапустить сервер, и все, скорее всего, продолжится без ошибок.

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

Вопросы

1. Какие типы развертываний работают следующим образом?
2. Есть ли другие способы сделать это, что мне не хватает?
3. Какие-нибудь учебники, фреймворки и т. Д., Которые могли бы сделать это проще?

Answer 1

Возможно, я неправильно понимаю вашу ситуацию, но если интерфейс, который вы используете в библиотеках поставщиков, не меняется между версиями, вы не могли бы просто сохранить jar-файлы в classpath ваших приложений командной строки и таким образом просто перезаписатьфайлы поставщика при необходимости?Таким образом, вам нужно будет перекомпилировать только когда интерфейсы меняются таким образом, чтобы сломать ваш код?

Answer 2

Я мог бы просто поделиться своим опытом. У нас есть 3 способа преодолеть это на данный момент. Первый путь - это наш старый путь, который мы все еще используем.

1. Создайте базовый проект, на который мы ссылаемся со всеми нашими внешними JAR-файлами. Пользовательский проект при компиляции / развертывании проверяет наличие более нового тега базового проекта, чем тот, который он использует в настоящее время, и, если имеется более новый тег, он завершится неудачно и вынудит пользователя проверить наличие обновлений и перекомпилировать. Преимущество этого состоит в том, что во время компиляции вы можете проверять наличие новых jar-файлов, а мы получаем список изменений и перезагружать jar-файлы. В нашей IDE мы можем быстро увидеть, если что-то изменилось из API - известно, что это произошло, тогда мы можем исправить и перекомпилировать. Кроме того, поскольку мы знаем об изменениях, мы можем прочитать журналы изменений и посмотреть, влияют ли на нас какие-либо изменения, а затем повторно протестировать части приложения, которые зависят от этих библиотек.

2. Мы используем Maven, но вместо общедоступных репозиториев мы поддерживаем наш собственный репозиторий, куда мы перемещаем библиотеку в наше локальное репо только после того, как она была протестирована - поэтому для нас нет сюрпризов. *

3. Этот метод уникален для развертывания Tomcat, но мы также загружаем библиотеки через Context, используя загрузчик классов. Это не мой любимый способ загрузки внешних jar-файлов, но этот работает без развертывания. Конечно, поскольку компилятор не может вам помочь, новый jar не может быть на 100% совместим с вашим кодом, и вы можете получить некоторые ожидания NoSuchMethodError или ClassNotFoundException времени выполнения.