=====================================================================
 Setting eclipse project references using mvn eclipse:eclipse
=====================================================================

1. Disable Maven 

> cd ../trunk
> mvn eclipse:clean -Dall -Defeature
> mvn eclipse:eclipse -Dall -Defeature

see: http://osgeo-org.1803224.n2.nabble.com/eclipse-cross-project-dependencies-td6341944.html

=====================================================================
 HOWTO: Set EFeature logging configuration file  
=====================================================================

1. Open a Run/Debug configuration
2. Goto tab "Arguments"
3. Enter VM argument
    
    -Djava.util.logging.config.file=logging/logging.properties
    
=====================================================================
 EFeature DataStore Implementation Comments
=====================================================================

Notice: plugin.xml, plugin.properties, build.properties
-------------------------------------------------------

These files are only here because testing the EMF model requires 
EMF Edit, which is only possible to generate if at least one plug-in 
class is defined. The plug-in IS NOT part of the Maven artifact.

=====================================================================
 EFeatureTest GenModel Setup Trick (merge all code into one plug-in)
=====================================================================
 
  > EMF Model, Edit and Test code should be generated (merged) into 
    the same plug-in: 
    
        org.geotools.data.efeature.tests.EFeatureTestsPlugin
    
    (reduces the number of maven artifacts needed)
            
  HOWTO: 
  ------
  
  1. Open file src/test/resources/model/efeature-tests.genmodel
  2. Select "EFeatureTest" (root)
  3. R-Clk -> select "Show Properties View"
  4. Expand "Model", enter "Model Directory", "Model Plug-in Class"
     and "Model Plug-in ID"
  5. Expand "Edit", enter same "Model Directory" as in step 3. This
     forces the Edit code to be generated into the same plug-in
     as the EFeatureTest model.
  6. Repeat step 4 for "Test"
  7. Ensure that "Editor" has no "Model Directory" and no 
     "Model Plug-in class". If forgotten, the Editor code is also
     generated by R-Clk on "EFeatureTest" -> "Generate All". If 
     successful, R-Clk on "EFeatureTest" -> "Generate Editor Code" 
     should be disabled.

=====================================================================
 EFeatureTest Build Procedure
=====================================================================
  
  1. Open file src/test/resources/model/efeature-tests.genmodel
  2. R-Clk on "EFeatureTest" (root) -> select "Generate All"

=====================================================================
 EFeatureTest Build Troubleshooting
=====================================================================

  1. "Generate All" produces many errors
  --------------------------------------
     
  If a lot of errors was produced by "Generate All", the property
  "EFeaureTest" -> "Templates & Merge" -> "Update Classpath" is
  probably "true", which overwrites the class-path built by the
  command "..efeature-tests> mvn eclipse:eclipse". This problem is
  easily fixed by executing "..efeature-tests> mvn eclipse:eclipse"
  one more time and then do a refresh at the "efeature-test" project
  root.
    
  2. Unit tests fails with error: 
  "java.io.FileNotFoundException: Can not locate test-data for "null"
  --------------------------------------------------------------------
  
  The reason is that the folder is not built (for some reason). This
  can be verified by inspection of target/test-classes/.../tests. Is
  missing, just force a build of this folder. F.ex by renaming it to
  "test-data1" and then rename it back again to "test-data". 
  
======================================================================
 EFeature Ideas
======================================================================
  
  Adding support for thread safe commits in stand-alone applications
  --------------------------------------------------------------------
  
  EMF does support this through EMF transaction. EMF transaction 
  however, requires the Eclipse Platform on the class path, which is 
  very restrictive because EFeature can only be run on the Eclipse 
  platform. A alternative to is to combine GT feature locking 
  capabilities with a EMF ChangeRecorder. This however, will only be 
  thread safe if all access to locked EObject is performed from GT 
  transaction aware client code. Hence, locked EObjects is still 
  accessible (read and write) by EMF dependent client code not aware
  of (or don't care about) the transaction.     
  
  The algorithm could be something like this:
  
    1) On begin:
        
        - lock all features to prevent access from other transactions 
        - create a temporary transaction resource
        - add this resource to a ChangeRecorder
          
        
    2) On next: 
    
        - make copy of EObject
        - return copy to client code

    3) On next: 
    
        - make copy of EObject
        - return copy to client code
         
    *** Every change is recorded by the ChangeRecorder ***
    
    4) On Commit:

        - apply and revert changes to transaction resource
          (this produces a forward delta ChangeDescrition)
        - add all changed EObjects to old resource
        - apply changes from forward delta 
            
            
  NOTES: EMF 2.7.0 (releases with Eclipse 3.7) adds forward delta
         support to ChangeRecorder class.