Maven plugins

278 views
Skip to first unread message

Joshua Fox

unread,
Apr 30, 2017, 9:30:39 AM4/30/17
to google-a...@googlegroups.com
What is the difference between these  two Maven plugins?


  • com.google.appengine::appengine:appengine-maven-plugin
  • Older

- Cloud-SDK Based
  • com.google.cloud.tools::appengine-maven-plugin
  • Newer
  • Is it recommended over the other one? 
  • What is the relation to appcfg? Is it  simply that appcfg is a component of the Cloud-SDK (where the Cloud-SDK consists of gcloud and related CLI tools)
  • Will an upcoming version depend on the Google AppEngine SDK for Java? 
  • I see that Google Cloud Tools for Eclipse   interacts well with Maven, so that Maven can handle dependency management, goals etc. Does the Google Cloud Tools for Eclipse bundle/use the 
  • com.google.cloud.tools::appengine-maven-plugin?

Joshua Fox

unread,
Apr 30, 2017, 9:44:10 AM4/30/17
to google-a...@googlegroups.com
On Sun, Apr 30, 2017 at 4:29 PM, Joshua Fox <jos...@freightos.com> wrote:
What is the difference between these  two Maven plugins?


  • com.google.appengine::appengine:appengine-maven-plugin
  • Older

- Cloud-SDK Based
  • com.google.cloud.tools::appengine-maven-plugin
  • Newer
  • Is it recommended over the other one? 
  • What is the relation to appcfg? Is it  simply that appcfg is a component of the Cloud-SDK (where the Cloud-SDK consists of gcloud and related CLI tools)
  • Will an upcoming version depend on the Google AppEngine SDK for Java? 
Or perhaps just on the  Dev Appserver v1? I'll appreciate some clarification on that.
 



--
JOSHUA FOX
Principal Software Architect | Freightos


☏ (Israel): +972-545691165 | ☏ (US):  +1-3123400953 | Skype: joshuafox.freightos
Smoother shipping with the world's online freight marketplace.

Adam (Cloud Platform Support)

unread,
Apr 30, 2017, 2:48:57 PM4/30/17
to google-a...@googlegroups.com
To answer your questions:
  • Is it recommended over the other one?

  • It's actually recommended to use the App Engine standalone SDK based plugin for now, due to some issues with the development server in the Cloud SDK. See also the related discussion for more details.

  • What is the relation to appcfg? Is it simply that appcfg is a component of the Cloud-SDK (where the Cloud-SDK consists of gcloud and related CLI tools)?

    The Cloud SDK based plugin doesn't have any dependency on appcfg. It uses the gcloud command from the Cloud SDK to manage operations (eg. gcloud app deploy). It still invokes dev_appserver, but this is a newer version (v2) than the one included in the standalone SDK (v1) and currently has some issues as mentioned above. 

  • Will an upcoming version depend on the Google App Engine SDK for Java? 

  • No, as the point of the plugin is to move away from the standalone SDK and support the Cloud SDK.

  • I see that Google Cloud Tools for Eclipse interacts well with Maven, so that Maven can handle dependency management, goals etc. Does the Google Cloud Tools for Eclipse bundle/use the com.google.cloud.tools::appengine-maven-plugin?

  • When you create a project using the template 'Maven-based Google App Engine Standard Java Project', it will create a Maven project using the appengine-standard-archetype archetype that uses the com.google.cloud.tools::appengine-maven-plugin. This is just a UX convenience for creating a regular Maven project that uses that same archetype.

Joshua Fox

unread,
May 1, 2017, 1:24:23 AM5/1/17
to google-a...@googlegroups.com
Thank you. That's useful.

