Wednesday, December 9, 2015

Git: Reverting multiple bad commits which are already pushed to a central repository

Here is the case:
I pushed multiple bad commits into a central repository and now I wanted to roll back all of them.

Step1 : check git log and identify your last good commit or till where you wanted to roll back.
$ git log --oneline
5ff2aee commit1 - bad commit
8516637 commit2- bad commit
64db1b7 commit3 - bad commit
6897d4b commit4 - bad commit
6974cb5 commit5 - this is my last good commit
79e63c6 commit6
6cd2939 commit7
d39ae18 commit8

Step2: Do reset hard till your last good commit.
$ git reset --hard 6974cb5

Step3: verify git log
$ git log --oneline
6974cb5 commit5 - this is my last good commit
79e63c6 commit6
6cd2939 commit7
d39ae18 commit8

Step 4: Do force push to central repo
$ git push origin <master repo> -f




Preferences sharing across all workspaces - Handling programatically

To share preferences across all workspaces in eclipse, you need to save preferences via ConfigurationScope.

What is configuration scope ?

Preferences stored in this scope are shared by all workspaces that are launched using a particular configuration of Eclipse plug-ins. On a single-user installation, this serves to capture preferences that are common to all workspaces launched by that user. On a multi-user installation, these preferences are shared by all users of the configuration.

How to save ?

IEclipsePreferences store = ConfigurationScope.INSTANCE.getNode(MyUIPlugin.PLUGIN_ID);
if (store != null)
{
store.putBoolean(MyFLAG_PREF, true);
try
{
store.flush();
}
catch (BackingStoreException e)
{
//Log exception
}
}


How to retrieve the saved preference value?

boolean isSet = Platform.getPreferencesService().getBoolean(MyUIPlugin.PLUGIN_ID,
MyFLAG_PREF, false, new IScopeContext[] { ConfigurationScope.INSTANCE });


Understand more about preference scopes:


Eclipse tips and tricks

Managing eclipse global preferences / eclipse installation level preferences

Where are the global preferences stored for eclipse? 
 eclipse\configuration\.settings folder

Here some plugins store their global preferences. For example: the recent workspace settings are in org.eclipse.ui.ide.prefs.

MAX_RECENT_WORKSPACES=5
RECENT_WORKSPACES=/Users/kondalkolipaka/development/workspaces/devbranch2\n/Users/kondalkolipaka/development/workspaces/devbranch
RECENT_WORKSPACES_PROTOCOL=3
SHOW_WORKSPACE_SELECTION_DIALOG=true
eclipse.preferences.version=1

Same way you can store your plugin global preferences in your own file.

Take a look at this.
http://mcuoneclipse.com/2012/04/06/eclipse-global-preferences/

Tuesday, December 8, 2015

Suppress warnings for non-nls string literals

@SuppressWarnings("nls") suppress warnings relative to non-nls string literals

Example:
@SuppressWarnings("nls")
private static final String[] PLATFORMS = { "iphone", "ipad", "windows", "android" };


Complete list:


The list of tokens that can be used inside a SuppressWarnings annotation is:
  • all to suppress all warnings
  • boxing to suppress warnings relative to boxing/unboxing operations
  • cast to suppress warnings relative to cast operations
  • dep-ann to suppress warnings relative to deprecated annotation
  • deprecation to suppress warnings relative to deprecation
  • fallthrough to suppress warnings relative to missing breaks in switch statements
  • finally to suppress warnings relative to finally block that don't return
  • hiding to suppress warnings relative to locals that hide variable
  • incomplete-switch to suppress warnings relative to missing entries in a switch statement (enum case)
  • javadoc to suppress warnings relative to javadoc warnings
  • nls to suppress warnings relative to non-nls string literals
  • null to suppress warnings relative to null analysis
  • rawtypes to suppress warnings relative to usage of raw types
  • resource to suppress warnings relative to usage of resources of type Closeable
  • restriction to suppress warnings relative to usage of discouraged or forbidden references
  • serial to suppress warnings relative to missing serialVersionUID field for a serializable class
  • static-access to suppress warnings relative to incorrect static access
  • static-method to suppress warnings relative to methods that could be declared as static
  • super to suppress warnings relative to overriding a method without super invocations
  • synthetic-access to suppress warnings relative to unoptimized access from inner classes
  • sync-override to suppress warnings because of missing synchronize when overriding a synchronized method
  • unchecked to suppress warnings relative to unchecked operations
  • unqualified-field-access to suppress warnings relative to field access unqualified
  • unused to suppress warnings relative to unused code and dead code

Sunday, December 6, 2015

Fragments in OSGI - Eclipse


A Bundle fragment, or simply a fragment, is a bundle whose contents are made available to another bundle (the fragment host). Importantly, fragments share the classloader of their parent bundle. One notable difference is that fragments do not participate in the lifecycle of the bundle, and therefore cannot have an Bundle-Activator.


Example:
These are 2 plugins which does not have any activator classes.
org.eclipse.epp.logging.aeri.ui
org.eclipse.epp.logging.aeri.ide - Host Plugin

And, In org.eclipse.epp.logging.aeri.ide plugin MANIFEST.MF file, you can find below section:
Fragment-Host: org.eclipse.epp.logging.aeri.ui;bundle-version="1.0.0"


At runtime the fragment is merged with its host plug-in and for the runtime both projects are just one. Fragments are always optional for their host plug-in and the host plug-in doesn't even know that it exists.

Thursday, December 3, 2015

"No repository found containing: osgi.bundle" error message during the Eclipse udpate

Below trick helped me to resolve the problem.

Help>Install new software>Uncheck "Contact all update sites during install to find required software"