Things to remember when contributing code to jdt ui:

- legal issues: all code/icons/doc etc. that is _not_ authored by the contributor should be 
  indicated as such. we then need PMC approval, about.html etc. Ideally, there's no third-party code in the contribution.
   
- all files must have appropriate copyright notices, indicating the original contributor
  The triggering bug report number is good to have, for easier tracking.
   
- code has to adhere to jdt ui's naming convention and honor our style conventions, like compact assignments

- the contributor should write junit test cases and contribute them as well

- for new views: all 1-view specific settings should be located as close to the view as possible. Often, 
the view's dropdown menu (the triangle) is the right place.

- for new views: adapters should be used, and standard jdt ui actions groups (ccp, source, refactor etc) added.

- exceptions should be handled by using JavaPlugin or ExceptionHandler classes

- general: no RuntimeExceptions or Errors should be caught in the code

- in general, code should adhere to our 'endgame' standards: 
   --no calls to System.out.println 
   --no use of internal API
   --no illegal subclassing of API classes

   --no unused imports [compiler opt], 
   --no unused private members [compiler opt], 
   --no ignored exceptions [compiler opt],
   --no non-nls strings [compiler opt],
   --no use of deprecated API [compiler opt]
   --no methods with constructor name [compiler opt]
   --no static references made in a non-static way [compiler opt]
   --no 'methods overriden but package visible' [compiler opt]
   --no hidden catch blocks [compiler opt]
   --no-op assignments [compiler opt]
   --no unreachable code [compiler opt]
   --no unresolved imports [compiler opt]
   --etc.

- all translatable strings should be externalized - also plugin.xml
(note that .properties files should include copyright notices as well)

- all actions, views, dialogs should have help context ids and register them

- key bindings should not be hard-coded (by KeyListeners) - instead, the platform mechanism should be used

- when appropriate, IJavaElements should be displays using JavaElementLabel provider. That way, they look consistent.

- all menu entries, labels in dialogs etc should have unique mnemonics

- all menu entries, toolbar tooltips, etc should use chapter capitalization 
(note that it's OK to capitalize a short word if it's the last in the label)


Dumping some general Issues:
- don't submit a patch that has any warning (We have the rule that if we touch a file that has warnings, we also go and fix those, even if not created by us)
- make sure your code is formatted
	- this should happen automatically if you use save actions
	- example of wrong formatting: if (!<space>condition)
	- however: do not format the whole file - only format the code you add or touch
- labels:
	- must have mnemonic (use same if used in same button elsewhere if possible)
	- never use (s) but have both forms, e.g. working set and working sets
	- if only one, then show the name, e.g. delete working set 'foo'
	- use single quotes when displaying a UI element
	- never put UI strings into code: they must be externalized
	- enable spell checking so you don't have typos like 'Dont'