On Sun, Apr 30, 2017 at 9:48 PM, 'Adam (Cloud Platform Support)' via Google App Engine <google-appengine@googlegroups.com> wrote:
To answer your questions:
  • Is it recommended over the other one?

    It's actually recommended to use the App Engine standalone SDK based plugin for now, due to some issues with the development server in the Cloud SDK.
  • See also the related discussion for more details.

  • What is the relation to appcfg? Is it simply that appcfg is a component of the Cloud-SDK (where the Cloud-SDK consists of gcloud and related CLI tools)?

    The Cloud SDK based plugin doesn't have any dependency on appcfg. It uses the gcloud command from the Cloud SDK to manage operations (eg. gcloud app deploy). It still invokes dev_appserver, but this is a newer version (v2) than the one included in the standalone SDK (v1) and currently has some issues as mentioned above. 

  • Will an upcoming version depend on the Google App Engine SDK for Java? 

    No, as the point of the plugin is to move away from the standalone SDK and support the Cloud SDK.

  • I see that Google Cloud Tools for Eclipse interacts well with Maven, so that Maven can handle dependency management, goals etc. Does the Google Cloud Tools for Eclipse bundle/use the com.google.cloud.tools::appengine-maven-plugin?

    When you create a project using the template 'Maven-based Google App Engine Standard Java Project', it will create a Maven project using the appengine-standard-archetype archetype that uses the com.google.cloud.tools::appengine-maven-plugin. This is just a UX convenience for creating a regular Maven project that uses that same archetype.

 
What is the status of Google Cloud Tools for Eclipse? On the one hand, it  is recommended on the Google Group thread; but on the other hand, it it is designed to work with the  Cloud-SDK Based Maven plugin which is not now recommended.
 
On Sunday, April 30, 2017 at 9:30:39 AM UTC-4, Joshua Fox wrote:
What is the difference between these  two Maven plugins?


  • com.google.appengine::appengine:appengine-maven-plugin
  • Older

- Cloud-SDK Based
  • com.google.cloud.tools::appengine-maven-plugin
  • Newer
  • Is it recommended over the other one? 
  • What is the relation to appcfg? Is it  simply that appcfg is a component of the Cloud-SDK (where the Cloud-SDK consists of gcloud and related CLI tools)
  • Will an upcoming version depend on the Google AppEngine SDK for Java? 
  • I see that Google Cloud Tools for Eclipse   interacts well with Maven, so that Maven can handle dependency management, goals etc. Does the Google Cloud Tools for Eclipse bundle/use the 
  • com.google.cloud.tools::appengine-maven-plugin?

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/48be9f57-91ae-44ab-a47e-f8e325e20ba8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Les Vogel

unread,
May 1, 2017, 2:20:12 PM5/1/17
to Google App Engine
Actually, the Cloud SDK based tooling now uses dev_appserver v1, not dev_appserver v2 to run your GAE Standard Java apps.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CAD%3DB7cP7-kNkvYycn3f_102aeAyWiY2JbmvUMABxHT0miSo1dw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--

  •  Les Vogel
  •  Cloud Developer Relations
  •  le...@google.com
  •  +1-408-676-7023 

Adam (Cloud Platform Support)

unread,
May 1, 2017, 3:29:28 PM5/1/17
to Google App Engine
Yes, you're right. I see that it was just changed in the 1.3.0 release. So you can ignore my first point, as it should now be fine to use the Cloud SDK based Maven plugin in all cases.


On Monday, May 1, 2017 at 2:20:12 PM UTC-4, Les Vogel wrote:
Actually, the Cloud SDK based tooling now uses dev_appserver v1, not dev_appserver v2 to run your GAE Standard Java apps.

Jeff Schnitzer

unread,
May 1, 2017, 4:06:04 PM5/1/17
to Google App Engine
I’ve been using both plugins (you can configure them both in your pom) for a while now and can confirm: While the cloud tools plugin had a number of issues up until a couple weeks ago, it works pretty well now. I dropped the com.google.appengine plugin and now use the cloud tools one fulltime.

The cloud tools plugin makes it somewhat easier to script deployment (eg, you can pass the project & version in as cmdline params).

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/5af4398a-e787-4fe2-b9e5-3af032f2c187%40googlegroups.com.

Joshua Fox

