Конкретный classpath для Maven

Если вы разрабатываете компоненты ADF (10g/11g, я думаю), я полагаю, вы будете использовать JDeveloper в качестве IDE. JDeveloper поставляется с очень богатым инструментом управления библиотекой, который позволяет вам определить, какие библиотеки необходимы для компиляции или какие пакеты должны быть упакованы для развертывания. Я полагаю, вы уже знаете, как добавлять библиотеки в проекты и указывать в профиле развертывания, которые следует выбирать при упаковке. Если вы хотите сохранить свои библиотеки из maven, возможно, это лучший подход. Скажем, библиотеки, на которые вы ссылаетесь, также являются "Webcenter", используя этот подход, гарантируют, что у вас есть соответствующие библиотеки, поскольку JDeveloper будет поставляться с правильными библиотеками версий.

Тем не менее, поскольку вы используете maven, я бы не рекомендовал хранить некоторые библиотеки из-под контроля и хранилища maven. Я бы рекомендовал выбрать между управлением maven и Oracle JDeveloper. В нашем текущем проекте мы работаем с JDeveloper ADF 11g (и WebCenter), и мы используем maven, это просто упрощает управление библиотекой. В конце концов, у нас будет большое количество сторонних библиотек (скажем, Apache, Spring и т.д.), Которые могут быть полезны для управления maven и не так много библиотек Oracle, которые действительно необходимы для компиляции в среде IDE ( поскольку вам понадобятся только API, а не их реализации). Наш подход заключался в том, чтобы добавить библиотеки Oracle в наш репозиторий maven всякий раз, когда они требуются, и пусть maven контролирует управление зависимостью.

Как говорят другие, в своих ответах, если вы не хотите, чтобы зависимости были включены в любой из ваших артефактов, используйте <scope>provided</scope>. После того, как вы сконфигурируете среду разработки, вы будете благодарны за работу, и вы можете (почти) забыть об управлении зависимостями. Для создания IDE файлов JDeveloper мы используем плагин maven jdev, поэтому mvn jdev:jdev будет генерировать файлы наших проектов и устанавливать зависимости от библиотек и их компиляции должным образом.

Обновлено:

Конечно, вам нужно обратиться к библиотекам ADF в ваши файлы pom. В нашем проекте мы просто ссылаемся на те, которые используются в каждом приложении, скажем, Библиотеки тегов ADF или конкретная служба, а не весь стек ADF/WebCenter. Для этого используйте "предоставленный" объем. Вы все же можете позволить JDeveloper управлять вашими библиотеками, но мы обнаружили, что проще использовать либо 100% -ные библиотеки JDeveloper, либо подход 100% maven. Если вы пойдете с подходом maven, вам потребуется некоторое время, чтобы сначала создать ваше местное репо, но как только это будет очень легко поддерживать, и весь цикл (разработка, сборка, тестирование, упаковка и развертывание) будет проще, с более последовательной конфигурацией. Верно, что в будущем вам придется обновляться до более поздних версий ADF, но поскольку ваша структура репозитория уже будет определена, она должна быть чем-то быстрым. Для будущих обновлений я бы рекомендовал сохранить версию ADF как свойство на вершине pom, что позволит вам быстрее переключиться на новую версию.

Хотя вы явно заявили, что не хотите их в репозитории, ваши причины не оправданы. Вот мое предложение:

• установите эти банки в своей репостории
• добавьте их как зависимости maven, с <scope>provided</scope>. Это означает, что они предоставлены вашей рабочей средой (сервером приложений) и не будут включены в ваши артефакты (война/ухо)

Проверьте этот похожий вопрос

Целесообразно, чтобы организация, использующая maven, имеет собственный репозиторий. Вы можете видеть Nexus. Затем вы можете установить эти банки в свой репозиторий, и все разработчики будут использовать их, вместо того, чтобы иметь банки только в каждом локальном репозитории.

( "Самый уродливый" вариант будет вовсе не использовать maven, поместите банки в относительное местоположение и добавьте их в путь к классам проекта, отправив файл свойств пути к классам (в зависимости от IDE))