anchor.diff:  
   Right now, our entry point method is empty! What kind of stuff would
   you normally put in there for bootstrapping an UberFire app? Let's
  -create a panel and come back to that question.
  +first create a panel and then come back to that question.
   
   == Create a panel
   
   UberFire interfaces are made up of a few fundamental building blocks:
  -Widgets, Panels, Menu Bars, Tool Bars, and Perspectives. Panels
  -can contain Widgets and other Panels, and Perspectives give end users
  -the ability to rearrange Panels on the screen by dragging and dropping
  -them. Use of Perspectives is optional, so we'll leave them for later.
  +Widgets, Panels, Menu Bars, Tool Bars, and Perspectives. Panels can
  +contain Widgets and other Panels, and Perspectives contain Panels, an
  +optional Menu Bar, and an optional Tool Bar. Perspectives split up the
  +screen into multiple resizeable regions, and end users can drag and
  +drop Panels between these regions to customize their workspace. Use of
  +Perspectives is optional, so we'll leave them for later.
   
   To create your first panel, create the file
   `src/main/java/com/mycompany/uftutorial/client/PanelOne.java`:
  
positive.code: import org.uberfire.client.annotations.WorkbenchScreen;
  
  import com.google.gwt.user.client.ui.IsWidget;
  
  @Dependent
  @WorkbenchScreen(identifier="PanelOne")
  
negative.code: testing against a real JBoss EAP or WildFly instance. We don't want
  Dev Mode to start its embedded Jetty server.
  
  Next, we enable GWT's strict mode. This causes the build to fail with
  a helpful error message when you use Java APIs that aren't available
  in GWT's in-browser runtime environment (GWT calls this
  _non-translatable_ code). Without strict mode, these errors will show
  up later in the compile in a way that gives you no clue what happened.
  
  NOTE: There is a caveat to using strict mode: it is not compatible
  with client-side Bean Validation, so you will have to turn it off when
  and if you start using Bean Validation in your app's client-side
  code. The inferior alternatve to strict mode is to set Dev Mode's
  `logLevel` to `DEBUG` and sift through the output for clues about
  non-translatable code. But we don't have to worry about that at this
  point.
  
  Moving on, we set `runTarget` to the local URL where your webapp will
  be served by the JBoss EAP or WildFly server on your workstation.
  
  The `extraJvmArgs` setting increases the memory limits for the Dev
  Mode JVM, and asks its JIT compiler to be more aggressive in
  generating native code. We've done some experimenting and found a
  compile threshold of 1000 allows Dev Mode to start up a little faster.
  
  Next up, we configure `maven-war-plugin`, which produces the WAR file
  during the build's _package_ phase:
  
  [source,xml]
  ---------
  