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.
Related
I am trying to understand about gradle-wrapper.jar in git version control. I found the purpose of it on this question Purpose of gradle wrapper.jar in my libraries.
As binary files are not good to store in git if they are changing a lot, I assume gradle-wrapper.jar does not change very often, is this correct?
This also lead me to the question when does it change and why, is it when we update gradle version?
Short answer: You never need to upgrade the Gradle wrapper, unless you need a specific bugfix or feature of the wrapper itself (which is fairly rare).
Longer answer: The Gradle wrapper is extremely stable, in a sense.
That doesn't mean that no new versions are released. In fact the Gradle wrapper is released with each Gradle release.
But an ancient Gradle wrapper is usually not a problem, which is even explicitly mentioned in the docs:
Note that running the wrapper task once will update gradle-wrapper.properties only, but leave the wrapper itself in gradle-wrapper.jar untouched. This is usually fine as new versions of Gradle can be run even with ancient wrapper files. If you nevertheless want all the wrapper files to be completely up-to-date, you’ll need to run the wrapper task a second time.
What this means is that the Gradle wrapper is almost universally forward and backwards compatible (you can download a newer or older Gradle version with a given wrapper).
The only times you must upgrade the wrapper is if there is a bugfix or a feature in the wrapper that you absolutely must have.
For example the Gradle 6.0 release had 2 changes to the Gradle wrapper:
Wrapper reports download progress as percentage
Wrapper tries to recover from an invalid Gradle installation
So if you really want that progress update or you frequently suffer from invalid Gradle installations then you might want to upgrade your Gradle Wrapper past that version.
But very often projects can go many, many Gradle upgrade cycles without ever touching the gradle-wrapper.jar.
And that is, of course, by design. The Gradle designers know that storing frequently-changing binary files in a VCS (especially git) is not a good idea, so they have designed the wrapper to be as stable as possible by making it basically just a simple downloader/launcher for the real Gradle code.
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)
We're upgrading the jetty version from 8.x to 9.x in our project.
It was org.eclipse.jetty.aggregate:jetty-all-server:8.1.7.v20120910
But for 9.x, I can't find jetty-all-server anymore, instead, I found org.eclipse.jetty.aggregate:jetty-all:9.2.7.v20150116, notice the package name has changed to jetty-all
So I wonder is jetty-all-server stopped at 8.x and it changes the name to jetty-all at 9.x? Or there will be new jetty-all-server at 9.x in the future?
There is no such thing as jetty-all-server for Jetty 9.
Seeing as there are so many components of Jetty that are, in fact, conflicting with each other, the whole aggregate concept is really not viable any more. The introduction of npn/alpn for the spdy/http2 support also makes the aggregate impossible due to bootclasspath requirements.
The choices for the jetty group with aggregates are to either make every permutation of aggregates (currently standing at over 400 different combinations) or none.
We left jetty-all as a helpful one for use in the jetty-documentation for the getting started / introduction to Jetty phases, but it is absolutely inappropriate for production use.
Use a build tool (maven, gradle, ivy, buildr, grape, sbt, leinengen, eclipse, intellij, netbeans, make, shell script, etc..) and add the components from standard jetty to your project. You can even make an aggregate of your own.
I have recently started using maven to build my Java application. As Maven downloads the dependent jar(s), is there a chance that the functionality can break when my (unmodified) code is built with a newer version of the jar which maven automatically downloads?
If it can, what is the workaround?
Yes, this can and will happen. Obviously you want to avoid 'code rot' where your code isn't updated to improved, newer, and supported APIs, however sometimes dependencies change their interfaces at inopportune times.
There are several plugins which provide more nuanced control over specific versions you depend upon. I would recommend you minimize your dependency on pinned versions so you regularly benefit from bug fixes and updates to your dependencies.
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.