Code snippet:

URI resolvedFile = CommonPlugin.resolve(uri);
String fileString = resolvedFile.toFileString();
File file = new File(fileString);

Thats it. You have got the File now.

org.eclipse.emf.common.CommonPlugin - Include this in your import and manifest.

Code Snippets which is used to convert a text file inside a Eclipse RCP to a String.

Create a PluginResourceToString object and make a call to convertToString method with the filePath as the argument.

If in your plugin, resources is the directory containing text files to be read, and if the name of the text file is example.text. The parameter should be resources/example.text. Make sure that you are including the resources in build.properties file.

Related web links:

1. StackOverFlow - Simplest way to read a file in to string
2. StackOverFlow - Convert InputStream in to String

Simple way to create RCP Headless application is to define Trimmed window in the application model and making it as non visible / non to be rendered.

If made non visible, there will be no window launched and application will continue to run in the background. Only way to close application is to kill (If you don't run it with -consoleLog).

If made not to be rendered, application will run the code and simply exits. Be careful to use event based mechanisms in this case as application may not wait till the time event is received.

Though we do the above points, creating a pure Eclipse E4 based RCP headless (command line) application is not possible without modifying/adding to the Eclipse framework. This I conclude after serching in the Internet (Google, Stackoverflow) and conversing with Vogella,

Reasons are

1. Eclipse E4 model is basically for UI applications. All the elements that you find in the model are for UI.
2. Binding context, Part, PartStack, Trimmed windows, Controls - Everything is for UI.
3. If Trimmed windows are not defined, Eclipse framework throws exception and exits. 

Another reason why it is not pure command line application is that, we can see that model defining plugins depend on e4.ui plugins which are part of the framework.

The general requirements of a console / headless/ command line application are

1. There should not be any other UI elements loaded
2. In some cases, the requirement is that the application should be able to take the user input via the console / command line and prints the output to the same console (Logging).
3. Application should be able to have a nicer termination mechanism (either by closing the command line shell that opened the application, by pressing CTRL + C, CTRL + /, CTRL + D, CTRL + Q etc) instead of killing it.

With Eclipse E4, out of the above requirements, first one is achievable. Second and third are partially achievable (provided one develops the application without changes to the E4 framework).

Ok, so how do we develop an E4 based console application 

1. We need to have a product defining plugin, defining a product. We will have to use this product in our product configuration file. This is irrespective of whether we have normal eclipse application or E4 based one. We anyhow need to mention the startup plugin by this way.
2. Once we define the product, next step is to either to use the default E4 application, org.eclipse.e4.ui.workbench.swt.E4application or to define our own application (by defining extension point org.eclipse.core.runtime.applications, but here you need to define Application, ApplicationWorkBenchAdvisor and call PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor()); This is because, E4 model is loaded only when work bench is created. This is also reason that we never can build a pure console only application using Eclipse E4).
3. We need to add the E4 application model to our project like we do with any other E4 development.
4. In the application model, we define a trimmed window and we have to simply make it invisible (to make the application run in the background, in this case, add -consoleLog while running the application) or not to be rendered (to make the application exit after finishing the job, in this case usage of event mechanism have to be carefully handled).

Logging: 

Inside Eclipse IDE, we have the standard console window that will print whatever the code prints to stdout. But when we build the product using maven-tycho or PDE, we have to ensure that we are making the product build based on java.exe instead of javaw.exe (the eclipse.exe is based on javaw.exe). The reason is that javaw.exe has no console. i.e. stdout in javaw.exe is set to null.

While tycho has its own builder to build based on eclipse.exe, PDE build has options to set java.exe as the base for product build (I am not sure how to do that though)

There is a eclipsec.exe which is also based on javaw.exe but has a console. But you cannot by default do the branding in the product configuration file. May be launch4j can be used to brand the eclipsec.exe according to project needs. Also note that eclipsec.exe is only for Windows platform.

But while using javaw.exe (eclipse.exe), the option -consoleLog when passed will open the new console. We can get the output to the new console but not to the same console. Still figuring out how to output to the same console).

The plugins that provide common annotations for DI (Dependency Annotations) in Eclipse E4 are

javax.inject
javax.annotation
org.eclipse.e4.core.di
org.eclipse.e4.ui.services

The common annotations are

@Inject
@PostConstruct
@PreDestroy
@Optional
@Named
@Creatable

The common Interfaces and Constants are present in interface IServiceConstants.

Usage and Explanations:

@Inject - Used for Injecting the value which the framework has. Developer needs to ensure that the injected object instance is already present with the framework

class Employee {
    String name;
    String address;
    @Inject EmployeeDB database;

    @Inject
    public void setEmployeeDetailsFromUI(MPart part) {
           //Some code here
    }
}

@PostConstruct - Method annotated with this one are called after an object instance is created. Typically useful as an entry method for a part instance where developers can start creating the controls.

@PreDestroy - Method annotated with this one are called before the object is destroyed.

@Optional - Conveys to the framework that this variable is passed with the value only if the framework has the value else framework can pass null to the variable. Can be used as parameter to a method or as a field.

@Named - Can be paired with other annotations and meaning is that, the annotation is valid for the string passed with the @Named

@Creatable - Framework creates the class (if all attributes are creatable) and is injected.

The objects are looked up in the contexts that are made available by the framework. If the objects are available in the context, they are injected.

The framework start to look for the object for injection in the following order.

Part
Perspective
Window
Workbench
OSGi

Inorder to make that a class is present with the annotation, it has be either directly injected  (in this case, the framework will look for the dependencies and does injection for the dependencies as well) or connected to the application model which the framework will parse.

Like wise when connected to the application model or manually mentioned, the methods can be annotated to listen for specific events.

Reference: http://eclipsesource.com/blogs/tutorials/eclipse-4-e4-tutorial-part-4-dependency-injection-basics/
Annotations: http://eclipsesource.com/blogs/tutorials/eclipse-4-e4-tutorial-part-6-behavior-annotations/

Peer code reviews will help a lot during coding stage to ensure the correctness of the code.

We know that doing smaller commits will minimize the bugs.

Combining the above two will really help to have a better code.

Following can be a tip to do a peer code review if you use Git.

1. Developer does a rebase and do a smaller commit.
2. Developer creates patch with git format-patch -1 (sha of commit)
3. Developer emails the patch with rebase line info !!!
4. Reviewer rebase to the same line
5. Reviewer applies the patch
6. Reviewer uses git difftool to review and mentions that as comment in the code area with //TODO
7. Reviewer creates patch and sends as mail to the developer.

  

If you dont have any other review system, this may help.

Given two different SHAs (Commit Ids), you might want to view the difference between them and compare.

You can do this by

git difftool

The above will launch the difftool for each file in sha1 and sha2.

If you want to view only the file names,

git diff --name-only

Reference: StackOverflow

You many want to create a new local branch and track the remote branch.

You can do this by

git branch --track  

Where is the complete path of remote branch including remotes/origin/...