Maven by default uses these versions of plugins such as clean, compile, jar etc. if I don't override them in my pom.xml.
Should I be using more recent version of these plugins? For example, the current version of maven-compiler-plugin is 3.6.1 while the default is 2.5.1. Or, are the default versions reasonable enough that anyone not consciously depending on newer features need worry?
The maven way is "convention over configuration", so if you're wondering about not using the default parameters when running a maven build, you should have a specific use case that is not covered by the default version.
Here for example, (according to here) the install plugin is still at version 2.5.2, so that would point to me that using 2.5.1 is not such a bad choice by default.
I think the biggest difference comparing version (I might be wrong) is the upgrading of compatible version as for example this pseudo release note of the maven compiler.
Related
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).
My builds broke when I moved to Gradle 5 becasue Gradle v5.2 bundles with Groovy v2.5.4. These projects use the dynamic support build for Groovy.
Invoke dynamic support
groovy-all-2.5.4-indy.jar
This file is not being resolved for either JCenter or MavenCentral. However I did find a copy here:
Sonatyoe repo: https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.5.4/
groovy-2.5.4-indy.jar
but no groovy-all-2.5.4-indy.jar
I am not sure what can be done for Gradle to 'resolve' this file and actually find it.
Can someone tell me were I should be getting this JAR file from?
I'm using coordinates: "org.codehaus.groovy:groovy-all:2.5.4:indy"
Is that still the correct expression?
Is this a bug or am I just looking in the wrong places (see #1)?
Im ny build.gradle I was using jcenter() and tried changing that to mavenCentral().
Neither option came up with the JAR in question.
A final wrinkle is that we run an instance of Nexus. Is there some way to force Nexus to go outside and look-for this JAR?
This is not entirely conclusive, but it seems that the -indy jar was there in groovy versions prior to 2.5.0 because those versions supported java versions prior to 1.7.
The indy jar was there so that you could optionally enable support for the invokedynamic instruction introduced in java 1.7 while still supporting java versions prior to 1.7 which did not include invokedynamic (groovy docs for indy).
It seems that groovy 2.5 bumped the minimum jdk requirement to, quote:
JDK requirements changes
Groovy 2.5 requires JDK8+ to build and JDK7 is the minimum version of the JRE that we support.
(from http://groovy-lang.org/releasenotes/groovy-2.5.html)
which would make this whole duality of supporting both invokedynamic and without unnecessary.
So my guess would be that they just dumped the indy jar and always include the invokedynamic instruction in the normal groovy jar file set as the required jdk versions will always include it.
The versions of Maven plugins specified in default-bindings.xml is not latest.
For example, maven-resources-plugin is 2.6, but latest is 3.1.0,
maven-jar-plugin is 2.4, but latest is 3.1.0.
https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml
I think it's not necessary to update default-bindings.xml at every minor version update of plugins.
However, the above is major update.
I know I can change the versions myself if I want.
My Question is why default versions that affect most of the maven users are clearly old.
The thing is you should always pin all your plugin (and I mean all plugins) inside your build which means define the version of all plugins via <pluginManagement>..</pluginManagmenet> this is best practice and you should never rely on those in Maven Core.
Furthermore there is work done in the background to decouple the artifact handlers (plugin binding) from Maven Core and move it to the plugins1, 2 and 3 and so on (which is done in very small steps and will take a long time).
The -SNAPSHOT version qualifier is well explained in Oracle's "Understanding Maven Version Numbers".
But now I hear there is a RELEASE and LATEST version "numbers" as well. And at the same news item, that they are deprecated in Maven 3.
What are these RELEASE and LATEST version numbers/notations? Where can I learn more about them?
Copying answer from link provided by - glytching
Internally, Maven 2.x used the special version markers RELEASE and
LATEST to support automatic plugin version resolution. These
metaversions were also recognized in the element for a
declaration. For the sake of reproducible builds, Maven 3.x
no longer supports usage of these metaversions in the POM. As a
result, users will need to replace occurrences of these metaversions
with a concrete version.