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).
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
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).
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.
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 have an Eclipse 4 project that is built using Tycho (0.19.0) and Maven (3.0-5)
During development of a version, say 1.0.0, the artifacts are configured with version 1.0.0-SNAPSHOT, and 1.0.0.qualifier depending on the files. When I want to release the version, I use the tycho-versions:set-version goal to change from 1.0.0-SNAPSHOT to 1.0.0.
I then build and copy the product to a remote share that publishes an update site so that older versions can be upgraded automatically at launch time.
Since I have some beta testers, I use more that one update site. One contains the stable versions, and my beta testers have one more update site to check at startup. The other one is actually an update site for snapshots that I have published, so those are not released versions of the product.
What I am experiencing seems strange: When the 1.0.0 application starts, it finds the previous snapshot (versioned 1.0.0.201312191455), thinks that those artifacts are more recent and updates itself back to an older version.
I'm guessing that Eclipse's version conventions state that x.y.z is older than x.y.z.u. Is that correct?
If so, then why does the tycho versions plugin remove the qualifier when a versions changes from snapshot to "release"? Doing so seems to make the artifacts look older than any of the snapshots. What's the correct way to handle this situation?
The answer was given in the tycho mailing list some time ago:
http://dev.eclipse.org/mhonarc/lists/tycho-user/msg01001.html
The details:
OSGi does not have a notion of "snapshot" versions, all versions are
treated the same and 1.0.0.qualifier is indeed considered to be newer
than 1.0.0.
There are two versioning schemes that result is reasonable behaviour
both for OSGi and Maven.
Use the same four part version (eg., 1.0.0.20111112-0735) for both Maven
and OSGi. This results in slightly odd version jump when going from
snapshots to releases on the maven side, i.e. 1.0.0-SNAPSHOT goes to
1.0.0.20111112-0735, but everything works otherwise.
Use even/odd convention to version snapshots and releases, i.e.
1.0.1-SNAPSHOT/1.0.1.qualifier is released as 1.0.2/1.0.2.
I think it is also possible to decouple maven and osgi versions of
released artifacts, i.e. use 1.0.0 for maven and 1.0.0.20111112-0735 for
OSGi, but personally I find this confusing and would not recommend. And
I am not sure if Tycho will allow this in the future.
--
Regards,
Igor