We Keep Coding

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)

Minimal prerequisite eclipse version for plugin

I developed a plugin using Eclipse Indigo. It depends merely on the usual suspects like org.eclipse.core.runtime etc., there is only a single unusal prerequisiste org.eclipse.imp.runtime.
I am quite sure that the latter should run with 3.5.
Now I have the problem telling potential users what Eclipse version they'd need at least to install it.
Will it even be installable on previous versions when developed with 3.7?
If so, how can I find out what the minimal required versions are (I hope that I do not need to edit version numbers etc. in the plugin.xml?)
If not, does this mean I have to install, say, Eclipse 3.5 somewhere and build it there if I want to support 3.5 and higher?

Can this help you: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Feditors%2Fmanifest_editor%2Fdependencies.htm
It is said, that:
You can also specify the Minimum Version and Maximum Version of the plug-in dependency.

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.

how to compile code from svn into jar file?

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.