为maven指定类路径
这里对 Maven 来说相当陌生，所以让我首先解释一下我想要做什么：
我们有某些 JAR 文件不会添加到存储库中。这是因为它们特定于 Oracle ADF 并且已经放置在我们的应用程序服务器上。任何时候所有应用程序都只能使用 1 个版本。为了编译，我们需要将它们放在类路径中。这些 JAR 有很多，因此如果我们要升级到 ADF 的较新版本，我们将不得不进入每个应用程序并重新定义一些相当冗余的依赖项。再说一遍，我的目标是将这些 JAR 添加到类路径中，因为我们将控制其他地方实际使用的版本。
所以基本上，我想在编译时将给定网络目录（其中开发人员无权修改）中的每个 JAR 添加到 maven 的类路径中。并且无需将任何这些 JAR 文件放入存储库中。当然，这些 JAR 不会打包到任何 EAR/WAR 中。
编辑：
我不想将这些添加到公司存储库的其他原因是：
- 这些 JAR 不被其他任何东西使用。其中有很多，不常见并且是 Oracle 独有的。
- 任何时候都只能使用给定 JAR 的一个版本。永远不会出现应用程序A依赖于1.0而应用程序B依赖于1.1的情况。应用程序 A 和 B 都将仅依赖于 1.1 或 1.2。
- 我们计划维护 100 多个应用程序。这是很多 pom.xml 文件，这意味着每当我们升级 Oracle ADF 时，如果未正确指定任何依赖项（通过人为错误），我们每次编辑这 100 多个 pom.xml 文件时都必须修复每个错误。升级。
Quite new to maven here so let me explain first what I am trying to do:
We have certain JAR files which will not be added to the repo. This is because they are specific to Oracle ADF and are already placed on our application server. There is only 1 version to be used for all apps at anyone time. In order to compile though, we need to have these on the class path. There are a LOT of these JARS, so if we were to upgrade to a newer version of ADF, we would have to go into every application and redefine some pretty redundant dependencies. So again, my goal is to just add these JARs to the classpath, since we will control what version is actually used elsewhere.
So basically, I want to just add every JAR in a given network directory (of which devs do not have permission to modify) to maven's classpath for when it compiles. And without putting any of these JAR files in a repository. And of course, these JARs are not to be packaged into any EAR/WAR.
edit:
Amongst other reasons why I do not want to add these to the corporate repo is that:
- These JARs are not used by anything else. There are a lot of them, uncommon and exclusive to Oracle.
- There will only be one version of a given JAR used at anyone time. There will never be the case where Application A depends on 1.0 and Application B depends on 1.1. Both App A and B will depend on either 1.1 or 1.2 solely.
- We are planning to maintain 100+ applications. That is a lot of pom.xml files, meaning anytime we upgrade Oracle ADF, if any dependency wasn't correctly specified (via human error) we will have to fix each mistake every time we edit those 100+ pom.xml files for an upgrade.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我看到三个选项：
提供的范围声明它们。system范围技巧（即声明与系统范围的依赖关系并设置文件系统中jar的路径。system范围声明对这个几乎空的 jar 的依赖关系干净的方法是选项#1，但其他方法似乎也适用于您的情况。最接近您要查找的内容
更新：澄清选项#3
假设您有一个包含
a.jar和< 的目录。 strong>b.jar。创建一个c.jar，其中包含Class-Path条目。它的META-INF/MANIFEST.MF列出了其他 jar，如下所示：然后在 POM 中声明对
c的依赖（并且仅对c>）具有system范围，其他 jar 将变得“可见”，而无需在 POM 中显式列出它们（当然，您需要在清单中声明它们，但这可以很容易地编写脚本）。I see three options:
provided.systemscope trick (i.e. declare the dependencies with a system scope and set the path to the jars in your file system.systemscope.The clean way is option #1 but others would work too in your case. Option #3 seems be the closest to what you're looking for.
Update: To clarify option #3
Let's say you have a directory with
a.jarandb.jar. Create ac.jarwith aClass-Pathentry in itsMETA-INF/MANIFEST.MFlisting other jars, something like this:Then declare a dependency in your POM on
c(and only onc) with asystemscope, other jars will become "visible" without having to explicitly list them in your POM (sure, you need to declare them in the manifest but this can be very easily scripted).尽管您明确表示您不希望它们出现在存储库中，但您的理由是不合理的。我的建议是：
provided 检查 这个类似的问题
建议广泛使用 Maven 的组织拥有自己的存储库。您可以看到 Nexus。然后，您可以在存储库中安装这些 jar，并且所有开发人员都将使用它们，而不是仅将 jar 放在每个本地存储库中。
（“最丑陋”的选项是根本不使用maven，将jar放在相对位置并将它们添加到项目的类路径中，提交类路径属性文件（取决于IDE））
Although you explicitly stated you don't want them in the repository, your reasons are not justified. Here's my suggestion:
<scope>provided</scope>. This means that they are provided by your runtime (the application server) and will not be included in your artifacts (war/ear)Check this similar question
It is advisable that an organization that's using maven extensively has its own repository. You can see Nexus. Then you can install these jars in your repository and all developers will use them, rather than having the jars in each local repository only.
(The "ugliest" option would be not to use maven at all, put put the jars on a relative location and add them to the classpath of the project, submitting the classpath properties file (depending on the IDE))
如果您正在开发 ADF（我猜是 10g / 11g）组件，我想您会使用 JDeveloper 作为 IDE。 JDeveloper 附带了一个非常丰富的库管理工具，允许您定义编译所需的库或应该打包哪些库以进行部署。我想您已经知道如何将库添加到项目中，并在部署配置文件中指示打包时应选择哪些库。如果你想让你的库远离 Maven，也许这可能是最好的方法。假设您引用的库也是“Webcenter”库，使用这种方法将保证您拥有足够的库，因为 JDeveloper 将附带正确的版本库。
尽管如此，当您使用 Maven 时，我不建议让某些库和 Maven 存储库失控。我建议在 Maven 和 Oracle JDeveloper 库管理之间进行选择。在我们当前的项目中，我们正在使用 JDeveloper ADF 11g（和 WebCenter），并且我们使用 Maven，它只是让我们的库管理变得更容易。最终，我们将拥有大量可通过 Maven 管理的第三方库（例如 Apache、Spring 等），而在 IDE 中进行编译所需的 Oracle 库并不多（如您所见）只需要 API，而不需要它们的实现）。我们的方法是在需要时将 Oracle 库添加到我们的 Maven 存储库，并让 Maven 控制整个依赖关系管理。
正如其他人在他们的答案中所说，如果您不希望将依赖项包含在任何工件中，请使用
provided mvn jdev:jdev将构建生成我们的项目文件并设置库的依赖关系以及它们之间的依赖关系以正确编译。更新：
当然，您需要在 pom 文件中引用 ADF 库。在我们的项目中，我们仅引用每个应用程序上使用的内容，例如 ADF 标签库或特定服务，而不是整个 ADF/WebCenter 堆栈。为此，请使用“提供的”范围。您仍然可以让 JDeveloper 来管理您的库，但我们发现采用 100% JDeveloper 库方法或 100% maven 方法更简单。如果您采用 Maven 方法，一开始会花费您一些时间来构建本地存储库，但是一旦完成，维护就非常容易，并且整个周期（开发、构建、测试、打包和部署）会更简单，具有更一致的配置。确实，将来您必须更新到更高的 ADF 版本，但由于您的存储库结构已经定义，因此速度应该很快。对于未来的升级，我建议将 ADF 版本保留为顶部 pom 的属性，这样您可以更快地切换到新版本。
if you are developing ADF (10g / 11g I guess) components, I suppose you'll be using JDeveloper as IDE. JDeveloper comes with a very rich Library Management Tool that allows you to define which libaries are required for compiling or which ones should be packaged for deployment. I I suppose you will already know how to add libraries to projects and indicate in the deployment profile which ones should be picked while packaging. If you want to keep your libraries out of maven, maybe this could be the best approach. Let´s say the libraries you refer too are the "Webcenter" ones, using this approach will guarantee you you have the adequate libraries as JDeveloper will come with the right version libraries.
Nevertheless, as you are using maven I would not recommend to keep some libraries out of control and maven repositories. I´d recommend choose between maven and Oracle JDeveloper library management. In our current project we are working with JDeveloper ADF 11g (and WebCenter) and we use maven, it simply make us library management easier. At the end of the day, we will have a big amount of third party libraries (say Apache, Spring, etc.) that are useful to be managed by maven and not so many Oracle libraries really required for compiling in the IDE (as you would only need the API ones and not their implementations). Our approach has been to add the Oracle libraries to our maven repository whenever they are required and let maven to control the whole dependency management.
As others say in their answers if you don´t want the dependencies to be included in any of your artifacts use
<scope>provided</scope>. Once you configure your development environment you will be grateful maven does the work and you can (almost) forget about dependency management. To build the JDeveloper IDE files we are using the maven jdev plugin, somvn jdev:jdevwould build generate our project files and set up dependencies on libraries and among them to compile properly.Updated:
Of course, you need to refer to ADF libraries in your pom files. In our project we just refer to the ones used on each application, say ADF Tag Libraries or a specific service, not the whole ADF/WebCenter stack. For this purpose use the "provided" scope. You can still let JDeveloper to manage your libraries, but we have found that it's simpler to either have a 100% JDeveloper libraries approach or a 100% maven approach. If you go with the maven approach it will take you some time to build your local repo at first, but once that's done it's very easy to maintain, and the whole cycle (development, build, test, packaging and deployment) will be simpler, having a more consistent configuration. It's true that in a future you'll have to update to later ADF versions, but as your repository structure will already be defined it should be something fast. For future upgrades I'd recommend to keep the ADF version as a property on the top pom, that will allow you to switch faster to a new version.