I'm following Building a RESTful Web Service -- and was wondering why the gradle wrapper version was 1.11 instead of 2.3? I tried 2.3 and it worked.
Is there a downside to using 2.3 instead of the suggested 1.11?
Most probably the reason is, that at the time of the creation of the tutorial the stable Gradle version was 1.11, and the tutorial just wasn't updated since then. Usually there is no downside to use a newer version, except if there are some features used, which are now deprecated or removed in a newer version.
Related
I would like to know the difference between RELEASE, SNAPH, and just version number
So, I am working on a project, in which I have to change spring-core dependency version from 5.2.9.RELEASE to 5.3.11
In my maven repository, under org->springframwork->spring-core, I see below
5.2.8.RELEASE
5.2.9.RELEASE
5.3.4
5.3.6
5.3.8
5.3.9
5.3.10
5.3.11
My project builds successfully only with the 5.3.11 version of spring-core. It is ok to release my project to production with non-release version of spring-core?
The Spring Team changed the version scheme of some projects back in April 2020. As documented in this blog from the Spring Team.
So in short the 5.3.x line doesn't have the RELEASE suffix anymore for the final versions, as it was removed.
When upgrading a framework make sure you upgrade all parts of the framework. Not only upgrade spring-core but also all other related Spring Framework modules to the same version, if not this will eventually come back to hunt you with weird issues (memory, performance, transactions, missing methods etc. etc.).
I am new to gradle. But I do understand to some extent why developers are encouraged to use gradlew instead of gradle. However what worse could happen if developers use different versions of gradle to build their project? At the end of the day any gradle version makes sure that dependencies of the project is managed properly. For example if a Spring Boot project is dependent of a starter plugin version 2.x, no matter what version of gradle is used, the build tool makes sure that 2.x is available
As far as I'm aware the main point to use a common version of Gradle is plugin compatibility.
Gradle's internal APIs changed quite a lot in the last few versions, so not every plugin works with every Gradle version.
For example: Spring Boot's 2.3.4 reference explicitly states that it's build plugin requires Gradle 6.3 or later (although 5.6 is mentioned to work in a deprecated form)
https://docs.spring.io/spring-boot/docs/2.3.x/reference/htmlsingle/#getting-started-system-requirements
So while you can be sure that the Spring Boot version is used (because you defined it in your buildfile) any older version of Gradle is likely to run into Exceptions when trying to build your project.
Even if you're just using plugins that are provided by Gradle itself there can be compatibility issues. For example the java configuration block was first introduced in Gradle 5 (I think) and therefore would cause a syntax error in earlier versions.
Or simple things like Java versions that older version of Gradle do not support.
The more plugins you use it becomes increasingly unlikely that a lot of Gradle versions will be able to run it. Using the Gradle Wrapper is therefore a simple way that your build works for everyone.
And from the other perspecitve: if you are the one that usually maintains the build you can use all the latest Gradle features using the Wrapper as you can be sure it will not break anything. Getting everyone on the team to update manually before you can use a feature can be a pain
That beeing said, it's really primarly a maintenance issue. Nothing bad can happen if anyone uses their own installed version of gradle, except it might just not work
If everyone on the team uses a similar version nothing might happen at all
What are the difference between net.wasdev.wlp.maven.plugins and io.openliberty.tools liberty-maven-plugin and which one should I use ?
New, preferred (3.x) version
io.openliberty.tools:liberty-maven-plugin
The io.openliberty.tools one is the newer, better version of the liberty-maven-plugin, and the one you'll likely want to use for new development.
Older (2.x) version
net.wasdev.wlp.maven.plugins:liberty-maven-plugin
The older net.wasdev.wlp.maven.plugins plugin is what evolved into the newer io.openliberty.tools plugin.
Along with the move from version 2.x to version 3.x of the liberty-maven-plugin, the groupId was also changed from net.wasdev.wlp.maven.plugins (versions 1.x-2.x) to io.openliberty.tools (version 3.x and beyond).
Why use the newer plugin?
Both versions of the plugins can be used to work with (install, deploy to, etc.) either Open Liberty or WebSphere Liberty servers. (so that is not a concern in choosing one vs. the other).
The newer V3 plugin provides the helpful new "dev mode" support. Plus you'll find a lot more recent material using this version such as the Open Liberty guides.
It also enhances and streamlines some of the other goals and configuration (besides "dev mode"). There's a summary of the 3.x enhancements here.
So at this point the only reason to use the 2.x plugin from net.wasdev.wlp.maven.plugins would be to continue with a project already using this version of the plugin (unless or until you're ready to migrate).
Currently our project is using Gradle-1.3 version and we have a plan of upgrading it to Gradle-2.6 version inorder to implement artifactory in it.
Need to know if we upgrade gradle from 1.3 to 2.6 will there be impact to current artifact creation and if there any specific exclusion in Gradle-2.6/higher which were actually part of inclusion in Gradle-1.3 version?
There are some breaking changes between 1.3 and 2.6. To get most of them I would advise you to take a look at the according release notes. Basic functionality that has worked with 1.3 most likely is working in 2.6 as the Gradle Team is quite cautious in introducing breaking changes. You should just try building your project with Gradle 2.6 and compare the outputs. Keep in mind that already Gradle 2.10 is released which offers some quite nice performance improvements for incremental builds in comparison to 2.6.
I've searched and couldn't find anything to suggest that Spring 4.0.0 is not fully backward compatible with Spring 3.x.
Is that indeed the case?
You should be safe if you have updated your third-party dependencies and updated any Spring deprecations in your project. Spring Framework project lead Juergen Hoeller writes in the blog Migrating from Spring Framework 3.2 to 4.0.1:
To a large degree, an upgrade from Spring Framework 3.2 (or earlier) to 4.0.1 should be as straightforward as a change of version numbers in your Maven POMs. Note that you may have to upgrade specific third-party dependencies to a recent enough version (e.g. Hibernate 3.6+, Quartz 1.8+, Jackson 1.8+, Tiles 2.2+)
Read the migration guide on GitHub for details.
I've prepared report on API changes for the Spring releases here: http://abi-laboratory.pro/java/tracker/timeline/spring-framework/
The report includes backward binary- (BC) and source-compatibility (SC) analysis results. The BC between 3.2.16 and 4.0.0 is estimated at 90.08% and SC is estimated at 88.70%.
The report is generated by the japi-compliance-checker tool.
...
There are few API they have removed in the new version. You would not have any surprise changes with the new version, there could be slight changes in the API. But, you have to watch the deprecated APIs which will be the candidate for removal in the forthcoming versions.
Look at this document , they have included few backward compatibility changes and removal of the APIs.
The backward compatibility for object-mapper option of the and components has beed removed.
But there is not much changes mentioned in the document.
It should be backward compatible. I recently watched http://oredev.org/2013/wed-fri-conference/spring-4-on-java-8 and recall Juergen Hoeller saying that they designed Spring 4.0 to be easy to upgrade to from 3.2 its around the 47 minute mark in the video.
I take that to mean that there should be no compatibility issues.
Typically any breaking changes or incompatibility would be noted in the documentation. As you can see there is some deprecated code but it looks to be backwards compatible.