We Keep Coding

Maven - "Package from transitive module dependency referenced, declare a direct dependency to fix."

I never worked with Maven before, but after having a lot of problems with mockito dependencies in my Netbeans module, I decided to create a new one using Maven and move everything to this new project. After some time doing so, I managed to get the module running just ok.
The problem is that when I use some functionalities that require the Netbeans API I get an exception.
My guess is that the problem is in the dependencies declared in pom.xml. In some of the imports that I use in my application, I get the following message:
Package from transitive module dependency referenced, declare a
direct dependency to fix.
When I clean and build or run mvn clean install in the root directory I get this error:
Project uses classes from transitive module
org.netbeans.api:org-netbeans-modules-projectapi:jar:RELEASE73 which
will not be accessible at runtime.
To fix the problem, add this module as direct dependency. For OSGi bundles that are supposed to be wrapped in NetBeans modules, use the
useOSGiDependencies=false parameter
In the org.codehaus.mojo plugin declaration (which was the only one that had the useOSGiDependencies tag) I tried to change useOSGiDependencies=true to useOSGiDependencies=false but that didn't work. I also tried to change RELEASE73 to RELEASE82, since I am using Netbeans 8.2 but that didn't work as well. I also tried a bunch of other possible solutions that I found on google, but none seemed to work for me.
These are the Netbeans api dependencies that I have in my pom.xml file:
<dependencies>
<dependency>
<groupId>org.netbeans.api</groupId>
<artifactId>org-netbeans-modules-project-libraries</artifactId>
<version>RELEASE73</version>
</dependency>
<dependency>
<groupId>org.netbeans.api</groupId>
<artifactId>org-netbeans-api-annotations-common</artifactId>
<version>RELEASE82</version>
</dependency>
<dependency>
<groupId>org.netbeans.api</groupId>
<artifactId>org-openide-util</artifactId>
<version>RELEASE82</version>
</dependency>
<dependency>
<groupId>org.netbeans.api</groupId>
<artifactId>org-openide-awt</artifactId>
<version>RELEASE82</version>
</dependency>
<dependency>
<groupId>org.netbeans.modules</groupId>
<artifactId>org-netbeans-core</artifactId>
<version>RELEASE73</version>
</dependency>
<!-- ... -->
</dependencies>
I looked everywhere but couldn't find a straightforward answer on how to declare a direct dependency.
Can anyone explain to me what am I doing wrong here?

After digging a bit more, I found that I had to add all the dependencies manually. This answer helped me a lot.
I just lack experience with maven. Basically I googled org-netbeans-modules-projectapi:jar:RELEASE73 maven entered the first link and added the needed dependency to my project.

difference between com.sun.jna and net.java.dev.jna?

I'm looking through the central maven repository and seeing a net.java.dev.jna and a com.sun.jna groupId for JNA. The github for JNA, using the com.sun.jna path as the directories in their source code, indicates that 4.1 has been pushed into the repository as part of a comment, but I'm seeing net.java.dev.jna at 4.1 and com.sun.jna at 3.0.
Obviously, I want to use JNA, but am baffled. What's going on with this package?

The correct 4.1 version to use is net.java.dev.jna:
<dependency>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna</artifactId>
<version>4.1.0</version>
</dependency>
The package name still seems to be com.sun.jna, but if you look in the POM file, the Maven coordinates have become net.java.dev.jna:jna.
They seem to have been that way for quite a long time, based on the MVN respository results.

How to include/ refer jackson-all.jar in maven

I am unable to find the repository entry for jackson-all.jar
Not sure why rather i could see individual jackson jars informations.
So,
how to refer the jackson-all.jar ?

For Jackson 2 have a look at the com.fasterxml.jackson groups. I normally have the following added to my dependencies:
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.4.1.3</version>
</dependency>
You may also need a jax-rs-module. See the official download page or github for information on how Jackson is divided into packages.

jackson-all.jar does not exist as a Maven dependency.
The list of all artifacts in the group org.codehaus.jackson are at http://mvnrepository.com/artifact/org.codehaus.jackson.
Just add dependency elements in your pom.xml for the artifacts you directly need in your application. Maven will make sure that all other artifacts these depend on will be included in your project.
Edit: If you use a Java IDE, it will help you look up the missing dependencies for every class you use in your code.

I stumbled onto http://repo1.maven.org/maven2/com/fasterxml/jackson/jr/jackson-jr-all - it looks like what you want. How you add that to maven though, i'm not sure.

Maven: benefit of specifying dependencies's versions as properties for single module project

On various projects I've been working on, I've seen diferent ways of specifying dependencies versions. On some projects, the package version is written on the same dependency declaration:
<dependency>
<groupId>org.apache.myfaces.extensions.validator.validation-modules</groupId>
<artifactId>myfaces-extval-property-validation</artifactId>
<version>2.0.7</version>
<scope>compile</scope>
</dependency>
On others, a property is used, as in:
<dependency>
<groupId>org.apache.myfaces.extensions.validator.validation-modules</groupId>
<artifactId>myfaces-extval-property-validation</artifactId>
<version>${versions.extval}</version>
<scope>compile</scope>
</dependency>
For multimodule projects, I can see a clear benefit in declaring versions on the parent pom to avoid duplication (and the potential confusion and errors that come with it), but on single module applications, would there be a benefit to use such a level of indirection?
What would be a best practice for this and why?
Thanks a lot :)

