对于maven多模块项目，研发云流水线配置cd进某个子模块的目录，再执行mn package命令，如果运行时报借说找不到其他子模块的依赖，可以么解决

在Maven多模块项目中，当使用流水线（如CI/CD流水线）进行构建时，可能会遇到由于目录切换导致的依赖解析问题。以下是各个选项的解析以及为什么选择这些答案：

A. 子模块pom的parent节点定义relativePath指向上了一级的parent-pom：

解析：在Maven多模块项目中，每个子模块的pom.xml通常会引用一个父POM（parent-pom），该父POM定义了共同的依赖、插件管理等。如果子模块在父POM所在目录的下一级，则通常通过relativePath指定父POM的位置。这样，无论在哪个子模块目录下执行Maven命令，Maven都能正确地找到父POM，并通过父POM找到其他子模块的依赖关系。
选择原因：正确设置relativePath有助于Maven在任意子模块目录下都能解析依赖关系。

B. 把报错的子模块上传到私有制品库，然后流水线依赖库配置选择使用这个私有制品库：

解析：如果某个子模块已经构建并打包成JAR或WAR等制品，可以将其上传到私有Maven仓库中。在流水线配置中，添加对这个私有仓库的依赖，这样即使当前构建的子模块在本地找不到其他子模块的依赖，也可以从私有仓库中下载。
选择原因：这种方法适用于子模块之间已经存在制品化依赖的情况，或者作为临时解决方案。

C. 不cd进子模块目录，而是在parent-pom所在的目录执行mvn命令，同时通过mvn参数-am和-pl指定只编译构建这个子模块：

解析：-am（--also-make）参数会构建指定的模块以及它所依赖的模块；-pl（--projects）参数用于指定要构建的模块列表。在父POM目录下执行Maven命令，并通过这两个参数指定要构建的子模块，可以确保Maven在构建过程中正确处理依赖关系。
选择原因：这种方法避免了切换目录带来的依赖解析问题，直接在父POM目录下通过指定参数构建所需子模块。

D. 无法解决，放弃使用流水线：

解析：由于上述选项提供了多种可能的解决方案，因此这个选项是不正确的。放弃使用流水线并不是解决问题的合理方法。
不选择原因：放弃使用流水线是一种消极的解决方案，不利于项目的持续集成和持续部署。

综上所述，选项A、B、C都是解决Maven多模块项目在流水线中构建时遇到依赖问题的有效方法，因此选择ABC作为正确答案。