Not specifying Gradle minor version - gradle

Using gradle:
Is it possible to set the dependencies such that minor versions are auto upgrading? For instance, I would like gradle to automatically pick the latest guava 11 minor version.
Adding
compile 'com.google.guava:guava:11'
unless of
compile 'com.google.guava:guava:11.0.2'
do not seems to work.

The syntax to use is "11.+" if you want any minor revision above 11.0.0.
If you want for example 11.0.2 but not 11.1.0, you can use "11.0.+".
Using "11+" will probably also find 12.0.0 and above, so would not work as well.
This is mentioned in the Gradle user's guide, where it's referred to as a dynamic version.

Replace it with:
compile 'com.google.guava:guava:11.+

Related

Package android.content.res does not exist

I am trying to build my ionic project, but I get the following errors:
error: package android.content.res does not exist
error: package org.json does not exist
Does anyone know how to solve it? Thanks.
It may be because some of your plugins are still using an old version of cordova/gradle plugins, or you didn’t updated cordova/gradle plugin of your app.
You may try:
Remove these cordova plugins and switch to their corresponding versions of the capacitor version your are using.
Another way, if you prefer you may upgrade/downgrade your Capacitor
version to be compatible with the plugins your are using..

if i have go version 1.7 how do i know which minor i am using?

I have no idea about GO, I have never worked with it. But I have helped a team and they need to update their project.
Recently a bug has been found and they have to update the version of go to 1.17.8 but in the go.mod I see that they use 1.17.
if I put 1.17.8 I get a format error because it must be X.X it can't be X.X.X, how do I know which version of minior I'm using? or how can I be sure I'm using the correct version.
go 1.17.8 //Compile Error -> go version '1.17.8': must match format 1.23 (I NEED THIS ONE)
go 1.17 //Compile OK
[H]ow can I be sure I'm using the correct version.
By installing the correct version. The go directive in go.mod has no influence on your installation.

How can I ensure that newest version of Gradle resolve all dependencies

I need to update Gradle version in kotlin project. Have I any option to check if all dependencies support new version of Gradle or I need to check all dependencies release nots to make sure.
Actually for me it's not pretty clear how dependencies can't support new version of Gradle.
For instance:
Have I any option to check if all dependencies support new version of Gradle
There two sets of dependencies:
Application dependencies -- https://docs.gradle.org/current/userguide/declaring_dependencies.html
Applications dependencies have no correlation with Gradle whatsoever. These are dependencies needed to build your application and has no impact on Gradle's build environment.
Build dependencies
https://docs.gradle.org/current/userguide/tutorial_using_tasks.html#sec:build_script_external_dependencies
https://docs.gradle.org/current/userguide/plugins.html
These dependencies, commonly Gradle plugins, do have an impact of your build. Whether or not a plugin supports a version of Gradle is only known by going to the source and checking release notes, if any. If it is not clear if a plugin supports a particular version of Gradle, then your only option is to upgrade your version of Gradle and see if anything breaks.

Difference between using gradlew and gradle

What is the difference between using gradlew and gradle or are they the same?
The difference lies in the fact that ./gradlew indicates you are using a gradle wrapper. The wrapper is generally part of a project and it facilitates installation of gradle. If you were using gradle without the wrapper you would have to manually install it - for example, on a mac brew install gradle and then invoke gradle using the gradle command. In both cases you are using gradle, but the former is more convenient and ensures version consistency across different machines.
Each Wrapper is tied to a specific version of Gradle, so when you
first run one of the commands above for a given Gradle version, it
will download the corresponding Gradle distribution and use it to
execute the build.
Not only does this mean that you don’t have to manually install Gradle
yourself, but you are also sure to use the version of Gradle that the
build is designed for. This makes your historical builds more reliable
Read more here - https://docs.gradle.org/current/userguide/gradle_wrapper.html
Also, Udacity has a neat, high level video explaining the concept of the gradle wrapper - https://www.youtube.com/watch?v=1aA949H-shk
gradle vs gradlew
gradlew is a wrapper(w - character) that uses gradle.
Under the hood gradlew performs three main things:
Download and install the correct gradle version
Parse the arguments
Call a gradle task
Using Gradle Wrapper we can distribute/share a project to everybody to use the same version and Gradle's functionality(compile, build, install...) even if it has not been installed.
To create a wrapper run:
gradle wrapper
This command generate:
gradle-wrapper.properties will contain the information about the Gradle distribution
*./ Is used on Unix to specify the current directory

Not seeing latest dependency version when I run versions:display-dependency-updates

I am trying to update dependencies in my java mvn project to latest version. When I run below command I see latest versions displayed, but I see different versions in central repository.
mvn versions:display-dependency-updates -DskipTests=true --update-snapshots install
For example, when I ran above command I got this for commons-collections
commons-collections:commons-collections ............ 3.2.1 -> 20040616
But when I browse it in the central repository - commons-collections:MVN Repo,
I see many updates after 20040616
Can someone clarify which is the latest version and MVN command to get the latest?
The display-dependency-updates command assumes that versions are numbered according to a very specific <Major>.<Minor>.<Incremental>-<Qualifier> structure, per the versions-maven-plugin Version Number Rules. It determines "newest" by sorting according to those criteria, and not via some sort of timestamp. When using dependencies that follow different rules, it's not likely to be able to tell you which version is actually newer. Sadly, this makes display-dependency-updates not nearly as useful as one might hope, but I still find it useful as a starting point to check and see what dependencies may need to be updated.
Unfortunately Maven does not know when the dependency was published, it just compares text.
In your case, the latest version of commons-collections:commons-collections is 3.2.1, but if you compare the text, 20040616 is bigger.
So basically 20040616 > 3.2.1 becuase it thinks 20040616 is a major version and it is bigger than 3.
Read more here: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN402
I generally use http://mvnrepository.com to find the latest version of an artifact, while you have used http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22. However, I see similar problems. 20040616 is not the date of the artifact, it is the version of the artifact. Since 20040616 is greater than 1, 2, 3, or 4, version 20040616 will always be viewed as the latest version. It would appear that this artifact should be removed from the repository since it does not obey the numbering rules. I have seen a few other problems like this in the repository, but I'm not sure who to contact to get it corrected.
http://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html
description of display-dependency-updates

Resources