维护内部Maven存储库的提示？ [英] Tips for maintaining an internal Maven Repository?

问题描述

我有兴趣为我的组织维护 Maven 2存储库。有哪些指针和陷阱会有所帮助。

I'm interested in maintaining a Maven 2 repository for my organization. What are the some of the pointers and pitfalls that would help.

在设置从自己的工件下载或将自己的工件发布到存储库的标准时，用户应遵循哪些指导原则何时发布他们的代码？您为此类事物制定了哪些治理/规则？您在开发人员的指南/文档中包含了哪些内容？

What are guidelines for users to follow when setting up standards for downloading from or publishing their own artifacts to the repository when releasing their code? What kinds of governance/rules do you have in place for this type of thing? What do you include about it in your developer's guide/documentation?

更新：我们已经站起来对Nexus表示非常满意 - 遵循Sal的大部分指导方针并没有遇到任何麻烦。此外，我们通过Hudson CI服务器限制了部署访问和快照构件的自动构建/部署。 Hudson可以分析所有上游/下游项目依赖项，因此如果编译问题，测试失败或其他一些违规导致构建中断，则不会发生部署。厌倦了在Maven2 / Maven3中进行快照部署，因为元数据在两个版本之间发生了变化。 仅限Hudson快照部署策略将缓解这种情况。我们不使用Release Plugin，但在版本插件周围编写了一些代码。要移动快照以释放。我们也使用m2eclipse，它似乎与Nexus很好地配合，因为从设置文件中它可以看到Nexus并且知道从那里索引工件信息以进行查找。 （虽然我不得不调整其中一些设置以使其完全索引我们的内部快照。）如果您对此感兴趣，我还建议您使用您的工件部署源jar作为标准做法。我们在超级POM中配置它。

UPDATE: We've stood up Nexus and have been very happy with it - followed most of Sal's guidelines and haven't had any trouble. In addition, we've restricted deploy access and automated build/deployment of snapshot artifacts through a Hudson CI server. Hudson can analyze all of the upstream/downstream project dependencies, so if a compilation problem, test failure, or some other violation causes the build to break, no deployment will occur. Be weary of doing snapshot deployments in Maven2/Maven3, as the metadata has changed between the two versions. The "Hudson only" snapshot deployment strategy will mitigate this. We do not use the Release Plugin, but have written some plumbing around the Versions plugin when going to move a snapshot to release. We also use m2eclipse and it seems to work very well with Nexus, as from the settings file it can see Nexus and knows to index artifact information for lookup from there. (Though I have had to tweak some of those settings to have it fully index our internal snapshots.) I'd also recommend you deploy a source jar with your artifacts as a standard practice if you're interested in doing this. We configure that in a super POM.

UPDATE2 ：我遇到过这个Sonatype白皮书详细介绍了采用/成熟的不同阶段，每个阶段都有不同的Maven资源库管理器使用目标。

UPDATE2: I've come across this Sonatype whitepaper which details different stages of adoption/maturity, each with different usage goals for a Maven Repository manager.

推荐答案

我建议设置一个至少有四个存储库的nexus服务器。我不推荐神器。免费版的nexus对于不到三组的开发团队来说非常好。如果你有更多的用户，请帮自己一个忙，并为Sonatype版本付费。 LDAP集成为自己付费。

I would recommend setting up one nexus server with at least four repositories. I would not recommend artifactory. The free version of nexus is perfectly fine for a dev team of less than 20 in less than three groups. If you have more users than that, do yourself a favor and pay for the Sonatype release. The LDAP integration pays for itself.

1. 内部版本


2. 内部快照


3. 内部第三方，用于内部使用的代码来自外部来源或已获得认可的第三方版本。在这里放置来自客户和合作伙伴的JDBC驱动程序，javax。*东西。


4. 外部代理所有常用来源的常用代理，如m2，codehaus等

1. Internal Release
2. Internal Snapshot
3. Internal 3rd Party for code used in house that comes from outside sources, or for endorsed 3rd party versions. Put the JDBC drivers, javax.* stuff and stuff from clients and partners here.
4. External Proxies common proxy for all the usual sources like m2, codehaus etc

配置Nexus以执行以下内部回购

Configure Nexus to do the following for internal repos

1. 定期删除旧快照


2. 删除发布时的快照


3. 构建索引文件。这也加速了本地构建

有一个公共的settings.xml文件，它使用这四个，只有这四个来源。如果您需要自定义此设置，请尝试保留设置文件的公共部分，并使用配置文件获取差异。不要让您的客户自行推出您最终会得到在一台计算机上构建但不在任何其他计算机上的代码。

Have a common settings.xml file that uses these four and only these four sources. If you need to customize beyond this try to keep a common part of the settings file and use profiles for the differences. Do not let your clients just roll their own settings or you will end up with code that builds on one machine but not on any other machine.

为您的客户提供通用代理。在Nexus中，您可以向常见的Maven源（Apache，JBoss，Codehaus）添加一堆代理，并将一个代理暴露给内部客户端。这样可以更轻松地从客户端添加和删除源。

Provide a common proxy for your clients. In Nexus, you can add a bunch of proxies to the common Maven sources (Apache, JBoss, Codehaus) and have a single proxy exposed to the internal clients. This makes adding and removing sources from your clients much easier.

不要在同一个存储库中混合内部和第三方工件。 Nexus允许您通过web gui将jar添加到内部存储库。我建议将此JDBC驱动程序和其他外部代码添加到第三方。与大多数企业软件相比，UI非常好用。

Don't mix Internal and 3rd party artifacts in the same repository. Nexus allows you to add jars to an internal repository via a web gui. I recommend this as the way of adding your JDBC drivers and other external code to 3rd party. The UI is quite nice to use when compared to most enterprise software.

定义一个共同的父POM 定义内部快照和发布回购通过 distributionManagement 标记。我知道很多人告诉你不要这样做。虽然我自由地承认这样做存在各种问题，但如果客户端只构建要部署到单个内部存储库的版本和快照，则可以正常工作。

Define a common parent POM that defines the Internal snapshot and release repos via the distributionManagement tag. I know lots of people tell you not to do this. And while I freely admit that there are all kinds of problems with doing this, it works out OK if the clients will only be building releases and snapshots to be deployed to a single internal repository.

如果您有一个错误管理的Maven存储库，请创建一个名为 Legacy 的第五个存储库并将整个回购那里。设置一个cron任务，一旦他们一岁，就从旧版中删除旧文件。这让每个人都有一年的时间离开它并更新他们的poms。

If you have an existing mis-managed Maven repository, create a 5th repos called Legacy and put the whole repos there. Set up a cron task to delete old files from legacy once they are a year old. That gives everyone a year to move off of it and update their poms.

建立易于遵守内部工件的命名约定。我更喜欢 Department.Function.Project 的GroupID和 componentName 的ArtifactId。对于内部存储库，com / org / net和公司名称可能无关紧要。如果公司更名，那就错了。销售，会计或库存部门重新命名的可能性要小得多。

Establish an easy to stick to naming convention for internal artifacts. I prefer GroupID of Department.Function.Project and an ArtifactId for that componentName. For internal repositories, com/org/net and the company name are likely to be irrelevant. And wrong if the company changes its name. It is far less likely that the sales, accounting or inventory department will be renamed.

这篇关于维护内部Maven存储库的提示？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！