Сценарий проблемы следующий (Примечание: это не проблема зависимости между банками, поэтому такие инструменты, как JarAnalyzer, ClassDep или Tattletale не помогут. Спасибо).
У меня большой проект, которыйсоставлен в 10 или более артефактов банку.Все банки зависят друг от друга и образуют иерархию зависимостей.
Всякий раз, когда мне нужно изменить один из файлов, я бы проверял соответствующий исходный код и исходный код для проектов, которые зависят от него.Измените код, скомпилируйте, упакуйте файлы.Пока все хорошо.
Проблема в том, что я могу забыть проверить один из зависимых проектов, потому что зависимости между банками могут быть довольно длинными и со временем меняться.Если это произойдет, некоторые jar-файлы могут перестать синхронизироваться, и я в конечном итоге получу NoSuchMethodException или какую-то другую проблему несовместимости классов во время выполнения, чего я хочу избежать.
Единственное решение, которое я могу придумать, самое простое - проверить все проекты и перекомпилировать их.Но это требует времени, особенно если я перестраиваю его при каждом небольшом изменении.У меня есть сервер непрерывной интеграции, который мог бы сделать это для меня, но он используется совместно с другими разработчиками, так что проверять, не прерывается ли сборка для меня.
Однако у меня есть все банки, так чтогипотетически должна быть возможность проверить, что jar-файлы, которые зависят от измененного кода, имеют несоответствие в сигнатуре метода, именах классов и т. д. Но как я могу выполнить такую проверку?
Кто-нибудь сталкивался с подобной проблемой раньше?Если да, то как ты решил это?Буду признателен за любые инструменты или методологии.
Дайте мне знать, если вам нужны разъяснения.Спасибо.
РЕДАКТИРОВАТЬ :
Я хотел бы немного прояснить свой вопрос.
Конечная цель этой задачи состоит в том, чтобы проверить, чтовнесенные мною изменения будут скомпилированы для всего проекта.Я ищу инструмент / технику, которая помогла бы мне выполнить такую проверку.
Рассмотрим этот пример:
У вас есть 2 проекта: A и B, которые развернуты как A.jar и B.баночка соответственно.A зависит от B.
Вы хотите изменить B, поэтому вы проверяете его и изменяете сигнатуру метода, от которой зависит A.Вы можете скомпилировать B и выполнить все тесты самостоятельно без каких-либо проблем, потому что сам B не зависит ни от чего.Таким образом, вы с радостью фиксируете свои изменения.
Через несколько часов полная интеграция проекта не удалась, потому что A не удалось скомпилировать!
Как мне избежать этого?
Видинструмент, который я ищу, извлечет A.jar и проверит, что все зависимости в A от нового модифицированного B все еще в порядке.Как потенциальная ошибка компиляции, которая произошла бы, если бы я перекомпилировал источники A и B.
Другое решение, как предлагалось многими из вас, - это установить локальную непрерывную интеграциюсистема, которая будет перекомпилировать весь проект локально.Я не возражаю против этого, но я хочу избежать этого внутри своего рабочего пространства.С другой стороны, если я извлекаю все источники в другое временное рабочее пространство, мне нужно отразить локальные изменения во временном рабочем пространстве.
Это довольно большая проблема в моей команде, поскольку сборки очень часто ломаются, потому что кто-то забывает проверить (или открыть в Eclipse) правильный набор проектов.Я пытался убедить людей проверить исходный код и перекомпилировать связку перед фиксацией, но это не только требует времени, но и требует выполнения нескольких команд, поэтому большинству людей это просто кажется слишком хлопотным.Если техника не проста или автоматизирована, то она непригодна для использования.