unread,
May 3, 2017, 8:03:33 AM5/3/17
to google-a...@googlegroups.com
A question about Google Cloud Tools for Eclipse , given all these changes.


1. If I want to debug my projects without using "remote debugging"? 
a. Do I need  Google Cloud Tools for Eclipse?
b. We are using the  Cloud-SDK-Based 1.30 Maven plugin  which has dev-appserver v1. If we wait until  Cloud-SDK-Based Maven  plugin goes back to dev-appserver v2, (how long might hat be), will we be able to debug with a Cloud-SDK-Based Maven project (opened in Eclipse, but without Google Cloud Tools for Eclipse)?  

2. What is the recommended development setup for Standard Env? 
a. Is it Cloud Tools for Eclipse with the Cloud-SDK-Based Maven  plugin? 
b. Or just Cloud-SDK-Based Maven  plugin without Cloud Tools for Eclipse?
 
3. What is the recommended development setup  for Flex Env development? We need a single dev-environment to develop a GAE-Standard-Env service and a GAE-Flex-Env service on the same codebase.
- We actually don't need "Flex support" in the sense of a local Docker or builtin deployment. So the fact that  Cloud Tools for Eclipse  is said to not support Flex might not be relevant.
- For launching an appserver, we can use the Maven-Jetty plugin (org.eclipse.jetty::jetty-maven-plugin v 9.4.2)
- But I am not sure if that is the full recommended setup. What do you suggest?  

Adam (Cloud Platform Support)

unread,
May 6, 2017, 4:08:47 PM5/6/17
to Google App Engine
1. If I want to debug my projects without using "remote debugging"?
You need to use remote debugging to debug App Engine applications in Eclipse as the debugger must connect to the Jetty instance running on localhost.

a. You don't need to use Google Cloud Tools for Eclipse as both maven plugins support the jvmFlags option which allows you to provide the necessary JVM flags for debugging:

<configuration>
    <jvmFlags>
      <jvmFlag>-Xdebug</jvmFlag>
      <jvmFlag>-Xrunjdwp:transport=dt_socket,address=9999,server=y,suspend=n</jvmFlag>
    </jvmFlags>
  </configuration>
  
See the related discussion in an issue on the old plugin's project page for a solution involving Maven profiles (this applies equally to the new plugin as the same parameter is supported).

b. The ability to connect the debugger isn't dependent on the version of dev_appserver, which is mostly a Python wrapper around Jetty, so yes you would still be able to debug with either plugin. Note that as Jeff mentioned you can also use both plugins in your project.

2. What is the recommended development setup for Standard Env?
a. Cloud Tools for Eclipse seems to be more of a 'getting started quickly' solution, with some UI conveniences but fewer features, so for more serious projects I'd personally recommend the Maven plugin.

