В настоящее время я работаю с проектом на основе Maven (назовем его Core) на Java, и в настоящее время мы разделили его на следующие модули:
- Основной
- Core.Integration
В настоящее время я использую IntelliJ в качестве моей IDE, и все они создают и имеют свои собственные файлы pom (проект Core также содержит модульные тесты). Хотя единственный модуль, который имеет пригодный для использования вывод, является Core, Core.Integration используется только для тестирования ядра Core с другими проектами, поэтому реальный вывод этого модуля отсутствует.
Мы поместили Core.Integration в качестве своего собственного модуля вместо использования тестовой папки в ядре, поскольку у него есть дополнительные зависимости, такие как другой внутренний проект (давайте назовем его ThirdParty), поэтому чтобы доказать, что Core работает с ThirdParty, у нас есть набор интеграционных тестов. Модуль Core не должен знать о ThirdParty, и модульные тесты не нуждаются в использовании этого другого проекта, так как в Maven имеется только 1 область тестирования, мы не хотим портить модуль Core этой зависимостью.
ТАК ... теперь мы знаем, почему у нас есть этот отдельный модуль тестирования интеграции, я доберусь до главной проблемы ...
Допустим, что сам модуль Core работает нормально, и все модульные тесты пройдены, однако вы обнаружите, что в модуле Core.Integration есть неудачный тест. При условии, что у вас были открыты оба этих модуля, вы можете понять это и не внедрять изменения, пока не исправите провальный тест. Однако некоторые из других IDE открывают только один модуль, и вы должны вручную указать, чтобы он включал другие, поэтому допустим, что разработчик проверяет проект, а затем загружает модуль Core, но не пытается включить модуль тестирования интеграции. поскольку он не нуждается в этом на данный момент, он вносит изменения, все проходит, и он развертывает. На этом этапе сборка повреждена, и мы должны повторно посетить, почему и где она все сломана.
В .net у вас есть идея решения, и во многих проектах в этом случае, если один из этих проектов терпит неудачу, решение терпит неудачу. Итак, взяв вышеупомянутый подход и применив его к .net (притворяясь, что у нас есть решение под названием «Core»). Если бы нам нужно было проверить наше решение и открыть его, мы бы автоматически увидели все дочерние проекты, а затем, если мы сделаем то же самое изменение и построим решение, оно сообщит нам, что оно провалилось, так как один из дочерних проектов провалился. Это то, что я после, идея родительского решения , у которого есть много дочерних моделей, которые всегда будут загружаться вместе, тогда, если одна из них терпит неудачу, все это терпит неудачу, таким образом, обратная связь о тестах на разрыв дается до того, как она тоже поздно. Принимая во внимание, что на данный момент они представляют собой отдельные модули без ссылки.
Моя другая проблема также заключается в том, что разные разработчики используют разные IDE (например, IntelliJ, Eclipse, Netbeans), поэтому, если подобный тип структуры проекта возможен с использованием подхода pom в стиле Maven, мне нужно, чтобы разные IDE распознавали это без ручных шагов необходимость включения других модулей и т.д ...
Извините, что много вафель там, но хотел дать более полный контекст для конкретной проблемы и структуры проекта.