We Keep Coding

Java: Can't find symbol: class name, when the class name in one of two packages with the same name [duplicate]

I use maven to build a multi module project. My module 2 depends on Module 1 src at compile scope and module 1 tests in test scope.
Module 2 -
<dependency>
<groupId>blah</groupId>
<artifactId>MODULE1</artifactId>
<version>blah</version>
<classifier>tests</classifier>
<scope>test</scope>
</dependency>
This works fine. Say my module 3 depends on Module1 src and tests at compile time.
Module 3 -
<dependency>
<groupId>blah</groupId>
<artifactId>MODULE1</artifactId>
<version>blah</version>
<classifier>tests</classifier>
<scope>compile</scope>
</dependency>
When I run mvn clean install, my build runs till module 3, fails at module 3 as it couldn't resolve the module 1 test dependency. Then I do a mvn install on module 3 alone, go back and run mvn install on my parent pom to make it build. How can I fix this?

I have a doubt about what you are trying to do but but I'll assume you want to reuse the tests that you have created for a project (module1) in another. As explained in the note at the bottom of the Guide to using attached tests:
Note that previous editions of this guide suggested to use <classifier>tests</classifier> instead of <type>test-jar</type>. While this currently works for some cases, it does not properly work during a reactor build of the test JAR module and any consumer if a lifecycle phase prior to install is invoked. In such a scenario, Maven will not resolve the test JAR from the output of the reactor build but from the local/remote repository. Apparently, the JAR from the repositories could be outdated or completely missing, causing a build failure (cf. MNG-2045).
So, first, to package up compiled tests in a JAR and deploy them for general reuse, configure the maven-jar-plugin as follows:
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Then, install/deploy the test JAR artifact as usual (using mvn install or mvn deploy).
Finally, to use the test JAR, you should specify a dependency with a specified type of test-jar:
<project>
...
<dependencies>
<dependency>
<groupId>com.myco.app</groupId>
<artifactId>foo</artifactId>
<version>1.0-SNAPSHOT</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
</dependencies>
...
</project>

Regarding to my comment to Pascals question i think i have found a stuitable answer :
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
<phase>test-compile</phase>
</execution>
</executions>
<configuration>
<outputDirectory>${basedir}\target</outputDirectory>
</configuration>
</plugin>
</plugins>
The main difference here as you see here is the <phase> tag.
I will create the test-jar and it will be available in the compile phase of the tests and not only after the package phase.
Works for me.

neo4j procedure depending on signed jar (mapdb)

