I'm trying to add "com.google.api-ads" % "adwords-axis" % "1.23.0" as a dependency in build.sbt file in a Play 2.2.1 project. When I do play eclipse for generating the eclipse project file, I get the following error:
[error] (*:update) sbt.ResolveException: unresolved dependency: com.google.http-client#google-http-client-jackson2;RELEASE: not found
Later I found out that adwords-axis depends on ads-lib which has the following dependency (note RELEASE version):
<dependency>
<groupId>com.google.http-client</groupId>
<artifactId>google-http-client-jackson2</artifactId>
<version>RELEASE</version>
</dependency>
I read that the version can be specified as RELEASE in Maven in this answer.
Does SBT not allow specifying the version as RELEASE? If so, is there a workaround to use adwords-axis dependency?
I don't think there is such functionality in SBT and it is probably also not a good idea since the API might change totally between two releases and your project would then download any new version making your build non-repeatable, if you check out an old version from your VCS its not certain that it will compile etc. So it is a pretty bad decision by the project maintainers of the library that uses RELEASE as the version of any dependency.
What you can do though is to figure out what version it would resolve to now, if it really works and then override the transitive dependency with that specific version of google-http-client-jackson2 and depend directly on that.
So for example (not that I'm just randomly guessing that 0.17.0-rc would be a good version):
libraryDependencies := Seq(
"com.google.api-ads" % "adwords-axis" % "1.23.0",
"com.google.http-client" % "google-http-client-jackson2" % "1.17.0-rc"
)
Related
So I have a library which I want to use, and I have it inside of a folder called "lib",
I'm working in maven so I put this in my pom.xml
<dependency>
<groupId>org.worldborder</groupId>
<artifactId>worldborder</artifactId>
<scope>system</scope>
<version>1.0</version>
<systemPath>${basedir}/src/lib/WorldBorder.jar</systemPath>
</dependency>
Doing this allows me to write code which uses said library, but when I build the jar it gives me a no class def found error when using, when I use mvn clean install, I do get a warning when I build,
Some problems were encountered while building the effective model for me.acidviper:ViperUHC:jar:1.0-SNAPSHOT
'dependencies.dependency.systemPath' for org.worldborder:worldborder:jar should not point at files within the project directory, ${basedir}/src/lib/WorldBorder.jar will be unresolvable by dependent projects # line 85, column 25
It is highly recommended to fix these problems because they threaten the stability of your build.
For this reason, future Maven versions might no longer support building such malformed projects.
I'm a complete noob when it comes to maven, so I don't understand how to fix this error. Any help is appreciated. Thanks!
Hi I faced the same issue. To solve that I installed that jar directly into my local .m2 repository.
mvn install:install-file
-Dfile=/path/to/jar
-DgroupId=org.worldborder
-DartifactId=worldborder
-Dversion=1.0.0
-Dpackaging=jar
then if you are using spring boot you can use plugin like spring-boot-maven-plugin. It creates a complete jar for your application with all of it's dependencies
I'm using the maven dependency:tree command to see all my modules and submodules.
We're using a dev=RELEASE version model so that we can see our dependencies fail fast. Then we lock in a version when we go to prod.
Our dependency tree goes about four levels deep of modules.
I want a quick way to identify if anything in my pom dependencies contains a RELEASE version.
I'd like to be able to use the dependency:tree command to do this - but unfortunately it resolves all the RELEASE versions to the last 'dot' version.
Note this is using Maven 2.
My question is: How do I get the maven dependency:tree command to show when I'm using a RELEASE version?
The trick is - as the comments have pointed out - is to upgrade to Maven 3 - and then use the Maven Versions Plugin :
This means you have to set the versions explicitly - but you still get the fail-fast behaviour.
See here for more detail:
https://stackoverflow.com/a/48184999/15441
I recognized that Maven not always uses the latest version of a plugin.
For example org.codehaus.mojo:sonar-maven-plugin version 2.7 has beed released on 19th of October but on 23th of October, 2.6 was still used by Maven (mvn sonar:sonar).
I even remember some plugins, where the latest version was several minor releases above the version that Maven decided to use.
Is there any (central) index/list/database where Maven looks up what version to use? If yes, where can it be accessed manually?
I know this is an ancient thread but in the interest of posterity and accuracy: all pom.xmls logically inherit from the super POM. You can always see what your "real" pom.xml looks like by typing:
mvn help:effective-pom
The resulting pom.xml that is printed is a combination of the super POM, your pom.xml, and of course any parent POMs in the mix as well.
The super POM is provided by the org.apache.maven.model.superpom.DefaultSuperPomProvider class (https://github.com/apache/maven/blob/bce33aa2662a51d18cb00347cf2fb174dc195fb1/maven-model-builder/src/main/java/org/apache/maven/model/superpom/DefaultSuperPomProvider.java#L56-L85). The resource it loads is org/apache/maven/model/pom-4.0.0.xml (https://github.com/apache/maven/blob/bce33aa2662a51d18cb00347cf2fb174dc195fb1/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L23-L149).
As far as i know, this link will answer your question.
Automatic Plugin Version Resolution
When a plugin was invoked without an explicit version given in the POM
or on the command line, Maven 2.x used to pick the latest version
available where the latest version could either be a release or a
snapshot. For the sake of stability, Maven 3.x prefers the latest
release version over the latest snapshot version.
Given the threat of non-reproducible builds imposed by automatic
plugin version resolution, this feature is scheduled for removal as
far as plugin declarations in the POM are concerned. Users of Maven
3.x will find it output a warning when missing plugin versions are detected to encourage the addition of plugin versions to the POM or
one of its parent POMs. The Enforcer rule requirePluginVersions can be
used additionally check for missing plugin versions in the POM
For command line execution if a version is not specified Maven looks up the latest version from the GA (group ID/artifact ID) maven-metadata.xml file.
Example: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml
If you're encoding command line execution of Maven goals into your builds you should specify a version for these, otherwise your builds may change as new versions of plugins are released.
I am encountering a problem with the maven-enforcer-plugin. It is complaining with the following (simplified) output:
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
Failed while enforcing releasability the error(s) are [
Dependency convergence error for com.company.project:interfaces:1.0.4 paths to dependency are:
+-com.company.project:product:1.0.14-SNAPSHOT
+-com.company.project:some_part_A:1.0.0
+-com.company.project:interfaces:1.0.4
and
+-com.company.project:product:1.0.14-SNAPSHOT
+-com.company.project:some_part_B:1.0.0
+-com.company.project:some_sub_part_BB:1.1.0
+-com.company.project:interfaces:1.0.4
and
+-com.company.project:product:1.0.14-SNAPSHOT
+-com.company.project:interfaces:1.0.6
The problem is with some_sub_part_BB:1.1.0. According to the plugin, this part has a dependency on version 1.0.4 of the interfaces. But this is not possible: version 1.0.0 of some_sub_part_BB used interfaces version 1.0.3, and version 1.1.0 of some_sub_part_BB went directly to using interfaces version 1.0.6. I do not have any artifacts of some_sub_part_BB that uses version 1.0.4.
I guess I'm looking at some bug of the plugin, but I would like to debug this issue to make sure what is going wrong. Is this an issue anyone has encountered before, or can someone provide me any pointers on how to debug this problem? (I am fairly new to Maven, and aside from checking all the pom.xml files I have no idea where to look further).
Side note: The idea is (was) that the interface version to be used is specified on the project level POM, so that all (sub-) parts agree on which interface to use. However, as you can see, the different parts also specify which interface they use, which I don't think is the correct way of doing this. I haven't figured out how to fix this (yet).
Turns out that this is not a bug: in the pom.xml file, you can overrule versions of artifacts in the section dependencyManagement. In my case, someone enforced version 1.0.4 of the interfaces. The enforcer plugin does not show this; it only became apparent to me after generating the dependency tree with the verbose flag, i.e. mvn dependency:tree -Dverbose.
Well, the problem is that I want maven to check dependency version on build and warn me if there are any newer dependency versions (in fact - notify me if I use an outdated version of some module). My maven module A has the following dependency:
<dependency>
<groupId>com.example.mycompany</groupId>
<artifactId>commons</artifactId>
<version>1.0.3</version>
</dependency>
And com.example.mycompany:commons module in fact can already have 1.0.4 version. Is there any way to check version of the dependency in repo and fail the build if newer version is already available.
I hope that versions-maven-plugin can make it. But I can not find appropriate configuration.
If you are using source control and a continuous integration server (which is a safe assumption) you can:
use the versions plugin and let it modify the pom
then use the scm:check-local-modification or the release plugin as the release plugin IIRC checks for local modifications.
Here is an example checking for the latest parent pom:
mvn versions:update-parent scm:check-local-modification -DallowSnapshots=false -DgenerateBackupPoms=false
This problem can be solved with the maven-enforcer-plugin. You have to create your own custom rule, because non of the standard rules seem to match your needs.
The notion of the rule you are going to implement should be enforce dependencies are up to date. To implement the check you could get some inspiration by the versions-maven-plugin you mention.