The POM for org.apache.cxf:cxf:jar:2.4.2 is invalid, transitive dependencies (if any) will not be available
It seems like the .pm file that captures the dependency information got corrupted (either when dowloading or is already corrupted in the central repository). Try a different version
Related
I have following project structure:
rootProject.name = 'toolbox-backend'
include 'toolbox-components-executor'
include 'toolbox-components-toolsyncer'
include 'toolbox-components-toolconfigparser'
toolsyncer i.e. has the dependency for the jgit library. While trying to edit the code in the service java file I see that IntelliJ shows the resolve in red - so it isn't found.
I found out that this happens when I resolve all projects at the same time. The toolsyncer subprojects shortly resolved the dependency but gets its dependencies removed as soon as the next subprojects starts to resolved and therefore removes the jgit dependency since it does not need it.
Whats the best practise here? Declare all dependencies needed in the root project?
Is there a way to tell Ivy to prefer the latest version of a particular library among the transitive dependencies, without turning the transitive dependency into a direct dependency?
After retrieving the artifacts required for a build I end up with two versions of the same library, both as transitive dependencies. I've run a report so I know where the libraries are coming from but I'd prefer not to end up with references to transitive libraries in my ivy.xml file.
The Ivy manual states "If no specific conflict manager is defined, a default conflict manager is used for all modules. The current default conflict manager is the 'latest-revision' conflict manager". Apparently that doesn't apply to transitive dependencies.
Is there a way achieve what I want without directly referencing transitive libraries?
Transitive dependencies are dependencies of your dependencies, so conflicts can occur when one or more versions of the same library are referenced. This is where the conflict manager functionality kicks in. By default, ivy will choose the most recent version, working on the assumption that most libraries are backwardly compatible. If you review the report generated by the report task you'll see the other version(s) marked as "evicted".
Your question appears to put forward an alternative mode of operation? Perhaps an example would help.
I have an installed dependency in my local repository. The remote repository where the dependency came from is now down for some reason. When I try to compile the project Maven says that it can't resolve dependency. But why???
When you have these error, simply clean the _remote.repositories that indicate maven where the dependency comes from. You will find this file for each artifact inside your M2_REPO.
Maven will compare the local POM's timestamp (stored in a repository's maven-metadata file) to the remote. When maven does this depends on the updatePolicy that can be defined in your settings xml.
Either set this to never (discouraged) or skip this check (only when a remote repository appears to be down) by using the -o option (offline); then maven will not check remote repositories.
I don't understand why transitive dependencies of test scope dependencies are included into package (from maven package phase). I'm using maven-war-plugin with default settings.
It doesn't make sense, does it ? The problems arise when you have 10 test scope deps, all with some logging transitive dependencies, and you have to exclude all of them. Not only that one has to do it in compile scope dependencies, but even for test scope deps.
Maven bug MNG-5150 breaks at least jboss-packaging-plugin as described in MJBOSSPACK-40.
I would guess that the same bug also breaks maven-war-plugin.
I changed the version from jFreeChart in the pom.xml of my maven project from 1.0.12 to 1.0.13.
Now I get the error
"The type org.jfree.ui.layer cannot be resolved to a type. It is indirectly referenced from required class files."
What does this mean? I just updated the jfreechart dependency.
The type is in the JCommons library. I think the problem is that the JFreeChart has not been properly distributed to maven in version 1.0.13. In the IBiblio directory listing, you can see that a .pom file is missing (as opposed to version 1.0.12, where it's present).
This means that maven has no ideas what the dependencies are. It still downloads the artifact through it's filename by convention, but it doesn't know anything about the context.
Now you can either complain to the vendor and demand a proper pom or create your own pom file (start with the old version and adjust it until things start working) and deploy it to your company's repository (or your local repository) using install:install-file or deploy:deploy-file.
My guess is that you'll at least have to include the following dependency
<dependency>
<groupId>jfree</groupId>
<artifactId>jcommon</artifactId>
<version>1.0.15</version>
</dependency>
(If you want to do it the easy way, just add the above dependency to your own project pom)