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.
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
I have a couple projects that make up a module, and I want to build them automatically. The module consists of a plain JAR API, an EJB, an EAR, a plug-in and a RCP product, so building it with either Maven or Tycho is not possible. I want to evaluate if it is possible using Gradle.
The last couple days I tried to figure out how that is done, and I'm not sure why there is so little support to build RCP applications using Gradle, especially since Gradle has overtaken Maven on the build automation front.
What I tried:
BuildMonkey - gets it's repositories directly (and unmodifiable) from https://ftp.heanet.ie, which is down
Wuff! - doesn't work with the latest Gradle version
GradlePlugins - for Gradle 0.9, last commit was 8 years ago
DiffPlug - example project leads to NoClassDefFoundError
Is there some great tool I'm missing? Something has to work? Especially considering Tycho isn't in use either. Maybe it's really Eclipse RCP that nobody uses anymore?
This question is similar, but old - and I tried the tools in the answers.
I need to convert few projects from ant to maven. I know the basics of both, also read a lot of articles on how to. However, is it a good idea to write a pom using eclipse? Or is it better to write it without using eclipse? The M2Eclipse plugin needs maven to be tweaked more, will the changes related to M2Eclipse cause problems when the war is built on jenkins?
Pros of using Eclipse IDE:
The formatting of pom.xml will be taken care, when you add the 'maven-eclipse-codestyle.xml' to the code formatter, as mentioned here. Formatting will be harder when you do it without an IDE.
The auto-completion feature of eclipse will make your coding easier, since it will automatically sense the open tags and close them. You need to close all the open tags manually, if you don`t use an IDE.
You can view the dependency hierarchy of the dependencies added and hence it might be a bit helpful while managing the dependencies.This can be extremely useful ,when you have transitive dependencies (Dependencies within other dependencies). You can find more about transitive dependencies here.
An IDE will warn you of common mistakes that may occur while coding (something like, 'forgetting to close an open tag','placing a tag in an incorrect location'). This will save a whole lot of time. If you don`t use an IDE, you need to correct the mistakes only when you get an exception after executing a maven command.
Eclipse will warn of missing artifacts (when the dependencies are not present in the local repository), which can help you to fix it before executing the maven goal.
Cons of using Eclipse IDE:
m2e plugin will throw 'Plugin execution not covered by lifecycle configuration' errors all over your pom.xml files. These errors won`t affect your build, but may be quite annoying.
I personally have done migration from Ant to Maven2. IMO it is better to write pom.xml on your own so that you wont face any last minute surprises as well as you will get complete overall knowledge on what you are exactly doing with your pom file.
However if you still want to go with m2e, from my experience it did not create any problems at all. Regarding the build - I guess there shouldn't be any issue. You can refer this link if you need more info about m2e and jekins - m2e and jenkins
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 am trying to write my pom.xml for a multimodal flex application. I have been using this resource as an example:
http://www.sonatype.com/books/mvnref-book/reference/flex-dev-sect-creating-with-archetype.html
I am using M2E v1.01 but I am faced with a number of 'Plugin execution not covered by lifecycle configuration" errors. As far as I can see - there are no m2E connectors available to resolve this and I have tried all the Maven advice I can find - to include:
Clean
Update dependencies
Update project configuration
The problem only occurs if the project is declared as swc or swf package. My next move to ask Eclipse to 'permanently mark goal as ignored' - which seems a little brash.
Any advice would be appreciated.
Thanks in advance.
With STS 2.8.0, we have upgraded m2eclipse to be version 1.0. However, this can cause a bit of trouble with existing projects. I wrote a blog on this a couple of months ago.
http://blog.springsource.org/2011/10/18/upgrading-maven-integration-for-springsource-tool-suite-2-8-0/
Essentially, the new architecture for m2eclipse requires that each maven plugin you use must be mapped to one Eclipse plugin to handle the plugin's execution inside of Eclipse. This obviously causes problems since not every maven plugin author has the knowledge or time to create also create and maintain an Eclipse plugin.
By marking the plugin as ignored, you are saying that the plugin should never be executed inside of Eclipse (implying that whenever you need it to be executed, you will do so from the command line). Once marked as ignored, you can then change it to execute, which means that it should always be executed whenever the associated lifecycle is performed in Eclipse. This may cause performance problems, and so only do it if you know the risks.
If all this is too much for you, then STS provides a downgrade option to revert to an older version of m2eclipse. Go to the Dashboard extensions page. Unfortunately, you will have to manually revert all changes to your .project and .classpath files (we provide an auto-upgrade mechanism, but not a downgrade mechanism...presumably everything is in version control).
Any questions or problems should be sent to the STS forums:
http://forum.springsource.org/forumdisplay.php?32-SpringSource-Tool-Suite
You can check this alpha connector "Flex Maven Integration for Flash Builder" on the eclipse marketplace: http://marketplace.eclipse.org/node/648556.