With a version property you can override it on the command line whereas with a fixed version you cannot.
So you can recompile your project with a newer version just by specifying it on the command line.
mvn -Dversions.extval=2.0.8 clean package
Or something.
apart from that, mostly used on multi-projects, and although there you have the dependency management section as well for versions.

Solving Maven dependency convergence issues

I use the maven-enforcer-plugin to check for dependency convergence issues. A typical output would be:
[WARNING] Rule 1: org.apache.maven.plugins.enforcer.DependencyConvergence failed
with message:
Failed while enforcing releasability the error(s) are [
Dependency convergence error for junit:junit:3.8.1 paths to dependency are:
+-foo:bar:1.0-SNAPSHOT
+-ca.juliusdavies:not-yet-commons-ssl:0.3.9
+-commons-httpclient:commons-httpclient:3.0
+-junit:junit:3.8.1
and
+-foo:bar:1.0-SNAPSHOT
+-junit:junit:4.11
]
Seeing this message, I would normally "solve" it by excluding the transitive dependency, e.g.
<dependency>
<groupId>ca.juliusdavies</groupId>
<artifactId>not-yet-commons-ssl</artifactId>
<version>0.3.9</version>
<exclusions>
<!-- This artifact links to another artifact which stupidly includes
junit in compile scope -->
<exclusion>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</exclusion>
</exclusions>
</dependency>
I'd like to understand whether this is truly a fix and the risks involved in excluding libraries in this fashion. As I see it:
The "fix" is normally safe, provided I'm choosing to use the newer version. This relies on the library authors maintaining backwards compatibility.
There is typically no impact on the Maven build (since the nearer definition wins), however by excluding the dependency I'm telling Maven that I know about this problem and thus appeasing the maven-enforcer-plugin.
Are my thoughts correct and is there an alternative way of handling this issue? I'm interested in answers that focus on the general case - I realise the junit example above is a little strange.

We all agree that JUnit should never be set to another scope than test. Generally speaking I don't think either that there is another solution than excluding the unwanted dependency, so we all agree that your are right to do it.
A SIMPLE CASE :
As Andreas Krueger says, there may be a risk with versions (I actually encountered it). Let say that the project's dependencies are the following:
+-foo:bar:1.0-SNAPSHOT
+-group1:projectA:2.0
+-group2:projectB:3.8.1
+-group2:projectB:4.11
Note that it is only a mere simplification of your case. Seeing this dependency tree, you would exclude the dependency projectB given by projectA :
<dependency>
<groupId>group1</groupId>
<artifactId>projectA</artifactId>
<version>2.0</version>
<exclusions>
<exclusion>
<groupId>group2</groupId>
<artifactId>projectB</artifactId>
</exclusion>
</exclusions>
</dependency>
After packaging the project with maven, the remaining dependency would be group2-someProjectB-4.11.jar, version 4.11 and not 3.8.1. Everything would be fine and the project would run without encountering any problem at all.
Then, a while after, let say that you decide to upgrade to the next version of project A, version 3.0 which adds new great features :
<dependency>
<groupId>group1</groupId>
<artifactId>projectA</artifactId>
<version>3.0</version>
<exclusions>
<exclusion>
<groupId>group2</groupId>
<artifactId>projectB</artifactId>
</exclusion>
</exclusions>
</dependency>
The problem is that you are not aware yet that projectA version 3.0 also have upgraded its dependency projectB to version 5.0 :
+-foo:bar:1.0-SNAPSHOT
+-group1:projectA:3.0
+-group2:projectB:5.0
+-group2:projectB:4.11
In that case, the exclusion you would have made a while ago excludes projectB version 5.0.
However, projectA version 3.0 needs the improvements from project B version 5.0. Because of the exclusion, after packaging the project with maven, the remaining dependency would be group2-someProjectB-4.11.jar, version 4.11 and not 5.0. At the moment you use any of projectA's new features, the program wouldn't run correctly.
WHAT WAS THE SOLUTION ?
I encountered this problem in a Java-EE project.
A team developped database services. They packaged it as projectA. Each time they updated the services, they also updated a file listing all their current dependencies and the current versions.
ProjectA was a dependency for the Java-EE project I was working on. Each time the service-team updated ProjectA, I also checked the versions' updates.
In fact, there is no harm in excluding a dependency. But each time you update a dependency where an exclusion has been set, You have to check :
if this exclusion still makes sense.
if you need to upgrade the version of the excluded dependency in your own project.
I guess maven exclusions are like kitchen knifes. It's sharp, cuts vegetables with no effort, but requires care when handling it...

If JUnit as an artifact is coming through as a dependency in compile scope, it is a bug of one of your libraries, here: ca.juliusdavies.
JUnit should always be included in test scope. Thus, it is not packed into the produced .jar, .war or .ear file, on successful build.
Generally speaking, there is no harm in excluding already included dependencies, as when library 1 and library 2 share one common dependency.
The only problem, of course, that can occur, is when library 1 and library 2 include different versions of the same dependent artifact. This can cause run-time errors, when the features of the library have changed.
Fortunately, this is not often the case, unless the difference in the version numbers is great. In general, it is advisable to include the latest dependency version and exlude the older one. This is most of the time viable.
If not, check wheter there are updates to the first-level dependencies of your project.