0

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

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.

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

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

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

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>

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

Update 2:

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>

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

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.

What might be the reason for that?

Schütze
  • 1,044
  • 5
  • 28
  • 48
  • See your today's question [Maven debug shows warnings and errors, but eventually compiles](http://stackoverflow.com/questions/38121520/maven-debug-shows-warnings-and-errors-but-eventually-compiles) and the answer regarding ``. – Gerold Broser Jun 30 '16 at 13:17
  • Well I read that part, but I don't exactly get how it causes the problem I am facing here? These paths work in all other projects (under core and runtime) so I fail to see how is that the problem. – Schütze Jul 01 '16 at 07:09
  • You should not use ``... using a dependency without `system`scope will download the artifact from a repository and use it. If you use `systemPath` this makes your build depending on your system which means the location of the path. If someone else will build the same project it will fail. – khmarbaise Jul 01 '16 at 08:00
  • Then how can I refer to the jars that I need maven to look for? I don't want to download anything from internet, it's a confidential project, I **must** use these jars. – Schütze Jul 01 '16 at 08:03
  • See your yesterday's question [Maven debug shows warnings and errors, but eventually compiles](http://stackoverflow.com/questions/38121520/maven-debug-shows-warnings-and-errors-but-eventually-compiles) and the points 1. and 2. in the answer. – Gerold Broser Jul 01 '16 at 08:14
  • Any command line argument is not acceptable, since this will run on jenkins and there are other complications, so 1. in the answer is out of options. As for the 2., I'll read the source you wrote there and see if it will work out for me. However, for the time being, this is no answer. – Schütze Jul 01 '16 at 08:27
  • @GeroldBroser I fixed the related parts. Now, we are literally "system-free". – Schütze Jul 04 '16 at 13:15

1 Answers1

0

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>
Schütze
  • 1,044
  • 5
  • 28
  • 48