I've created a one-off of a public domain library to use for testing. I built it and copied it to a server so the rest of my group can use it also. Unfortunately when I run ./gradlew build it's picking up the original version.
I set the compile line in build.gradle to have '+' for the version
How does gradle decide which version to include and how would I force it to use my updated copy?
Assuming the original version is 2.0, and your version is 2.1, and the dependency spec refers to "2.0.+" (or some variation of that), it's going to take the FIRST artifact that matches that version expression. You may think it means to find the "largest", or somehow to know that it should get your version, but that's not what's happening here.
In short, set the dependency to a specific version.
If you have non-standard repositories, read the "Repositories" section of the Gradle User Guide for information on how to configure that: https://docs.gradle.org/current/userguide/dependency_management.html#sec:repositories .
Related
It is mentioned here that
If you do not follow Maven versioning standards in your project versioning scheme, then for version comparison, Maven interprets the entire version as a simple string
From the example, we can see that 1.0.9.3 should be treated the more updated than 1.0.10.1
1.0.1.0
1.0.10.1
1.0.10.2
1.0.9.3 < most updated version
There is a project I am currently working on. It has a dependency on a package com.example.http, which is versioned 1.0.12.2. There are several updates on it now. A subset of the versions are (1.0.0, 1.0.9, 1.0.12.2, 1.0.16). Since it does not follow Maven versioning standards, I would expect the order of these versions to be:
1.0.0
1.0.12.2
1.0.16
1.0.9
Q1:
However, when I run mvn versions:display-dependency-updates, it said that 1.0.16 was the most updated version. Why?
Q2:
Should I do something to removed the non-standard 1.0.12.2? notes: all, but 1.0.12.x, follows the maven versioning standard
[INFO] com.example:http ............................ 1.0.12.2 -> 1.0.16
The mechanism changed about 10 years ago, so your information is outdated. Maven is able to sort arbitrarily long version numbers, see e.g. https://blog.soebes.de/blog/2017/02/04/apache-maven-how-version-comparison-works/
More information can also be found in the answer https://stackoverflow.com/a/31482463/927493
I'm maintaining a parent pom for my team which will provide the latest compatible version of various maven plugins per the JDK that the project uses. Sometimes if a project utilizes an older version of Java (like 1.5) maven will fail due to a plugin requiring a newer version. Is there a way to get a map of a given plugin and see what the minimum java version is for said plugin? I was thinking there was some sort of report or something that would show me that, but I'm not seeing anything.
What about: https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html Apart from that on every plugin page you can find the goals page which contains the information you need. One more thing if you are using not the most uptodate versions all older versions pages are available where you can look at which version which JDK versions uses. It shouldn't be problem to write some kind of script to programmatically extract the information of the older plugins. The above site contains the informations of the uptodate plugins.
Apart from that plugin version selection basead on JDK version is not a good idea. The plugins have only a minimum version for JDK they need to run with. Apart from that they run on all versions (already on JDK 9 with one exception)...Furthermore plugins might require a minimum Maven version to run with which is either Maven 2.2.1 or Maven 3.0+ which shouldn't a problem.
You should define your plugins versions simply based on problems you might have but i would recommend to keep uptodate with your plugins.
If you need running you build with JDK 6 for example, but you use Maven 3.3.X which needs JDK 7 to run you can achieve this by using toolchain to handle this situation.
In theory this shouldn't be an issue. Maven will use the Java version you run it with, so the plugin's dependency will be satisfied, independent of the project's language level. Just make sure your devs are using a current version.
Example: running Maven with Java 8 will satisfy the dependency of a Plugin that requires Java 8, independent of the project's source and target level.
(With dependencies it's more complicated, I am afraid, but since you are not actually coding against your plugins, you should be fine)
I'm writing testing library with my own junit runner. it extends BlockJUnit4ClassRunner which is available since 4.5 till... who knows. user of my library should be able to choose whatever junit version (with BlockJUnit4ClassRunner of course). and i don't know how to define dependency on junit (let's say current version is 4.10).
if i make [4.5, 4.10] provided, then i have to release new version with every junit release
i'm not sure if [4.5, ) is good a good practise because it implicitly chooses the newest version and build may not be repeatable
e.g. mockito uses ant and junit 4.10 only for compilation and have no maven dependency on it. i also don't know if it's a good practice.
how should i solve this dependency problem
In general, JUnit releases are backward compatible[*]. The developers take great care so that they are backward compatible. One option would be to declare a dependency on JUnit 4.5, and then the user can override that version in their pom (with version 4.10), and it should still work.
If you're doing the above and claiming that it works with all versions after 4.5, then you should be testing with all versions as well, which should be reasonably easy to do.
[*] Classes and methods are deprecated of course, but things should still work.
In case you always want to stick to the latest version of junit then use
<version>LATEST</version>
The above will always refer to the latest released or snapshot version of junit.
If you use
<version>RELEASE</version>
then it'll refer to the last released/non-snapshot version present in the repository.
Also there is no issue in declaring an open-ended version range which will include the latest version after x.y.z, i.e.
<version>[x.y.z,)</version>
But things turn sour when there may happen API level changes in the junit world that are incompatible with your artifact. In that sense, it's better to provide an exact version and mandate the client to follow the same.
The problem with the version markers LATEST and RELEASE they are only supported by Maven 2.2.1 and before but no longer for Maven 3. So the thing is to avoid them.
Furthermore if you define your dependency to JUnit as provided users can use a different version instead of the defined version.
Maven has a version management system that picks the highest version of a library if multiple versions are referenced. For example if a pom A refers to a version 1.1 and and pom B to 1.2, then a pom C (referring to both A and B) will use the highest version; 1.2.
This approach assumes that 1.2 is 100% backwards compatible with 1.1 and this is a good and required approach. However, at certain times in the lifecycle of libraries it is wise to clean up shop. For me any major changes in the API means increasing the major version, so a 2.0 does not need to be 100% backwards compatible to the latest 1.x. Fine.
Maven, however, does not really care and if pom B would be upgraded from 1.2 to 2.0, Maven would then use 2.0, but pom A cannot work with that version.
How to tell Maven that a version is no longer backwards compatible?
I've tried specifying excluding ranges, so A refers [1.1,1.999) and B refers [2.0,2.999). However, Maven still solves the maximum version number (2.0).
First it's a bad practice to use version ranges in Maven Builds furthermore you have to define a version numbering definition which says 1.0 and 1.1 must be backwards compatible whereas 2.0 is not but that's a definition you have to make. Maven does not know about that. I would recommend to use Major.Minor.Increment-Qualifier etc. In my opinion you should pin your versions fix otherwise you are not able to reproduce your builds.
I would change the artifact ID (probably by adding the major version number). This would make the 1.x and 2.x versions different beasts to Maven.
Have you looked into the maven enforcer plugin? it may have something like this, or you may be able to write a custom rule.
I found HTMLUnit is useful for me,but the files are too old.
So I use svn co https://htmlunit.svn.sourceforge.net/svnroot/htmlunit htmlunit to check the code,But I don't know how to use them.
Is there somebody can tell me how to compile them?
I see you have very little knowledge of Subversion.
I could link you to lots of verbose documentation, but let's make it quick and easy: what you downloaded is the whole repository, containing lots of redundant code, majorly the three canonical directories branches tags trunk.
In order to obtain usable code, you either download a stable (tag) version or unstable version (trunk). Advantage of trunk over tag is that it mostly contains new features, but tags are generally stable.
Try to get the following URL: https://htmlunit.svn.sourceforge.net/svnroot/htmlunit/tags/HtmlUnit-2.8/, then you could try ant to build (I'm no Java expert, does the package have an ant script?)
You don't need to take the detour of building it from sources yourself. The latest version is 2.8, and it's readily available from the Maven central repository. If you're not using a dependency manager, just grab the jar from here:
http://repo2.maven.org/maven2/net/sourceforge/htmlunit/htmlunit/2.8/
Check out the projects instructions on how to get and build the latest version !
http://htmlunit.sourceforge.net/gettingLatestCode.html.
It seems it ships as a collection of submodules, each with its own build system (some of them maven, some ant).
The latest release dates back to August 2010, doesn't seem to be that old, but if you're aware of improvements you need which are available only in later versions I suggest you look at their CI server, which provides already the artifacts from the latest build.