I have created a neo4j user-defined procedure. It also compiles and works in neo4j.
Recently though, I added a dependency to my procedure plugin that prevents neo4j from starting when I try to run the newly built jar. Concretely, I receive following exception at the bottom of the stack trace:
Caused by: java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
The only thing I changed is to add MapDB to my dependencies. So I suspect that it depends on some signed artifact. As it turns out neo4j plugins are "uber-jars" (i.e., shaded jars) which doesn't work very well with signed dependencies.
I figured I could try to exclude MapDB from the shading by changing the scope to provided and additionally adding the mapdb jar to plugins folder of neo4j. So the plugins folder of neo4j now includes both mapdb.jar and myprocedure.jar.
This doesn't seem to work though: neo4j starts, but when calling my procedure I receive a ClassNotFound Exception.
Any ideas on how I can solve this dilemma? I really depend on something like MapDB as my graph is very large and keeping everything in my procedure in-memory regularly leads to memory exceptions.
Many thanks in advance!
The important part of my pom.xml should it help (I started off with the procedure template so it still looks quite similar):
<dependencies>
<!-- other dependencies that don't make a difference ... -->
<dependency>
<groupId>org.mapdb</groupId>
<artifactId>mapdb</artifactId>
<version>3.0.7</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.neo4j</groupId>
<artifactId>neo4j</artifactId>
<version>${neo4j.version}</version>
<scope>provided</scope>
</dependency>
<!-- Test Dependencies -->
<dependency>
<groupId>org.neo4j.test</groupId>
<artifactId>neo4j-harness</artifactId>
<version>${neo4j.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.neo4j.driver</groupId>
<artifactId>neo4j-java-driver</artifactId>
<version>1.4.2</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<!-- Neo4j Procedures require Java 8 -->
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<!-- This generates a jar-file with our procedure code,
plus any dependencies marked as `compile` scope.
This should then be deployed in the `plugins` directory
of each Neo4j instance in your deployment.
After a restart, the procedure is available for calling. -->
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

So, one solution that worked was to use the maven-assembly-plugin instead of the maven-shade-plugin. The assembly plugin creates a standalone jar with all dependencies without re-packaging all dependencies.
Of course, I had to remove the <scope>provided</scope> for mapdb so it is also included in the assembled jar.
The rest is just replacing the shade plugin with following snippet (thanks to this question here):
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
Afterwards I received another exception which I thought was due to a wrong signature:
Caused by: java.lang.VerifyError ...
Turns out this was just because I had another procedure in neo4j that uses the same dependencies as mapdb. Quick fix was to remove that procedure library.
Of course, there are also other solutions, including removing the signature, or re-signing it. However, I explicitly did not want to remove any signatures.

I'm not aware that neo4j is checking any jar signatures by default. I suspect the repackaging of mapdb artifact being the culprit.
To validate that, remove the shade or assembly plugin in and build a jar that solely contains your code. Copy that jar and the mapdb.jar into the plugin folder and observe logs during a restart.

How to read depedency version from properties file [duplicate]

This question already has answers here:
Reading Properties file from POM file in Maven
(2 answers)
Closed 6 years ago.
I have one maven project. I want to externalise maven dependancy version to external property file.
I tried with property file plugin I is not reading property file.
config.properties
springframework.version=4.2.5.RELEASE
POm.xml file
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.estuate.test</groupId>
<artifactId>testPom</artifactId>
<version>0.0.1-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-1</version>
<executions>
<execution>
<phase>pre-clean</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>config.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${springframework.version}</version>
</dependency>
</dependencies>
still I am gettting error message as
build.plugins.plugin[org.codehaus.mojo:properties-maven-plugin].dependencies.dependency.version' for org.springframework:spring-core:jar must be a valid version but is '${springframework.version}'
Please help me out.

When you add a plugin with a custom execution, like you do, then you must realise that it only executes in the phases you specify. You specify pre-clean phase, which is part of the clean lifecycle, and not part of the build lifecycle.
Maven is composed of lifecycles, which execute up to a given phase. A command of mvn compile actually means run the build lifecycle all phases up to and including the compile phase.
Two of the standard lifecycles are (not complete list):
clean :: pre-clean -> clean -> post-clean
build :: validate -> compile -> test -> package -> verify -> install -> deploy
The dependencies specified are probably used by the standard plugins for the compile phase, so the properties needs to be available at that time.
When you state the pre-clean phase, the properties are available when you execute mvn clean.
For the properties to be available at compile phase, you should probably bind to the validate phase instead.
Although very verbose, there is actually quite a few hints running in debug mode with mvn -X, but it may be too much to comprehend at first.
Some more information about maven lifecycles here : https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

you can use maven properties plugin which is one of the suggested way to read property files in maven projects. below is the plugin details
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-1</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>Versions.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${springframework.version}</version>
</dependency>
</dependencies>
Version.properties file looks like
springframework.version=4.2.5.RELEASE

I think .
You should assign a Spring version to the springframework.version statement.
For example
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.3.1-REALESE</version>
</dependency>
then the other dependencies
<dependency>
<groupId>...framework...</groupId>
<artifactId>spring-...</artifactId>
<version>${springframework.version}</version>
</dependency>

Maven won't exclude during copy-dependencies

I have a project that uses Netty 4.0.29 and I have another dependency that pulls in netty 3.9.0. I put in an exclusion but it is still roping in 3.9.0 when I run copy-dependencies.
<dependency>
<groupId>com.ning</groupId>
<artifactId>async-http-client</artifactId>
<version>1.9.31</version>
<exclusions>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty</artifactId>
</exclusion>
</exclusions>
</dependency>
If I run mvn dependency:tree with this exclusion in place, I see that it is indeed excluded:
[INFO] +- com.ning:async-http-client:jar:1.9.31:compile
But when I run mvn clean dependency:copy-dependencies I see the jar 3.9.0 being copied along with the 4.0.29. According to the documentation and Google, this should not copy when there is an exclusion.
[INFO] Copying netty-3.9.0.Final.jar to /Users/udonom1/wk/141/coursecopy-api/target/dependency/netty-3.9.0.Final.jar
[INFO] Copying netty-all-4.0.29.Final.jar to /Users/udonom1/wk/141/coursecopy-api/target/dependency/netty-all-4.0.29.Final.jar
I tried excluding as suggested by the first answer below and that did not work.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>process-sources</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration> <outputDirectory>${project.build.directory}/lib</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
<excludeArtifactIds>io.netty:netty:3.9.0.Final</excludeArtifactIds>
</configuration>
</execution>
</executions>
</plugin>
I also added a dependency as further suggested:
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
<version>4.0.29.Final</version>
</dependency>
What am I doing wrong?

For those who are having the same issue. I used mvn -X and discovered that dependency:tree is omitting two other jars that are referencing netty. I added exclusions for those and I'm good to go. Spent a whole day on this.

If you are writing not library you have simple way to control versions of any dependency in your project - dependencyManagement block in root pom file, example:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty</artifactId>
<version>4.0.29.Final</version>
</dependency>
</dependencies>
</dependencyManagement>
Additional bonuses from this block - you can omit version and scope for dependency in concrete dependency (with same group id, artifact id and packaging).
PS another look to your dependencies make me ask you: are you sure that this dependency have single maven artifact id? netty-all-4.0.29.Final.jar - seems that this artifact should have netty-all artifact id... If they have different artifact id's my recipe wouldn't help. In this case you should define build configuration for maven-dependency-plugin, example:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<configuration>
<excludeArtifactIds>io.netty:netty:3.9.0.Final</excludeArtifactIds>
</configuration>
</plugin>
</plugins>
</build>
or just use -DexcludeArtifactIds parameter in your maven call

Maven vs. AspectJ - Example?

MY aspect works great from Eclipse with AspectJ plugin, however if I try to use it with Maven I get .... nothing.
I tried this http://mojo.codehaus.org/aspectj-maven-plugin/includeExclude.html
I add loggin in my aspect and I try to test it with junit test, but when I run
mvn clean
mvn test
I get...
[INFO] [aspectj:compile {execution: default}]
But i dont see logging in test
If I do compiling in Eclipse it works find, but Id like it to be IDE Independent(so I could use it with Hudson)
P.S. I use .aj file for Aspect
I tried to Google it, but I cant find any working example.

Without seeing your POM it's hard to say, one thing to check is that Maven expects your aspects to be under src/main/aspect rather than src/main/java by default.
You also need to ensure the aspectj runtime library is on your classpath (in Eclipse it is included by the AJDT classpath container.
For example (from the plugin documentation):
<project>
...
<dependencies>
...
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>1.6.2</version>
</dependency>
...
</dependencies>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<goals>
<goal>compile</goal> <!-- use this goal to weave all your main classes -->
<goal>test-compile</goal> <!-- use this goal to weave all your test classes -->
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
<build>
...
</project>
If neither of these work, can you post your pom contents? It might help to identify the problem.