Comments (17)
I've uploaded that archetype. But @tbroyer stuff is awesome, I like his maven plugin better. I haven't converted all my stuff over yet.
from gwt-maven-plugin.
We should probably take this chat to another location since it's running off track. But I'll share it quickly here. I haven't upgraded this app in a while so there is a possibility it needs some tuning.
https://gist.github.com/branflake2267/cd2d25d7bd723a716fcfbcad52c97a14
from gwt-maven-plugin.
By the way, I've gotten a step closer to a better moduleName m2e configurator so it can be renamed in Eclipse.
from gwt-maven-plugin.
Once I get through my archetype updates, testing your plugin in various configs, I'll loop back to update more docs.
from gwt-maven-plugin.
Adding the pom.xml for reference. https://github.com/branflake2267/Archetypes/blob/master/archetypes/gwt-basic-rpc-appengine/pom.xml
from gwt-maven-plugin.
@branflake2267 I tried to build a project from the gwt-basic-rpc-appengine archetype 2.0-SNAPSHOT but it seems it isn't deployed to sonatype... https://oss.sonatype.org/content/repositories/snapshots/com/github/branflake2267/archetypes/gwt-basic-rpc-appengine-archetype/ only shows the 1.0-SNAPSHOT.
I'm trying to modify @tbroyer 's modular-webapp
archetype to use app engine so it would be great if I had the 2.0 version of yours which shows how to launch app engine instead of just plain jetty. I'm trying atm but struggling to work out what goes where.
from gwt-maven-plugin.
@slugmandrew AFAICT, it should be as easy as running cd *-server && mvn appengine:devserver -Denv=dev
instead of cd *-server && mvn jetty:run -Denv=dev
, and changing the launcherDir
in the root POM to point to the *-server/target/*-server-${project.version}
. The problem with this approach is that the SDM .nocache.js
stub is generated in *-server/target/*-server-*
, i.e. in the prod target dir, possibly overwriting your prod compilation when assembling the final WAR. Ideally, you'd want to build to a different target dir when using -Denv=dev
but that might make your build complex and brittle; so, well, just remember to mvn clean
before you package your app for production. You can also have a look at the MobileWebApp sample in the GWT SDK (or the GWT source repository)
BTW, closing this issue now that the GWT samples use this plugin; plus, I really don't think you should work that way and should rather split your project into modules, like in my archetypes.
from gwt-maven-plugin.
FYI, I've changed how I use app engine. That means I'm using the old app engine maven plugin in that archetype. Google has built a newer maven plugin that works much better, but the only way to use it's configuration is to use a server runtime in eclipse to debug it. http://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/servers/AppEngine.html - And oh, I see what you mean, the 2.0 is missing and 1.0 has the old config.
from gwt-maven-plugin.
@tbroyer I don't think I made that clear enough - I have used your multi-module archetype because I want to have my project split up into modules, based on your advice! And I want to use your plugin instead of the Mojo one. The 2.0 archetype I wanted Brandon to upload uses your plugin instead of the Mojo one, I just want to know how to run App Engine on that instead of Jetty and have SDM link into the page refresh. I've got it working using the bookmarklet in this test project but I'm just hacking my way around really.
@branflake2267 Thanks for that. It's very confusing when you don't know maven well and switching from a single module to multiple ones is a lot to get your head round. I have been using the new appengine plugin for a while but only for deployment (appengine:update
). I was still launching it using the <server>com.google.appengine.tools.development.gwt.AppEngineLauncher</server>
of the Mojo plugin and thought there might be an equivalent command for Thomas's one.
And yes, Thomas is awesome, as are yourself. You've both helped me many times and I'm really grateful for what you give to the GWT community.
FWIW, this all started as I had help from someone (Chris at Arcbees if you know him) converting my single module app into a multi-module one, but the layout is different from what I'd expected:
- root [parent]
- client
- server
- shared
- app
I'm having a hangout session with Chris later to discuss the differences in the layouts and the two plugins so maybe then I'll have a better handle on things :-)
from gwt-maven-plugin.
@slugmandrew Sorry, I wasn't clear enough: the last paragraph wasn't directed to you but to the OP. As I said in the first paragraph though, the next step to make in your test project is to change launcherDir
to point to your ${webappDirectory}
(beware of evaluation time of the properties though when inherited in modules; maybe you'd have to use businessenergybox-server/target/businessenergybox-server-${project.version}
instead), because the AppEngine plugin has no equivalent to the resourcesAsCSV
of the Jetty plugin, or the extraResourcePaths
from the Tomcat context.
The other differences with the Jetty (and Tomcat) plugins are that:
- I think you'll have to
mvn package -Denv=dev
whenever you make a change in your businessenergybox-shared module for your server to see the changes (as the module will be packaged as JAR inWEB-INF/lib
, and not loaded from the Maven reactor build; for the Jetty plugin there's a hack usingextraClasspath
). - because
launcherDir
points to the prod folder, you'll have tomvn clean
before youmvn package
(ormvn verify
) your app, to make sure the WAR will include the.nocache.js
from the businessenergybox-client module and not the one generated by SDM.
I'm not familiar with AppEngine though, so I may be wrong, and it could be easier and/or with fewer side-effects.
You can probably also use the -server
argument in <devmodeArgs>
for gwt:devmode
, also setting <warDir>
to your businessenergybox-server/target/businessenergybox-server-${project.version}
(gwt:devmode
uses warDir
, gwt:codeserver
uses launcherDir
):
<devmodeArgs>
<arg>-server</arg><arg>com.google.appengine.tools.development.gwt.AppEngineLauncher</arg>
</devmodeArgs>
The challenge here would be to have the com.google.appengine.tools.development.gwt.AppEngineLauncher
class in the classpath for DevMode without it messing with, say, the GWT Compiler classpath for a production build. Maybe it'd be as easy as using a <profile>
.
Wrt the layout suggested by Chris (Christian Goudreau? Of course we know him ;-) ), I suppose the server module is a simple JAR, and the app module simply uses it as a dependency? That's not much different from my archetypes then (and what I'm using in a project at work for several years now): server
module from the archetype becomes the app
module, and the "new" server
module is not much different from any other server-only dependency (e.g. Guice, in my dagger-guice-rf-activities
archetype) or the shared
module (except that it's only used on server-side so has no constraint on being GWT-compatible like the shared
module).
FWIW, we settled on such layout at work such that our server
module only depends on other modules containing only/mostly Java interfaces for your services, and the app
module is the one bringing the service implementations and wiring everything with Guice; that way, we made sure that the code in the server
module could never (even accidentally) depend on an implementation detail.
from gwt-maven-plugin.
Just my 2 cents, I'd steer clear from using the AppEngineLauncher to start the server. The reason is it's not an effective way to run the Server runtime because it's messy. Google built a much better way to run an app in the server run time, and it uses Eclipse Server Runtimes part of the Eclipse web tools. If you're using IDEA the same effect could be had. I also have seen the complications personally too. But I know folks really like the right click and debug and have the same process all in one. But when it comes down it there are so many gotchas. If you use a server runtime, and this runtime could be run anywhere with GWT as long as the launcherDir points into the war output path. Anyway, to my point, it won't matter how you configure the project if you use a server runtime. That is if you concentrate on using using the IDEs server runtime system, maven doesn't even have to control it. Or even use maven to start the services it won't matter. Then just start the CodeServer entry point and give it two things, the -launcherDir /point/to/server/runtime/war/output/path and module. I think it should be simple if you consider the server first. (Or start DevMode with the usual -war /output/to/war and -noserver)
from gwt-maven-plugin.
@tbroyer, @branflake2267, you are both so awesome for spending so much time replying. I will write you both a full response tomorrow, but for now - I think I got it (the auto-recompile) working... does this look right? Particularly the compile-1, compile-2 etc location?
It was as simple as setting <launcherDir>businessenergybox-server/target/businessenergybox-server-${project.version}</launcherDir>
and removing <appDir>${webappDirectory}</appDir>
from the appengine-maven plugin. See commit here if you're interested: slugmandrew/businessenergybox@61978be
Again, thanks so much and now I'll try and get a similar setup working when I have a hangout with Chris (Christopher Viel actually, but I also know Christian :) ) tomorrow.
from gwt-maven-plugin.
I believe the appDir
line that you needed to removed was because webappDirectory
is defined in the root POM, so it evaluates to target/businessenergybox-1.0-SNAPSHOT
instead of target/businessenergybox-server-1.0-SNAPSHOT
as expected by your launcherDir
(exactly what I warned about in my earlier comment). And it happens that target/businessenergybox-server-1.0-SNAPSHOT
is the default value that appengine:devserver
uses if appDir
is not set, which explains why it works when you comment the line out.
So, yes, everything looks good (except you have a bit of tidying to do in your POMs or you'll quickly be weighed down under technical debt)
from gwt-maven-plugin.
OK, so I'm along the right lines... I'm understanding this whole process a lot more now, having run gwt:codeserver -X
a ton of times and playing with the <launcherDir>
and <appDir>
properties yesterday.
It's been great for a while (as a maven newbie) to have everything in one place, and the Mojo plugin just go gwt:run
and boom - everything is done for you, but obviously that hides what is really going on and is not good in the long run!
I'm supposed to be having a meeting with Christopher now. This is roughly my 5 pom.xml
setup as it stands: https://gist.github.com/slugmandrew/1d9acf86be2c7db89031dc60de9df6e2 - a total mess with server and client dependencies in the shared pom, and other bits all over the place (I pass appengine.datastore.Key to client side, etc), because I've been using a single module for years building this app only going by the principle of "anything in shared can be used on either client or server". I am learning though so hopefully with a lot of work over the next couple of weeks I can have some nicely defined boundaries between client and server.
from gwt-maven-plugin.
I'm cringing I see app engine servlet launcher. :) You'll have to supersource the datastore key. I have done that, but you'll have to ask me offline for that bit. What I'd suggest doing first, perfect the classpath with maven, using maven to launch the app engine server. Then once that is perfect launching the codeserver and push the bits into the server war output directory using the launcherDir. Once you have those two pieces down, you're definitely good to go for debugging. But you probably want to run both launchers in the IDE. What you do here is match the maven launchers using the same classpath. At worst you can copy the classpath into the IDE launcher, annoying at best to do it this way. The IDE should be configuring the same classpath using the plugin tricks. By the way, I'm fixing the code server launcher for this plugin now and a few other things along the way. I've already got the src/main/webb warning fixed. I'm working on the code server launcher now.
from gwt-maven-plugin.
Yeah, that was the plan for the datastore key. If you'd like to give me any pointers offline my email is on my github profile page ๐ Or just point me to some code. I've super-sourced one of my own classes before so do I just do the same - mimic the package name and copy every method from the original?
But you probably want to run both launchers in the IDE
I was actually just discussing the different launch options with Christopher, and he had already recommended using IntelliJ to launch both servers. Annoying thing is I'll still have to use that damn bookmarklet but it's not exactly a massive problem I guess. I find it odd I still need the gwt-maven-plugin in my pom for the IntelliJ App Engine launcher to work properly though!
BTW, fixing the code server launcher sounds awesome - let me know when it needs testing (or anything else I can help with) and I'm right there.
from gwt-maven-plugin.
Since there are AppEngineLauncher notes here. This method of debugging will not be supported for much longer. Google has a new Cloud Eclipse Plugin and IntelliJ IDEA Eclipse Plugin. The goal is to use the CodeServer with -launcherDir or DevMode with and -war to push the bits to the external server runtime.
from gwt-maven-plugin.
Related Issues (20)
- Custom Linkers? HOT 2
- Source path from Inherited GWT.xml files are not being considered HOT 13
- GWT compilation failing with error, tried upgrading guice to 4.0 from 3.0 HOT 3
- Integration with GWT Eclipse Plugin seems partially broken HOT 6
- GWT 2.9.0 HOT 2
- GWT Multimodule modulename specificaiton HOT 1
- Redirected gwt artifacts cause a NPE when generating modules HOT 4
- Cannot compile GWT project using com.google.gwt:2.10.0-new-groupid-2 HOT 4
- API incompatibility issue with version 1.0.1 HOT 2
- Change default structure? HOT 2
- java process doesn't start. HOT 1
- Critical CVEs detected in transitive jar dependencies. HOT 1
- Validation warning, plugin should declare these Maven artifacts in `provided` scope HOT 1
- Upgrade to GWT 2.10.0 HOT 3
- goal codeserver fails when web app dependencies are managed in a BOM pom HOT 3
- [Question] How can i activate the debug logging ? because i keep getting the error: Hint: Check the inheritance chain from your module; it may not be inheriting a required module or a module may not be adding its source path entries properly HOT 5
- Release versiรณn with GWT 2.11.0 support HOT 2
- [Question] Can I hide the devmode gui? HOT 2
- Add support for JDK 17 HOT 1
- Maven execution not supported? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gwt-maven-plugin.