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
Related
My project is giving me an "Illegal Reflective" warning, which seems to be a problem before Groovy v3.0. However, Gradle on my machine is running Groovy v2.5.4 and I can't seem to bump this to > 3.0. I've tried having "compile 'org.codehaus.groovy:groovy-all:3.0.2'" in my dependencies but this doesn't do anything.
How can I bump the version of Groovy that Gradle uses?
Gradle has an internal Groovy it uses to run Gradle itself. Declaring a compile dependency on Groovy will not change that. To change the internal Groovy version the only way I know is to go to the lib directory of your installed Gradle and replace the groovy jars in there.
But I advise against doing that. You may see side effects. Groovy 3 contains breaking changes and I do not know if they impact Gradle. Some of them impacted Grails, which is why we already have 3.0.2 despite 3.0 being quite new.
The "Illegal Reflective" warning is just that, a warning. It is only there to try to force library makers to quit doing what they (the makers of the Java API) declared as wrong and warn they will enforce it at some point. But JDK11 is not yet that point.
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 am trying to evaluate Gradle as next-gen build tool for some of my future projects.
Steps I've done so far:
I have Java 7 installed on my machine.
Installed Gradle 2.0
Installed Spring Tool Suite 3.6.1, went to dashboard and added support for
Gradle and installed also Groovy-Eclipse package.
Now when I start Gradle projects from scratch or I clone some of the projects from github,
I am not able to get context sensitive help, like Ctrl + Space to autocomplete stuff in
build.gradle file.
I was reading a lot of documentation on net about this, and couldn't find proper answer, so if someone can give me some idea is it working?
Previously I was using Maven, and m2-eclipse, so when I type in pom.xml I am able to do Ctrl + Space which prevents me to make typo mistakes.
NOTE: Just please note that I've enabled Gradle DSL support for my Gradle projects.
Thank You
Gradle's build language is much more dynamic, extensible, and powerful than a Maven POM, and hence it's much harder to develop full IDE support for it. Recent versions of the Eclipse Gradle Plugin have limited editing support, and work is underway to take it to the next level. IntelliJ 14 is already further along, but expect to see further improvements there as well.
I have been in charge for the past 5 years of the development and the maintenance of a GWT project which consists of 6 different WebApps. The project is using GWT 1.5 and is built with ant (for either mode dev/war). These webapps are deployed on apache-tomcat, the production site run version 5.5 whereas we run (for testing) version 7.0.
To emphasize user experience, I would like to migrate the GWT version to a more recent one (of which I have no idea so far); I have read many things about migrating, regarding deprecated APIs, improvments made frome one version to another and I have still structural questions dealing with the new project layout itself.
Currently, the layout is the following:
WebXXX
-src
-net.yyy.webxxx
-common
-client
-server
-public
-Common.gwt.xml
-module1
-client
-server
-public
-module1.gwt.xml
-[...]
-test
-build
-build.xml
-buildModule1.xml
-[..]
-Dependencies(SVN_Externals)
-www
-compile-all-modules.xml
-compile-module1.xml
-WebXXXHosted.xml
-[..]
To explicit things a bit, the fodler Dependencies is a place-holder for linking Workspace sources with an external widgets library. This library is built at compile time (when building all modules or just one within an ant task) and the resulting jar is injected into the module WEB-INF/lib directory. That widget library does use gxt.1.1.1 and gwt-incubator 1.5.
Over the years, writing a new ant task for each new WebApp seemed to be the solution but now that we are also using maven, I am wondering if I must convert the project to a maven project before doing the migration or if I can skip, for now, the maven conversion.
Since I guess maven is not absolutely required and since the project includes several customized ant tasks to have it run (in dev mode), I am also wondering if I could (instead) migrate the related GWT jars in a version which is such that I won't have to rewrite all the UI though I know I will have major replacement to do and extensive tests to run.
Feel free to enlighten me about the way I could go (maven or not, the version of gwt I should migrate to, the related gxt version (if it's still relevant) to use) because I am in complete darkness !
Thanks for all,
Cheers !
Go one step at a time.
Always use the latest version (and migrate ASAP when a new version comes out). That being said, there've been reports of 2.5 and 2.5.1 having a few regressions in GWT-RPC, so if it doesn't work, try using 2.4 (but try 2.5.1 first!)
You'll have to update your GXT dependency too (I have no idea how they deal with backwards compatibility at Sencha and how much it will break your code –or not–; and again try to stay up-to-date)
gwt-incubator is deprecated for long, so be prepared to replace some of the widgets, and in the long run you'll want to totally remove that dependency.
don't move to Maven until after you upgraded GWT, unless upgrading breaks your Ant tasks too much (then try moving to Maven and then upgrading GWT; but 1.5 is a really old version so I have no idea how well it works with Maven).
Re. Maven, GWT will soon use Maven too and will provide an official plugin. Alpha versions of that plugin can be found at https://github.com/tbroyer/gwt-maven-plugin (I've received rather positive feedback for now); or you can use the gwt-maven-plugin from CodeHaus, or simply call the GWT Compiler with the exec-maven-plugin (or the antrun-maven-plugin). As for the project layout, see http://blog.ltgt.net/announcing-gwt-maven-archetypes-project, this is the layout the official GWT plugin will be based on (and again, mostly positive feedback so far).
If you are planning to do both migrate to gwt and maven, I would face first to migrate the existing project to maven. You have to be sure that all dependencies are in maven repositories or you know how to deal with local repositories. Once you have everything mavenized in modules and you can import the projects in eclipse (maybe you need an old gwt plugin) and run all tasks I would try to migrate module by module selecting the appropriate dependencies.
I think updating dependencies with maven is pretty easier than dealing with ant, but of course you could select the other way if you feel more conifrtable.
Anyway, the task of migrating a gwt application from 1.5 to 2.5.1 could be hard. First you have to know how the evolution of gwt to know which issues could come to your app (new widgets interfaces, handlers, etc).
You are depending on gwt-incubator which has been discontinued since some years ago, maybe you have a build which could work with gwt-2.5.1, but probably there are many things which dont work any more. There are some features which have been moved from incubator to gwt like cell-lists, date-picker, etc, so you have to rewrite your code using new stuff in gwt.
Your project depends on an old gxt version, they have made many changes in theirs api, and I think you have to deal with a lot of changes in your code as well.
In summary, mavenizing an ant project is not so difficult and you have plenty of information in the web, but porting a gwt app from 1.5 to 2.5.1 is not a trivial task, if you dont have a good suite of tests it could be harder, so be prepared to spend a lot of time figuring out how to replace old things and to fix issues.
I have a project that uses some Java and some Groovy, and it's all built with Maven. We use the GMaven plugin to compile the Groovy. I've been using Eclipse and have got fed up with the "Plugin execution not covered by lifecycle" message that indicates Eclipse is incapable of doing what my command-line does (I've tried adding the ignore/execute config to fix it, but it never works properly), so I've switched to Spring Tool Suite, which claims to have full Groovy support. How should I set it all up? So far I've had exactly the same experience as with regular Eclipse, but given that SpringSource are responsible for Groovy, I figure there must be a way of doing it.
Have you read this thread?
http://forum.springsource.org/showthread.php?130130-Working-with-Mavenized-Grails-projects-in-GGTS-3-1-0-Updated-for-3-1-0-release/page2
For grails projects, you do not need to use gmaven or the groovy-eclipse-compiler. You must be using the 3.1.0 STS (which is not actually released yet, but you can get this
You also must be using Grails 2.1.1.
You can secretly get a 3.1.0 release build by going to this download page:
http://www.springsource.org/downloads/sts-ggts
Instead of clicking on the links, copy them and substitute 3.1.0 for 3.0.0.