复杂的文件夹结构导致Maven编译复杂 [英] Maven compilation complication due to complex folder structure

查看:68
本文介绍了复杂的文件夹结构导致Maven编译复杂的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我某种程度上想通过Maven构建复杂的项目结构.我正在使用本地存储库(.m2/repository),因此请记住这一点!在讨论问题之前,我想先分享一下我目前拥有的结构:

I've somehow complex structure of projects which I want to to build via Maven. I am using my local repository (.m2/repository) so keep this in mind! Before talking about the problem, I'd like to first share the structure that I currently have:

+- pom.xml
+- runtimeProject1
|  +- pom.xml
+- runtimeProject2
|  +- pom.xml
+- runtimeProject3
|  +- pom.xml
+- sharedProjects
|  +- pom.xml
|  +- sharedProject1
|  |  +- pom.xml
|  +- sharedProject2
|  |  +- pom.xml
|  +- sharedProject3
|     +- pom.xml
+- coreProjects 
   +- pom.xml
   +- coreProject1
   |  +- pom.xml
   +- coreProject2
   |  +- pom.xml
   +- coreProject3
      +- pom.xml

因此,总而言之,我的工作空间有2个子目录,其中包含与自己的任务相关的模块,以及应使用coreshared.项目的运行时项目.每个项目都有一个pom.xml文件,如您所见,我的父母也有pom.xml个文件.一切都是通过本地存储库完成的,因此请记住这一点.

So in summary, my workspace has 2 subdirectories in which there are modules related to their own tasks, and runtime projects which are supposed to use core and shared. projects. Each project has a pom.xml file, and as you can see I also have pom.xml for parents. Everything is done via local repository, so keep this in mind.

现在,分别在sharedProjectscoreProjects目录下运行mvn install可以正常工作.我看到成功输出,说一切正常.当我从根文件夹(顶级)运行完全相同的命令时,就会出现问题.我面临以下警告:

Now, running mvn install under the directories of sharedProjects and coreProjects separately works fine. I see the success output, saying that all is OK. The problem occurs when I run the very same command from the root folder, the top-level pom.xml. I face the warnings of:

