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.
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 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 a GWT webapp split into two Maven projects where one is a dependency to the other. Each time I change something in the dependency and I'm running webapp in hosted mode I have to rebuild the subproject and restart hosted mode for changes to apply. It takes a lot of time so I'd like to ask you if there is any way to make GWT using "live" version of the dependency?
There are 2 cases:
for server-side code, assuming you use the DevMode's embedded server, rebuilding the app and then refreshing the server should be enough
for client-side code, AFAICT, you have to use the source and output directories of the dependency module rather than the JAR containing them (GWT will load the source from the classpath, but apparently it'll only see the modified sources if it comes from a folder rather than a JAR; at least that's what I found in my tests). This goes against The Maven Way™ but the only solution so far is to use a special profile that will import the sources of the dependency project as sources of the project you're running. You can see examples of that in my archetypes.
There's actually a bug opened for the gwt-maven-plugin, MGWT-332, to do that automatically when running a reactor build. I also mused about what's really needed, for the forthcoming official gwt-maven-plugin (rewritten from scratch, independent from the CodeHaus Mojo plugin).
If your dependency does not come from a reactor build, then you're out on your own: you chose to make it totally distinct, so that's how it'll behave: you'll have to release it (even a snapshot) each time you make a change to it, and use the new version in your app (which means re-launching the DevMode).
This can be circumvented by running DevMode on your own, without the help of the gwt-maven-plugin. You're left on your own managing the classpath though (using the Google Plugin for Eclipse, I suppose you could simply edit the launch configuration to add the source folders of your dependency project to the classpath, before the classpath provided by Maven, that would reference the JAR).
Remove the dependent other application jar file from the primary application lib folder under webapp.
Eclipse should then resolve the dependency using the other project in the workspace if you have added it to your primary application classpath.
As GWT build takes ages, we invested some money in a JRebel license. We have two separate Eclipse projects for our back-end and our GWT front-end. JRebel reloads the classes automatically and I never need to restart my local server while writing code. It proved to be a wonderful time saver. Definitely worth the investment.
I'm a bit surprised at the sheer number of articles / blogs / questions / answers about Clojure mentioning Maven.
In about ten years working as a Java dev, working on both desktop apps and webapps, I've never ever used Maven once (typically --and that's a personal opinion but I know some people do think the same-- the projects I've seen using Maven where including the "kitchen sink" whereas the ones built with a more "controlled" build process where way "cleaner" and producing smaller jars, faster build time, etc.).
Is Maven a requirement when you want to build a Clojure app?
Is Maven mandatory when you want to use Leiningen? For example, can I add external jars as dependencies to a leiningen project "manually", without needing Maven?
I think my question boils down to this: can you, in the Clojure/JVM world get away without ever using Maven, just like you can build, test, package and ship both Java desktop, webapps and Android apps without ever needing Maven?
Short answer: No. Clojure's just a jar and you can use it as "raw" as you like, just like any other Java library.
Longer answer: Maven's not a requirement, but the tooling around Clojure, especially Leiningen, is highly Maven-aligned so your life will be easier if you just submit to Maven's will. But, with a little work, it's not that hard to get along without Maven. At work, I use a mix of Leiningen and our existing Ant/Ivy-based build infrastructure. I use Ant to resolve dependencies (from our curated internal repo) and then use a hack of Leiningen's :resource-paths to get it to pick up the non-Maven jars. At some point I'll make a true plugin to do this stuff, but it's been working fine for me so far.
Also, if you're an Eclipse person and use CounterClockwise, you can treat your project like any other Java project in Eclipse, managing the classpath manually. It just happens that you've got some Clojure code in there as well.
Of course, the drawback in either approach is that if you want to grab something that's available from either Maven central or Clojars, you'll either have to set up some kind of mirror for your infrastructure, or manually pull down the transitive dependencies and add them to your project.
You do not have to use maven, or leiningen, for that matter. You can run the clojure REPL with
java -jar clojure-1.3.0.jar
and it will work just fine. I know where you're coming from, because a year ago, I was in the same boat as you. never used maven, seen a couple of less than great projects that used it poorly, and generally distrusted maven. Ant+ivy works great, who needs maven?
As a result of using leiningen, and starting a new job where we have a very well setup maven config, I've changed my tune completely; I now think maven is great, and far prefer it to ant, which I've used for a long time.
Specifically with clojure, some advantages of leiningen are:
automagic project scaffolding: "lein new" sets up a new project for you. convention is important, it helps other developers understand your project and quickly ramp up on it.
dependency and plugin management. adding a dependency is trivial, and there isn't a great way that I am aware of to do non-maven dependency management that is tightly integrated with clojure.
"lein repl" sets up your classpath and everything correctly, so you don't have to fool with it, you can just start and run a REPL.
artifact creation: building a fat jar (lein uberjar) is straightforward, and already set up for you.
So, while it's definitely possible to use clojure without leiningen, I honestly don't see why you would want to. There are too many niceities for day to day development not to use it, in my opinion.
regarding "Is Maven mandatory when you want to use Leiningen?"
leiningen uses and wraps Maven so you can't truly avoid it, though you don't ever need to touch any XML
Maven is not mandatory for Clojure as others have rightly pointed out.
However, I would like to encourage you to embrace Maven (either directly or via leiningen). It has some big advantages in the Clojure world:
You will be more productive in the long run - once you've got it set up, it is pretty impressive to see a complex build, test and deployment execute in a single command. Do you really want to be manually setting classpaths, downloading dependencies, incrementing version numbers, uploading to FTP sites etc.?
One of the biggest advantages of using Clojure on the JVM is access to the Java library ecosystem. Maven is the tool of choice for automatically managing dependencies on Java libraries. Nearly everything you are likely to need will be in either the Maven Central or Clojars repositories.
Clojure tends to have small focused libraries - this is good because they are "simple" and you can pick and choose the functionality you like. At the same time, it also means that you are likely to have numerically more library dependencies. Hence a build management system is going to be more useful.
You can make Maven builds as "lean" as you like. Obviously you can pull in every dependency under the sun if you like, but you can also create very lean jars by excluding the unnecessary cruft. That's your choice.
It is the de-facto standard in the Clojure world. If nothing else, using it means that you will be able to collaborate with others more easily.
P.S. Like you, I didn't really see the point of Maven 5 years ago. Then I gave it a go and saw how powerful it could be for my workflow. Now I'm a convert :-)