I have a project that I came back to a couple months since last working on and noticed the majority of the external classes I've been importing and using in my project are now invalid and unable to be found. Pic attached
And when I run maven clean install, I get errors along the lines of
java:[141,17] reference to JsonNode is ambiguous, both class org.codehaus.jackson.JsonNode in org.codehaus.jackson and class com.fasterxml.jackson.databind.JsonNode in com.fasterxml.jackson.databind match
There are several errors of this kind, referencing the line numbers that use the classes unable to be imported.
Could these issues be related? If so what's a simple way to just to reinstall the libraries I need to use in the project and get rid of the collisions?
Thanks for any help,
-Adam
If you didn't change anything in the project, the maven build probably picked up a newer version of some dependency in your pom.xml. You probably have some dependencies on the latest release or on version ranges for some artifacts, as described in this question.
My guess is that the dependency on jackson-databind has changed from 2.2.x to 2.3.0, which was released to the maven central repository quite recently (see here). Between 2.2.x and 2.3.0, they moved the class JsonNode into the package com.fasterxml.jackson.databind
If this is the cause of the problem, the build will be more repeatable and consistent if you set specific version dependencies, or at least narrower ranges, in the pom. In the case of jackson-databind, try setting the version to 2.2.3
Check your classes that the compile error is referring to. You probably have some imports like:
import org.codehaus.jackson.*;
import com.fasterxml.jackson.databind.*;
Then later you are trying to use a JsonNode. The compiler is telling you that's "ambiguous" because both of the above imports have a class named "JsonNode". You just need to call out which JsonNode you want by specifying it with the full classpath in your code.
org.codehaus.jackson.JsonNode node = new org.codehaus.jackson.JsonNode();
(Or something like that)
Once your maven build finishes, those other errors will probably go away in your IDE Screenshot.
Related
I wanted to read the source code of a java project, so I cloned the project into a directory, and opened it in VSCode. The project used gradle as a dependency manager. None of the dependencies were downloaded, so I ran
gradle --refresh-dependencies
This seemed to work in getting everything setup, but there were many different errors such as
Cannot make a static reference to the non-static method reload() from the type FastRegistry
This error seemed to be the most common, but VSCode reports 2000 errors. I should mention that this project is a Minecraft Mod, so there may be some conflict with the source code and the mapped class names. I am still a beginner at this kind of stuff, so hopefully there is a simple solution. Here is a link to the project: https://github.com/PorkStudios/FarPlaneTwo/
After asking the project owner about this, I found that this project uses lombok annotations. Because of the weirdly formatted annotations, everything was thrown off.
To fix this for VSCode, which does not support these annotations by default, install the extensions for it.
In addition to this, if you have already loaded the project, you will need to clean the workspace.
Using maven version 3.6.3 and JDK version "openjdk-17"
I've tried using Maven's dependencies so I could use the xstream library in my project. Following a guide I added com.thoughtworks.xstream to my pom.xml file:
I then tried to use xstream, but intellij couldn't resolve "XStream" even though it seems to work for JavaFX just fine. This code does not compile.
EDIT: I loaded a new project, where I used, what I believe to be, up to date versions. Maven 3.8.1, the latest intellij version, and everything else (JDK, openjfx) at version 17.0.2 yet when I try to use "XStream" in my project code (after reloading the maven project) it says "Cannot resolve symbol XStream"
Edit 2:
I added junit to the dependencies, it works. I add Gson to the dependencies. It doesn't work.
I figured out that in the "modules-info.java" file, "requires xstream" is needed. That is all
One of the following may solve your problem:
These are based on my previous experiences.
because may be auto import disabled. re Import maven project.(intellij: press Ctrl+Shift+A then actions - input "reload" find "Reload All Maven Projects").
in my experience, sometimes it does happen that the dependency is not fully received. remove xstream special version folder from .m2 (com->thoughtworks->xstream) and repeat step 1.
maybe repository not valid. check repository source in file settings.xml in .m2 (if exist) or replace to other source.
invalid cache and restart (intellij: file-> invalid caches/restart). This has solved my problem several times.
Your access to the site or repository may be closed. check network policy or use vpn (Poor probability)
When I execute in my Maven project the Versions Maven Plugin plugin with the command:
mvn versions:use-latest-versions
The pom.xml is updated with updated dependencies as it is supposed to do.
The problem is that some libraries are updated to version as new as the do not contains some of the packages used in previous versions so the compiler says package not found. Does anybody know how to avoid automatically? I mean, update to the latest version which have the packages and classes I am using in my code.
In my opinion, there is no easy way to determine which version update is "save".
Even if you would check that all classes you compile against still exist, method signatures might have changed. And even if all the method signatures stay the same, the behaviour might have changed, leading to runtime exception etc.
The only reasonable way I know to check a version update is to run a compile and run all test cases. Doing this for all combinations of possible version updates is possible but it will take a lot of time.
The plugin is not going to analyse your code and adjust the dependencies version accordingly.
The objective of the goal use-latest-versions is to upgrade your project to the latest release of your project dependencies, and as a result of you may have compilation and deployment problems.
Once you identified the problems you need to fix all the problems so that your whole project is upgraded to the latest releases of your dependencies.
The problem is that some libraries are updated to version as new as
the do not contains some of the packages used in previous versions so
the compiler says package not found. Does anybody know how to avoid
automatically? I mean, update to the latest version which have the
packages and classes I am using in my code.
Of course, it is not possible.
Updating dependencies is not a game of chance.
If you need to have the last version of a dependency, you should not worry about if this version breaks or doesn't break your code because you need it.
You update a library because you need to update that version. If you don't need to update your dependencies, don't update your dependencies, but if you need to do that, you should make the work to update your code too if necessary.
I'm trying to run Simple Hierarchy example of OWL API. I included owlapi-osgidistribution-4.0.2.jar and all libraries from its lib folder to the project class path. However I still have one unresolved import:
import static org.semanticweb.owlapi.search.EntitySearcher.getAnnotationObjects;
And one undefined method associated with that import:
for (OWLAnnotation anno : getAnnotationObjects(clazz, ontology)) {
anno.accept(le);
}
I see that EntitySearcher class is in the OWL API library. Have I missed something?
EntitySearcher is in the owlapi-api module, so should be found in your classpath.
That example is compiled routinely with each owlapi build, so it should not present any particular problem.
Note: I can't recall if the method you mention was added before or after 4.0.2 was released. It is possible that it was added for 4.1.0.
I went through the exact same instance of the problem yesterday, interesting coincidence.
The code that you're looking at is supposed to work with the latest version of the OWL API, namely 4.1.0-RC4. I've found hints to the problem browsing through the mailing list. Unfortunately the only available packaged version right now is the 4.0.2, and the latest version on the Maven repositories is 4.1.0-RC2, which didn't ship with the method used in the example.
The way I temporarily "solved" the problem was to use the Maven dependencies targeting version 4.1.0-RC2 and adding to the classpath the binary distribution for 4.1.0-RC4 built from the git repository (overriding the one for the older version resolved by Maven).
Assuming you know how to use Maven, this is the relevant entry of the POM file:
<dependency>
<groupId>net.sourceforge.owlapi</groupId>
<artifactId>owlapi-osgidistribution</artifactId>
<version>4.1.0-RC2</version>
</dependency>
To build the latest version of OWL API, just clone the git repository or download it as a zip file, extract and then run mvn clean install: the jar you want to add to your classpath should be present in the ./distribution/target/ directory.
You're also likely to get some warnings about the logger, if you want to fix that as well you need to get the tarball of slf4j with version matching the one that was resolved by Maven (from here, the version I used is 1.7.7), build it and then add slf4j-simple-#.#.#.jar to your classpath.
Hope this helps.
I have a project which depends on a JAR file. The version of this JAR changes often and we are having a hard time trying to ensure we are using the correct one. It is also causing problems when investigating bugs: which version of JAR contains the bug. Some programmers may forget to update corresponding dependencies and include 2 versions of this JAR inside the project, so that an old version may be found by the classloader.
A question is how to account for this issue.
I have a following plan:
1) When an error occurs log the JAR name I am working with to ensure it is a correct version. I plan to use something like
this.getClass().getResource(someResourceINeedFromThatJar).getFile()
2) I can write a test to account for this. But I don't know how I can run a test AFTER the package phase of my Maven build
3) Maybe you can suggest something else for this?
Well, We have same scenario and solved issue by using maven dependencyManagement
It does two things.
Set a default version for dependencies in submodules/child projects
override the version of transitive dependencies
it does override a specified value in a transitive dependency.
The enforcer plugin does not ignore the dependencyManagement. But is unable to recognize the discrepancy since the transitive dependency's version was altered before it went to work.
Here is a nice article : You can go through it:
http://andydennie.com/2012/08/02/maven-enforcer-plugin-vs-dependencymanagement/
And another source: http://maven.apache.org/enforcer/maven-enforcer-plugin/