[WARNING] Some problems were encountered while building the effective model for runtimeProjects:runtimeProject1:jar:1.0.0
[WARNING] 'dependencies.dependency.systemPath' for coreProject:com.google.protobuf:jar should not point at files within the project directory, ${project.basedir}/../coreProject/com.google.protobuf/protobuf-java-2.5.0.jar will be unresolvable by dependent projects @ line 31, column 22
[WARNING] 'dependencies.dependency.systemPath' for sharedProject:org.boofcv:jar should not point at files within the project directory, ${project.basedir}/../sharedProject/org.boofcv/GeoRegression.jar will be unresolvable by dependent projects @ line 43, column 22
[WARNING] 'dependencies.dependency.systemPath' for sharedProject:org.boofcv:jar should not point at files within the project directory, ${project.basedir}/../sharedProject/org.boofcv/BoofCV.jar will be unresolvable by dependent projects @ line 50, column 22
[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: sharedProject:org.boofcv:jar -> duplicate declaration of version 1.0.0.qualifier @ line 45, column 16
[WARNING] 'dependencies.dependency.systemPath' for sharedProject:javax.vecmath:jar should not point at files within the project directory, ${project.basedir}/../sharedProject/javax.vecmath/vecmath.jar will be unresolvable by dependent projects @ line 62, column 22

,然后错误地说出某些package do not exist,我想这是这种并发症的结果.

and then errors saying certain package do not exist, which I guess results from this complication.

我想我需要在这里更改pom.xml之一,但不知道该如何更改.

I guess I need to alter one of the pom.xmls here, but don't know which and how.

更新:我决定分享使用某些.jar文件作为依赖项的方式,所以就这样:

Update: I decided to share the way I use some of the .jar files as dependency, so here it is goes:

<dependency>
         <groupId>coreProjects</groupId>
         <artifactId>com.google.protobuf</artifactId>
         <version>2.5.0</version>
         <scope>system</scope>
         <systemPath>${project.basedir}/../coreProjects/com.google.protobuf/protobuf-java-2.5.0.jar</systemPath>
   </dependency>
    <dependency>
         <groupId>coreProjects</groupId>
         <artifactId>org.apache.felix</artifactId>
         <version>1.0.0</version>
         <scope>system</scope>
         <systemPath>${project.basedir}/../coreProjects/org.apache.felix/felix.jar</systemPath>
   </dependency>

请注意,这些文件在coreProjectssharedProjects文件夹下可以正常工作.只是不在runtimeProject(s)下,因此是我的问题.

Note that these work fine under coreProjects and sharedProjects folders. Just not under runtimeProject(s), hence my question.

更新2:

好吧,在评论员收到很多请勿将systemPathsystem用作作用域"警告之后,我重新构造了构建策略,现在我不使用任何与系统相关的东西.但是,问题仍然存在.现在,我这样指定依赖项(如您所见,没有路径相关的东西):

Okay, after getting a lot of "do not use systemPath and system as scope" warnings from the commentators, I restructured my build strategy and now I am not using any system related stuff. However, the problem persists. Now I specify the dependencies like this (as you can see no path related stuff is there):

<dependency>
         <groupId>coreProjects</groupId>
         <artifactId>coreProject2</artifactId>
         <version>1.0.0.qualifier</version>
   </dependency>
   <dependency>
         <groupId>coreProjects</groupId>
         <artifactId>coreProject1</artifactId>
         <version>1.0.0.qualifier</version>
   </dependency>
   <dependency>
         <groupId>sharedProjects</groupId>
         <artifactId>org.boofcv</artifactId>
         <version>[1.0,)</version>
   </dependency>

我相信,我们站在安全的一面.以上警告已消失.截至目前,我仅遇到package does not exist错误.这很奇怪,因为它抱怨的软件包是在根目录的pom.xml文件中引用的.例如,错误之一是:

So we are on the safe side, I believe. The warnings above have disappeared. As of now, I simply get package does not exist errors. It's strange, because the packages it's complaining about are referenced in the pom.xml file of the root. One of the errors, for instance, is the following:

package org.osgi.framework does not exist

但是,还有其他事情引起了我的注意.我遇到的另一个错误不是直接给出程序包的名称,而是该程序包的一部分.例如,如果程序包名称为somePackageName,则错误显示为somePackageName.somePart does not exist.因此,它不是整个软件包,而是其中的一部分,这使我更加困惑.

However, something else caught my attention. The other error I am having, does not directly give the name of the package, but rather a part of that package. For instance, if the package name is somePackageName, the error says somePackageName.somePart does not exist. So it is not the entire package, but only a part of it, which makes me even more confused.

这可能是什么原因?

推荐答案

好的,看来我在做一个简单的错误.我的proto文件被转换为错误目录下的java文件,从而导致package does not exist错误.因此,如果看到此错误,并且以某种方式利用协议缓冲区,请检查pom.xml中的antrun-plugin.确保它在正确的目录下运行.在这里,我分享了我的原型文件生成的antrun-plugin部分.询问您是否可以看到,目录确实很重要,因此请非常小心.

OK, it seems there was a simple mistake that I was doing. My proto files were converted into java files at the wrong directory, leading a package does not exist error. So, if you see this error and if you are somehow utilising protocol buffers, do check your pom.xml for the antrun-plugin. Make sure it operates at the correct directory. Here I share my antrun-plugin part for my proto file generation. Ask you can see, directories do matter a lot, and thus be very careful with them.

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
           <executions>
             <execution>
               <id>generate-sources</id>
               <phase>generate-sources</phase>
               <configuration>
                 <tasks>
                   <mkdir dir="src-gen"/>
                   <exec executable="protoc">
                     <arg value="--java_out=src-gen"/>
                     <arg value="proto/file1.proto"/>
                     <arg value="proto/ros/file1.proto"/>
                     <arg value="proto/ros/file2.proto"/>
                     <arg value="proto/environment/file1.proto"/>
                   </exec>
                 </tasks>
                 <sourceRoot>src-gen</sourceRoot>
               </configuration>
               <goals>
                 <goal>run</goal>
               </goals>
             </execution>
           </executions>
         </plugin>

这篇关于复杂的文件夹结构导致Maven编译复杂的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