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.
Related
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.
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 .
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 wondering what will happen if I'm using two or more different language packs (different versions) for a plugin. Which one will be used?
Example
Plugin: org.eclipse.core.jobs.nl_ru_3.7.0.v20131123061707.jar
What happens if in about a year I add a new version of this language plugin to my application. (Both are inside the plugin directory) ?
Should I delete the previous version or doesn't it matter at all and if it doesn't matter, why?
Plugins, which contain localization are still old good OSGI plugins and thus same rules are applied (thus, for i18n it is recommended to use fragments).
In each plugin, which depends on your localization plugin you may define range of versions or exact version, which should be used.
In case you have an exact match. Then only plugin, that matches the version will be used.
In case you have a range, then latest version will be used.
In case no version is defined, then latest version will be used.
To sum up: if one plugin needs to use specific localization plugin, you need to set appropriate dependency version.
More on Internationalization.
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.