英文:
How to share java dependencies from maven environment to non-maven environment
问题
我有两台服务器。
在第一台服务器上，已安装了Maven，而在第二台服务器上未安装Maven。
我的Kafka集群可以通过第二台服务器访问。
但是，Kafka库只能通过第一台服务器上的Maven导入。我应该如何将这些库迁移到第二台服务器？
我应该通过Maven在第一台服务器上将每个库导出为JAR文件，然后将这些JAR文件放到第二台服务器上吗？
英文:
I have two servers.
On first server, maven is installed and in second server maven is not installed.
My kafka cluster is accessible via second server.
But the kafka libraries can be imported via maven only on first server. How do I migrate these libraries to second server?
Should I export each library as a jar via maven in first server and then place these jars on second servers?
答案1
得分: 1
我不了解你的设置细节，但听起来很奇怪，你把我理解为生产环境（你在这里称为“服务器”的东西，你可能需要澄清一下）和构建工具链混在同一个问题中。
无论你的软件是什么，你没有义务在同一个地方运行和构建它 - 实际上，这两个地方相距越远越好。我的建议是设置不同的隔离环境：
- 构建/CI环境：一些 Jenkins、Buildkite 代理、Gitlab CI 代理，或者你喜欢的其他工具，用于在代码分支上构建可交付成果。这些可交付成果，例如使用 Maven 构建，并存储在某个地方（例如 S3 存储桶、FTP 服务器上的文件夹、Artifactory、Nexus等）。当然，在这个环境中没有 Kafka 或任何其他生产软件。
- 开发、预备、生产或其他你称之为的环境，建立在某种模板之上。这些环境不需要工具链，但需要你的应用程序所需的运行时环境。你可以使用 Chef 或类似工具构建常规机器，或者设置容器管理器，并使用你的CI构建你的软件的容器镜像。
源代码不应该存在于你的生产服务器上，所以你不需要在那里使用 Maven - 编译后的可交付成果将以适合你的形式（jar、ear、容器镜像等）由你选择的工具部署到那里。
我明白这并没有直接回答关于 Maven 的问题，但我认为这种设置将让你走得更远。
英文:
I have no details about your setup, but it sounds strange to me that you mix what I understand are productive environments (what you call "servers" here, you may like to clarify) and build toolchain in the same question.
Whatever your software is, you have no obligation to run and build it in the same place - actually, the further those 2 places are, the better. My proposal is that you set up different and isolated environments:
- Build/CI environment: some jenkins, buildkite agent, gitlab CI agent, whatever you like, that builds deliverables upon branches of your code. Those deliverables are built, e.g. with maven, and stored somewhere (an S3 bucket, folder in ftp server, an artifactory, nexus, whatever). Ofc there is no kafka or any other productive software in this environment.
- Dev, staging, prod, whatever you call them, environments, built upon some template. These need no toolchain but they need whatever runtime you need for your application. You can build regular machines with chef or something like that, or set up a container manager and use your CI to build container images of your software.
Source code should never be in your productive servers, so you need not maven there - the compiled deliverable will be deployed there in whatever form suits you (jar, ear, container image, whatever) by some tool of your choice.
I am aware that this does not give you a straight answer to a maven juggling question, but I think this kind of setup will bring you much further.
答案2
得分: 0
Your "non Maven connected" environment doesn't need "Maven" (in quotes because Gradle and sbt could be interchanged here). It, like all JVM environments, needs a CLASSPATH, including JARs and classes for dependency code.
You should use Maven Assembly plugin to build what is known as an uber/fat JAR, and distribute that.
Or, mentioned in other answer, you can do the same, but using Docker images as your distributable archive, perhaps using Jib Maven Plugin.
英文:
Your "non Maven connected" environment doesn't need "Maven" (in quotes because Gradle and sbt could be interchanged here). It, like all JVM environments, needs a CLASSPATH, including JARs and classes for dependency code.
You should use Maven Assembly plugin to build what is know as an uber/fat JAR, and distribute that.
Or, mentioned in other answer, you can do the same, but using Docker images as your distributable archive, perhaps using Jib Maven Plugin.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论