We Keep Coding

Track other versions change with Jenkins

I have a few components and some projects using them. All the dependency management is done using maven. I'd like jenkins to check if code changes for a component would impact a project even if the project isn't using the newest version of it.
Let's say I have component foo, and projects bar and baz.
project_bar uses component_foo version 1.0.0
project_baz uses component_foo version 1.1.0-SNAPSHOT
While I'm changing component_foo version 2.0.0-SNAPSHOT so it can be used by project_baz I'd like to know if it could break project_bar build.
Being able to ignore a major version change (don't check compatibility if component_foo new version was 2.0.0-SNAPSHOT) would be a bonus but not required.

There is on magical way in Jenkins to do that.
This is something handled by compiling the projects with the new dependecy version. To ensure functionality is not broken you need to have unit tests and preferably possibly system tests for you projects.

gradle - how does it decide which jar version to use?

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 .

Is there a way to get a map of maven plugin version and their required java version?

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)

library dependencies in maven. best practices

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; how to break backwards compatibility?

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.