b. This really depends on your needs. There's nothing you can do with the Cloud Tools plugin that you can't do with the Maven plugin, and as mentioned you can also use both (one is a plugin for Maven via pom.xml, the other is for the Eclipse project proper, and they don't mess with each other).

3. What is the recommended development setup  for Flex Env development?
No special App-Enginey bits are needed to test a flexible runtime app locally or manage it in Eclipse. This is covered in the docs; you can use mvn jetty:run-exploded with the Jetty plugin if you're on a Jetty based runtime or just mvn package; java -jar target/myjar.jar on any other runtime. A flexible runtime Java app is essentially just a Dockerized Java app that happens to run on the Flexible runtime.

Joshua Fox

unread,
May 7, 2017, 9:01:22 AM5/7/17
to google-a...@googlegroups.com, Montasir Asaira, Sharat Shroff
On Sat, May 6, 2017 at 11:08 PM, 'Adam (Cloud Platform Support)' via Google App Engine <google-appengine@googlegroups.com> wrote:
1. If I want to debug my projects without using "remote debugging"?
You need to use remote debugging to debug App Engine applications in Eclipse as the debugger must connect to the Jetty instance running on localhost.

This is inconvenient.  Every time a developer runs their code, they have to launch two processes. Is there a plan to improve that?


--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

For more options, visit https://groups.google.com/d/optout.

Adam (Cloud Platform Support)

unread,
May 7, 2017, 2:38:21 PM5/7/17
to Google App Engine, Mont...@freightos.com, sha...@google.com
I'm not sure I follow. You need to launch the dev_appserver process anyway to run your application locally. You're just passing extra JVM flags to enable the remote debugger so JDB can talk to it. AFAIK you need to enable the JPDA remote debugger to debug any Jetty app (or servlet container app for that matter). It's not a limitation of App Engine or the plugins.

Joshua Fox

unread,
May 8, 2017, 6:45:56 AM5/8/17
to google-a...@googlegroups.com, Montasir Asaira, Sharat Shroff
We have been using the  Google Plugin for Eclipse (now end-of-life). There, we are  able to launch an Eclipse Debug configuration that puts us right into the debugger.  (Screenshot attached.)

Launching two separate processes (first appengine:runfrom the Cloud-SDK-Based Maven plugin, then the remote debug process) is particularly inconvenient given that dozens of developer must  do this many  times a day.

We'd like to have the same simplicity of a single launch.

Inline image 2


For more options, visit https://groups.google.com/d/optout.

Brian de Alwis

unread,
May 8, 2017, 9:07:44 AM5/8/17
to google-a...@googlegroups.com
Josuha, you can use the Cloud Tools for Eclipse (CT4E, the successor to GPE) for launching even with Maven based plugins.

Launching two separate processes (first appengine:runfrom the Cloud-SDK-Based Maven plugin, then the remote debug process) is particularly inconvenient given that dozens of developer must  do this many  times a day.

I didn't see a reference to this in the email thread, but I'm guessing you're launching multiple services?  Launching multiple services is supported by CT4E.

With regard to Flex, CT4E is concentrating on the deployment side of the story.  For run/debug, the solutions right now are to use the Maven goals or other plugins like Run Jetty Run:


Brian.

On 8-May-2017, at 6:43 AM, Joshua Fox <jos...@freightos.com> wrote:

We have been using the  Google Plugin for Eclipse (now end-of-life). There, we are  able to launch an Eclipse Debug configuration that puts us right into the debugger.  (Screenshot attached.)

Launching two separate processes (first appengine:runfrom the Cloud-SDK-Based Maven plugin, then the remote debug process) is particularly inconvenient given that dozens of developer must  do this many  times a day.

We'd like to have the same simplicity of a single launch.

<image.png>
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

Joshua Fox

unread,
May 8, 2017, 9:25:38 AM5/8/17
to google-a...@googlegroups.com
On Mon, May 8, 2017 at 4:07 PM, Brian de Alwis <briand...@gmail.com> wrote:
Josuha, you can use the Cloud Tools for Eclipse (CT4E, the successor to GPE) for launching even with Maven based plugins.

Thank you. What added value does CT4E provide as compared to just Maven? Note that Adam of Google Support said:
 
 
a. Cloud Tools for Eclipse seems to be more of a 'getting started quickly' solution, with some UI conveniences but fewer features, so for more serious projects I'd personally recommend the Maven plugin.
b. This really depends on your needs. There's nothing you can do with the Cloud Tools plugin that you can't do with the Maven plugin, 

 
 
I didn't see a reference to this in the email thread, but I'm guessing you're launching multiple services?  Launching multiple services is supported by CT4E.


No, we are just launching  the builtin dev-appserver that you get when you run Maven goal  appengine:run on the Cloud-SDK Based Maven plugin. Of course, I don't insist on using Maven to launch. Whatever it takes to avoid launching two processes just to debug ( appengine:run plus the "remote" debugger).


With regard to Flex, CT4E is concentrating on the deployment side of the story.

Right. Deployment in an Eclipse tool is less valuable to us, as we have Jenkins setup to deploy. In fact, Google Support, in early 2017, told us that CT4E does not support  Flex Env. I think they were referring to limitations in deployment and a local Dockerized Flex -- but we do not need those.
 
 For run/debug, the solutions right now are to use the Maven goals or other plugins like Run Jetty Run:


Debugging of a Flex-like (not supporting GAE APIs) local environment inside  Eclipse is possible with the Jetty Maven plugin.  

But  I guess you are saying that  Run  Jetty Run would make this more efficient? I.e., we'd have one debug process rather than '"remote" debugging; and we'd avoid build time in which Maven constructs wars? If that can be done  for a Standard-Env-like local dev environment  (of the sort supported by the  Cloud-SDK Based Maven plugin or the old Google Plugin for Eclipse), that would be excellent!

Brian.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

For more options, visit https://groups.google.com/d/optout.

Brian de Alwis

unread,
May 8, 2017, 10:31:06 AM5/8/17
to google-a...@googlegroups.com
CT4E is to the Maven plugin as m2eclipse is for maven: it uses Eclipse for what Eclipse does best, and Maven for what Maven does best.  CT4E leverages the Eclipse incremental compiler and WTP to enable immediate run/debug and class replacement at debug-time without having to restart the world.  And it also supports deployment from within Eclipse.

Brian.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

Joshua Fox

unread,
May 9, 2017, 5:01:15 AM5/9/17
to google-a...@googlegroups.com

 Eclipse incremental compiler and WTP to enable immediate run/debug and class replacement at debug-time 

Thank  you. That makes sense.

Adam of Cloud Platform Support, your statement (copied immediately below in blue ) seems to contradict Brian's. Could you please explain?

On Sat, May 6, 2017 at 11:08 PM, 'Adam (Cloud Platform Support)' via Google App Engine <google-appengine@googlegroups.com> wrote:
 ...

a. Cloud Tools for Eclipse seems to be more of a 'getting started quickly' solution, with some UI conveniences but fewer features, so for more serious projects I'd personally recommend the Maven plugin.

b. This really depends on your needs. There's nothing you can do with the Cloud Tools plugin that you can't do with the Maven plugin, and as mentioned you can also use both (one is a plugin for Maven via pom.xml, the other is for the Eclipse project proper, and they don't mess with each other).
Brian.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

For more options, visit https://groups.google.com/d/optout.

Brian de Alwis

unread,
May 9, 2017, 11:11:00 AM5/9/17
to google-a...@googlegroups.com
CT4E offers two styles of App Engine projects for the standard environment:


The first one, the Google App Engine Standard Java Project, is a "native" WTP-based Eclipse project style.  The Maven-based Google App Engine Standard Java Project creates a Maven-based project using the new Maven App Engine plugins.  This Maven project uses M2Eclipse and its accompanying m2e-wtp bindings to integrate with Eclipse, which works very well.

So I believe Adam is recommending using Maven-based projects for important projects, like what is created by the second wizard.  I agree with that recommendation as it allows leveraging the many tools in the Maven ecosystem and works well with existing CI/CD solutions.

Brian.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

Adam (Cloud Platform Support)

unread,
May 9, 2017, 2:49:41 PM5/9/17
to Google App Engine
Yes, I should have specified that I meant the project type, not the plugin, since CT4E of course allows you to create a Maven-based project as well. I'm mostly speaking from personal preference. I like the additional options you get with M2Eclipse (like being able to specify a working set), and do most command invocation from a terminal. Hot reload also works fine when debugging this way with 'Build automatically' enabled in Eclipse, as it will replace .class files directly in the target/ directory without needing to invoke a Maven build.

Thanks Brian for shedding light on how CT4E handles debugging and integration with WTP. My understanding was that the JPDA remote debugger is still used under the hood when debugging locally in WTP, but I am nowhere near an expert on the Eclipse platform. Is this the case?

On Tuesday, May 9, 2017 at 11:11:00 AM UTC-4, Brian de Alwis wrote:
CT4E offers two styles of App Engine projects for the standard environment:


The first one, the Google App Engine Standard Java Project, is a "native" WTP-based Eclipse project style.  The Maven-based Google App Engine Standard Java Project creates a Maven-based project using the new Maven App Engine plugins.  This Maven project uses M2Eclipse and its accompanying m2e-wtp bindings to integrate with Eclipse, which works very well.

So I believe Adam is recommending using Maven-based projects for important projects, like what is created by the second wizard.  I agree with that recommendation as it allows leveraging the many tools in the Maven ecosystem and works well with existing CI/CD solutions.

Brian.
On 9-May-2017, at 4:59 AM, Joshua Fox  wrote:


 Eclipse incremental compiler and WTP to enable immediate run/debug and class replacement at debug-time 

Thank  you. That makes sense.

Adam of Cloud Platform Support, your statement (copied immediately below in blue ) seems to contradict Brian's. Could you please explain?

On Sat, May 6, 2017 at 11:08 PM, 'Adam (Cloud Platform Support)' via Google App Engine <google-appengine@googlegroups.com> wrote:
 ...
a. Cloud Tools for Eclipse seems to be more of a 'getting started quickly' solution, with some UI conveniences but fewer features, so for more serious projects I'd personally recommend the Maven plugin.

b. This really depends on your needs. There's nothing you can do with the Cloud Tools plugin that you can't do with the Maven plugin, and as mentioned you can also use both (one is a plugin for Maven via pom.xml, the other is for the Eclipse project proper, and they don't mess with each other).

On Mon, May 8, 2017 at 5:30 PM, Brian de Alwis  wrote:
CT4E is to the Maven plugin as m2eclipse is for maven: it uses Eclipse for what Eclipse does best, and Maven for what Maven does best.  CT4E leverages the Eclipse incremental compiler and WTP to enable immediate run/debug and class replacement at debug-time without having to restart the world.  And it also supports deployment from within Eclipse.

Brian.

On 8-May-2017, at 9:23 AM, Joshua Fox  wrote:

Brian de Alwis

unread,
May 9, 2017, 3:39:33 PM5/9/17
to google-a...@googlegroups.com
Yup, CT4E connects up the Eclipse Platform/Debug and JDT/Debug support, which works across JDWP (a component of JPDA), to debug the dev_appserver.  But fortunately nobody needs to ever know about it!

Brian.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

Joshua Fox

unread,
May 10, 2017, 7:49:45 AM5/10/17
to google-a...@googlegroups.com
On Tue, May 9, 2017 at 6:10 PM, Brian de Alwis <briand...@gmail.com> wrote: 
The first one, the Google App Engine Standard Java Project, is a "native" WTP-based Eclipse project style.  The Maven-based Google App Engine Standard Java Project creates a Maven-based project using the new Maven App Engine plugins.  
.... 
 leveraging the many tools in the Maven ecosystem and works well with existing CI/CD solutions.
 

Thank you. Brian. I understand better now. 

We would need to use the CT4E+Maven option, for all those reasons.  Indeed, with the old Google Plugin for Eclipse, we were very constrained by the way that the Eclipse plugin defined the layout and configuration of our project. 

On Tue, May 9, 2017 at 10:39 PM, Brian de Alwis <briand...@gmail.com> wrote:  
Yup, CT4E connects up the Eclipse Platform/Debug and JDT/Debug support, which works across JDWP (a component of JPDA), to debug the dev_appserver.  But fortunately nobody needs to ever know about it!

Thank you! So one-launch debugging is one type of  extra value of CT4E as compared to just using the Cloud-SDK-based Maven plugin  in Eclipse..

I guess both approaches provide hot reload? (Debug-time class reloading.)

What about incremental compilation?  (E..g, add a class or static method and launch the debugger, and only a few relevant class files are recompiled, then launch debug session, with no wait for a war to be  built.)

I should add that we separate our code into multiple Maven-modules for modularity.  (This translates to one Eclipse project per Maven module.) So, the above features would have to work with that.

Best,

Joshua
 

Elliotte Rusty Harold

unread,
May 10, 2017, 1:07:56 PM5/10/17
to Google App Engine, Mont...@freightos.com, sha...@google.com


On Monday, May 8, 2017 at 6:45:56 AM UTC-4, Joshua Fox wrote:

Launching two separate processes (first appengine:runfrom the Cloud-SDK-Based Maven plugin, then the remote debug process) is particularly inconvenient given that dozens of developer must  do this many  times a day.


I'm not sure I follow. It's always two separate processes, no matter how you launch. With Cloud Tools for Eclipse you can launch both with a  single action: Debug As > App Engine.

If you need a more custom local server environment with extra command line arguments and what not,  you can create that in Eclipse like any other launch configuration and save it for future one-click use form the Debug menu.

Brian de Alwis

unread,
May 10, 2017, 10:01:12 PM5/10/17
to google-a...@googlegroups.com
On 10-May-2017, at 7:48 AM, Joshua Fox <jos...@freightos.com> wrote:
> I guess both approaches provide hot reload? (Debug-time class reloading.)

CT4E uses the same Eclipse facilities used for Java projects to download new class definitions to the remote JVM. This allows in-place modification of a class without having to restart the web module, providing the remote JVM allows hot-swapping in the changed class definition.

The Maven App Engine plugins support hot reload but with a very different approach: it launches the dev_appserver on the exploded war file (i.e., extracted on disk) such that the .class files are overwritten during the Maven compilation; the dev_appserver detects the file changes and restarts the web server. This usually requires re-connecting to the debugger though.

> What about incremental compilation? (E..g, add a class or static method and launch the debugger, and only a few relevant class files are recompiled, then launch debug session, with no wait for a war to be built.)

CT4E is based on Eclipse WTP which supports incremental building and publishing. CT4E doesn't build wars (and the dev_appserver doesn't want a war).

> I should add that we separate our code into multiple Maven-modules for modularity. (This translates to one Eclipse project per Maven module.) So, the above features would have to work with that.

CT4E leverages m2e-wtp for multi-module support, and it works with no issue that we're aware of.

Brian.

Joshua Fox

unread,
May 11, 2017, 3:14:46 AM5/11/17
to google-a...@googlegroups.com
On Thu, May 11, 2017 at 5:01 AM, Brian de Alwis <briand...@gmail.com> wrote:
On 10-May-2017, at 7:48 AM, Joshua Fox <jos...@freightos.com> wrote:
> I guess both approaches provide hot reload? (Debug-time class reloading.)

CT4E uses the same Eclipse facilities used for Java projects to download new class definitions to the remote JVM.  This allows in-place modification of a class without having to restart the web module, providing the remote JVM allows hot-swapping in the changed class definition.

The Maven App Engine plugins support hot reload but with a very different approach: it launches the dev_appserver on the exploded war file (i.e., extracted on disk) such that the .class files are overwritten during the Maven compilation; the dev_appserver detects the file changes and restarts the web server.  This usually requires re-connecting to the debugger though.

> What about incremental compilation?  (E..g, add a class or static method and launch the debugger, and only a few relevant class files are recompiled, then launch debug session, with no wait for a war to be  built.)

CT4E is based on Eclipse WTP which supports incremental building and publishing.  CT4E doesn't build wars (and the dev_appserver doesn't want a war).

Thank you! So it seems that CT4E plus the Cloud-SDK-based   Maven  App Engine plugin  offers better hot-reload and incremental build than just using the Maven plugin in Eclipse.

> I should add that we separate our code into multiple Maven-modules for modularity.  (This translates to one Eclipse project per Maven module.) So, the above features would have to work with that.

CT4E leverages m2e-wtp for multi-module support, and it works with no issue that we're aware of.

Brian.
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

For more options, visit https://groups.google.com/d/optout.

Joshua Fox

unread,
May 11, 2017, 3:15:07 AM5/11/17
to google-a...@googlegroups.com
On Mon, May 8, 2017 at 2:35 PM, 'Elliotte Rusty Harold' via Google App Engine <google-appengine@googlegroups.com> wrote:


On Monday, May 8, 2017 at 6:45:56 AM UTC-4, Joshua Fox wrote:

Launching two separate processes (first appengine:runfrom the Cloud-SDK-Based Maven plugin, then the remote debug process) is particularly inconvenient given that dozens of developer must  do this many  times a day.


I'm not sure I follow. It's always two separate processes, no matter how you launch. With Cloud Tools for Eclipse you can launch both with a  single action: Debug As > App Engine.

Thank you. Yes, that is what I meant -- the convenience of launching with a single action. If behind the scenes there are two processes, that is fine.  

If you need a more custom local server environment with extra command line arguments and what not,  you can create that in Eclipse like any other launch configuration and save it for future one-click use form the Debug menu.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

For more options, visit https://groups.google.com/d/optout.

appu

unread,
May 15, 2017, 6:37:51 PM5/15/17
to Google App Engine
I'm not sure where you ended up on hot reload, but if you haven't got it working : it needs a little configuration to enable.

1. You have to configure the dev_appserver to scan the war directory using the jvmFlags in the appengine-maven-plugin

<configuration>
  <jvmFlags>
    <jvmFlag>-Dappengine.fullscan.seconds=5</jvmFlag>
  </jvmFlags>
</configuration>

and then you can run "mvn war:exploded" to rebuild from the command line/maven tool window.

I don't use eclipse, but there's a trick in eclipse to tell it to write your rebuilt classes directly to the target/<project>/WEB-INF/classes directory. The following setting just works on class reloading, but I think it configures your IDE to build on save directly into the exploded-app dir that the dev appserver is reading from.
<build>
   <outputDirectory>target/${project.artifactId}-${project.version}/WEB-INF/classes</outputDirectory>
   <plugins>
      ....
   </plugins>
</build>

On Thursday, May 11, 2017 at 3:15:07 AM UTC-4, Joshua Fox wrote:


On Mon, May 8, 2017 at 2:35 PM, 'Elliotte Rusty Harold' via Google App Engine <google-a...@googlegroups.com> wrote:


On Monday, May 8, 2017 at 6:45:56 AM UTC-4, Joshua Fox wrote:

Launching two separate processes (first appengine:runfrom the Cloud-SDK-Based Maven plugin, then the remote debug process) is particularly inconvenient given that dozens of developer must  do this many  times a day.


I'm not sure I follow. It's always two separate processes, no matter how you launch. With Cloud Tools for Eclipse you can launch both with a  single action: Debug As > App Engine.

Thank you. Yes, that is what I meant -- the convenience of launching with a single action. If behind the scenes there are two processes, that is fine.  

If you need a more custom local server environment with extra command line arguments and what not,  you can create that in Eclipse like any other launch configuration and save it for future one-click use form the Debug menu.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

Joshua Fox

unread,
May 16, 2017, 2:13:53 AM5/16/17
to google-a...@googlegroups.com, Amir Rouzrokh
Thank you! 

On this thread, we are gradually putting together a overview of the capabilities. Here is what we have pieced together so far.

Questions: Are the following available during debugging a Standard Env application?

1:  ... with the Cloud-SDK Based Maven plugin running in Eclipse with m2e without CT4E?

- Hot reload during debug -- yes (per Appu's latest answer)
- Incremental compilation during development -- yes
- Rapid launch (under 2 seconds,  avoiding wait for the war to be rebuilt and copied) -- no (?)
- One-launch debug (avoiding the need to launch twice: the server, then the "remote" debugger) -- no 
- Multi-Maven-module support --   yes

2: .... with CT4E on top of the  Cloud-SDK based Maven plugin?

- Hot reload --  yes
- Incremental compilation -- yes
- Rapid launch -- yes (per Appu's latest answer)
- One-launch debug --  yes
- Multi-Eclipse-Project support  (correctly tracking dependencies in a multi-Maven-module workspace) -- yes



To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages