Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CDO Development Guidelines"

(Members)
 
(15 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
<font color="red">This page is not yet finished. Do not take these guidelines for granted until the note is removed!</font>
 
<font color="red">This page is not yet finished. Do not take these guidelines for granted until the note is removed!</font>
  
==Basic Coding Guidelines==
+
==General Coding Guidelines==
 
The following Guide describes the basic requirements for creating CDO source code. Not all of these guidlines can be coverred by the auto-format for Java source Code (Strg+Shift+F). If you like to write an extension that allows comfortably adjusting the code regarding these Guidelines you are welcome.
 
The following Guide describes the basic requirements for creating CDO source code. Not all of these guidlines can be coverred by the auto-format for Java source Code (Strg+Shift+F). If you like to write an extension that allows comfortably adjusting the code regarding these Guidelines you are welcome.
  
Line 12: Line 12:
  
 
===Methods===
 
===Methods===
 +
 +
*Make sure your methodes are always organized with descending accessors (public, protected, private)
  
 
===Getter and Setter===
 
===Getter and Setter===
Line 17: Line 19:
 
==Guideline for writing test cases==
 
==Guideline for writing test cases==
  
 
==General Requirements==
 
  
 
===Ecore models===
 
===Ecore models===
Line 25: Line 25:
 
*make sure that the gemodels default base packages matches the plugin name (without the last segment)
 
*make sure that the gemodels default base packages matches the plugin name (without the last segment)
  
==Legacy Mode==
+
===Legacy Mode===
  
 
In the CDO test suite the Legacy Mode is always activated. This means that you do not need set this mode for every test case. But this also means that you need to deactivate it if you want to execute tests without legacy.
 
In the CDO test suite the Legacy Mode is always activated. This means that you do not need set this mode for every test case. But this also means that you need to deactivate it if you want to execute tests without legacy.
  
Please always use CDOUtil.getCDOObject() and CDOUtil.getEObject() to get either the CDOObject or the expected internal instance, no matter whether you are using legacy or not. This will make the test compatible to all legacy test cases and avoids ugly ClassCastExceptions.
+
Please always use '''CDOUtil.getCDOObject()''' and '''CDOUtil.getEObject()''' to get either the CDOObject or the expected internal instance, no matter whether you are using legacy or not. This will make the test compatible to all legacy test cases and avoids ugly ClassCastExceptions.
 +
 
 +
Never retrieve any infomation from our test model packages our factories in a static way since we have two implementations for it (native and legacy). Alway use the '''getModelXXX()''' calls which ensure that the correct instance of the package or factory is loaded.
  
 
When using dynamic EObjects please do not use <b>CDOUtil.prepareDynamicEPackage(dynamicMapEPackage)</b> if you want to make this test legacy aware. Otherwise the package will be native even if the Legacy test suite is executed. Please use somtehing like the following statement to make sure that you have prepared dynamic legacy objects.
 
When using dynamic EObjects please do not use <b>CDOUtil.prepareDynamicEPackage(dynamicMapEPackage)</b> if you want to make this test legacy aware. Otherwise the package will be native even if the Legacy test suite is executed. Please use somtehing like the following statement to make sure that you have prepared dynamic legacy objects.
Line 39: Line 41:
 
}
 
}
 
</source>
 
</source>
 +
 +
===How to regenerate the test models for legacy===
 +
 +
# Generate legacy code with legacy genmodel (e.g. mango.legacy-genmodel)
 +
# Delete all Interfaces in the legacy package (Impl interfaces) BUT NOT the package and the factory
 +
# Let the legacy factory and the legacy package extend the related native interfaces (CTRL+SHIFT+O) should mostly be sufficient)
 +
# Add "legacy to the uri"
 +
# Organize imports (CTRL+SHIFT+O)
 +
# Repeat 3 und 4 for all sub packages
 +
# Take care! If your model uses inheritance of different model just must inherit from the particular Legacy object
 +
# Do the same for the impl classes
 +
# Delete Factory and Switch from legacy (optional)
 +
# Finally do "organize imports" and "source format" on the projects
 +
 +
=Plug-in Structure=
 +
 +
This section describes the internals of a CDO plug-in.
 +
 +
Since it is recommened to copy an existing plug-in to create a new one, some might find it interesting how CDO plug-ins are structured. The following sections will give you an overview about these internals.
 +
 +
==OM Activator==
 +
 +
==.cvsignore==
 +
 +
==.options==
 +
 +
==about.html==
 +
 +
==about.properties==
 +
 +
==copyright.txt==
 +
 +
=Fragment Structure=
 +
In deviation from [[#Plug-in Structure]] a fragment must contain a fragment.properties file (instead of a plugin.properties file). Otherwise the About dialog would show wrong labels because the host plugin's plugin.properties would take precedence.

Latest revision as of 03:23, 24 June 2011

Coding Guidlines

This page is not yet finished. Do not take these guidelines for granted until the note is removed!

General Coding Guidelines

The following Guide describes the basic requirements for creating CDO source code. Not all of these guidlines can be coverred by the auto-format for Java source Code (Strg+Shift+F). If you like to write an extension that allows comfortably adjusting the code regarding these Guidelines you are welcome.

Members

  • Make sure your members are always organized with descending accessors (public, protected, private).
  • Group them logically. Members that fit together should be written under each other.

Methods

  • Make sure your methodes are always organized with descending accessors (public, protected, private)

Getter and Setter

Guideline for writing test cases

Ecore models

  • if you write ecore models, make sure that your model's name matches the last segment of the plug-in name (e.g. org.eclipse.emf.cdo.dawn.examples.acore -->acore.ecore)
  • make sure that the gemodels default base packages matches the plugin name (without the last segment)

Legacy Mode

In the CDO test suite the Legacy Mode is always activated. This means that you do not need set this mode for every test case. But this also means that you need to deactivate it if you want to execute tests without legacy.

Please always use CDOUtil.getCDOObject() and CDOUtil.getEObject() to get either the CDOObject or the expected internal instance, no matter whether you are using legacy or not. This will make the test compatible to all legacy test cases and avoids ugly ClassCastExceptions.

Never retrieve any infomation from our test model packages our factories in a static way since we have two implementations for it (native and legacy). Alway use the getModelXXX() calls which ensure that the correct instance of the package or factory is loaded.

When using dynamic EObjects please do not use CDOUtil.prepareDynamicEPackage(dynamicMapEPackage) if you want to make this test legacy aware. Otherwise the package will be native even if the Legacy test suite is executed. Please use somtehing like the following statement to make sure that you have prepared dynamic legacy objects.

if(!CDOUtil.isLegacyModeDefault())
{
CDOUtil.prepareDynamicEPackage(dynamicMapEPackage);
}

How to regenerate the test models for legacy

  1. Generate legacy code with legacy genmodel (e.g. mango.legacy-genmodel)
  2. Delete all Interfaces in the legacy package (Impl interfaces) BUT NOT the package and the factory
  3. Let the legacy factory and the legacy package extend the related native interfaces (CTRL+SHIFT+O) should mostly be sufficient)
  4. Add "legacy to the uri"
  5. Organize imports (CTRL+SHIFT+O)
  6. Repeat 3 und 4 for all sub packages
  7. Take care! If your model uses inheritance of different model just must inherit from the particular Legacy object
  8. Do the same for the impl classes
  9. Delete Factory and Switch from legacy (optional)
  10. Finally do "organize imports" and "source format" on the projects

Plug-in Structure

This section describes the internals of a CDO plug-in.

Since it is recommened to copy an existing plug-in to create a new one, some might find it interesting how CDO plug-ins are structured. The following sections will give you an overview about these internals.

OM Activator

.cvsignore

.options

about.html

about.properties

copyright.txt

Fragment Structure

In deviation from #Plug-in Structure a fragment must contain a fragment.properties file (instead of a plugin.properties file). Otherwise the About dialog would show wrong labels because the host plugin's plugin.properties would take precedence.

Back to the top