GWT and AppEngine Convention, without IDE Configuration
A Maven seed project for GWT, Google App Engine and JDO
This project offers a conventional seed project for a full-stack application that is pre-configured and ready-to-go. The goal is to offer a simple, working example of a CRUD application, using an entity relationship framework, enterprise-level validation, which sits atop a cloud-based, schemaless, high-replication datastore that has zero dependency on an IDE. How is this done? The entire dependency management and build lifecycle configuration is done solely through Maven.
This project currently supports the following:
- Google Web Toolkit 2.7.0
- Google App Engine 1.9.18 through a schemaless high-replication datastore (HRD)
- DataNucleus JDO 3.0
- JUnit 4.12
- Google Chrome. Due to the limitations for symbol-map support in IE and Firefox, you need to test with Google Chrome to see error log messages logged by the UI.
This project is licensed under Apache License 2.0
A few years ago, I was working for a company who let developers use their preferred IDE, using a BYOD approach to the authoring environment. I thought that was very cool, and I also believe it’s an approach likely to gain favor as more companies move to a Docker containers for development.
Some developers kept their own lifecycle mappings for Eclipse, some developers worked purely from the command line, and others benefitted from how IntelliJ introspected parent POMs to understand dependencies. Some developers kept their own m2e configurations.
At the time, I didn’t have any experience with Maven. Lots of developers lack Maven experience, and there’s a steep learning curve with Maven, especially if you need to create an environment-specific configuration, such as working in Eclipse with m2e.
I prefer IntelliJ it for development, but my preferences shouldn’t dictate the team’s preferences. Lots of people prefer Eclipse or Netbeans. For my most recent application, I had a hard time finding a starting point for my GWT/GAE/JDO project that didn’t include IDE specific configuration, and I had a harder time finding documentation and examples which didn’t omit the intricacies between the different SDKs and frameworks.
So, when my company decided to move from Eclipse to IntelliJ, we came across a few issues with our migration. First, it became difficult to share a project between Eclipse and IntelliJ. We had been using Maven for dependency management, but not lifecycle management.