Java, Eclipse Plugin Development and best software development practices
Wednesday, September 17, 2014
How to get active perspective in Eclipse
Active workbench page will have getPerspective() this will return the IPerspectiveDescriptor
IWorkbench workbench = PlatformUI.getWorkbench();
if (workbench != null) {
IWorkbenchWindow activeWorkbenchWindow = workbench.getActiveWorkbenchWindow();
if (activeWorkbenchWindow != null) {
IWorkbenchPage activePage = activeWorkbenchWindow.getActivePage();
if (activePage != null) {
IPerspectiveDescriptor perspective = activePage.getPerspective();
if (perspective != null) {
String id = perspective.getId();
//This is your active perspective
}
}
}
IWorkbench workbench = PlatformUI.getWorkbench();
if (workbench != null) {
IWorkbenchWindow activeWorkbenchWindow = workbench.getActiveWorkbenchWindow();
if (activeWorkbenchWindow != null) {
IWorkbenchPage activePage = activeWorkbenchWindow.getActivePage();
if (activePage != null) {
IPerspectiveDescriptor perspective = activePage.getPerspective();
if (perspective != null) {
String id = perspective.getId();
//This is your active perspective
}
}
}
visibleWhen on toolbar in Eclipse
I have added visibleWhen directly under toolbar, look like platform is not respecting visibleWhen for toolbar.
This is how I defined the extension:
<extension
point="org.eclipse.ui.menus">
<menuContribution
allPopups="false"
locationURI="toolbar:org.eclipse.ui.trim.vertical2">
<toolbar
id="com.kk.toolbar2"
label="Charm bar">
<command
commandId="com.kk.command.showhelp"
icon="icons/help.gif"
label="Help"
style="push">
</command>
<visibleWhen
checkEnabled="false">
<test
forcePluginActivation="true"
property="com.kk.isKKPerspective"
value="true">
</test>
</visibleWhen>
</toolbar>
</menuContribution>
</extension>
visibleWhen has no effect on toolbar
https://bugs.eclipse.org/bugs/show_bug.cgi?id=201589
Workaround for this problem is, adding visibleWhen for each command.
By adding visibleWhen on each command, toolbar is automatically getting disappeared if there are no visible elements
In my case, I want to add add a righside trim toolbar with some tool items. But I wanted to show this only in my perspective 'KKPerspective'.
<extension
point="org.eclipse.ui.menus">
<menuContribution
allPopups="false"
locationURI="toolbar:org.eclipse.ui.trim.vertical2">
<toolbar
id="com.kk.toolbar2"
label="Charm bar">
<command
commandId="com.kk.command.showhelp"
icon="icons/help.gif"
label="Help"
style="push">
<visibleWhen
checkEnabled="false">
<test
forcePluginActivation="true"
property="com.kk.isKKPerspective"
value="true">
</test>
</visibleWhen>
</command>
</toolbar>
</menuContribution>
</extension>
<extension
point="org.eclipse.core.expressions.propertyTesters">
<propertyTester
class="com.kk.KKPerspectiveTester"
id="com.kk.propertyTester2"
namespace="com.kk.propertyTester2"
properties="isKKPerspective"
type="java.lang.Object">
</propertyTester>
</extension>
This is how I defined the extension:
<extension
point="org.eclipse.ui.menus">
<menuContribution
allPopups="false"
locationURI="toolbar:org.eclipse.ui.trim.vertical2">
<toolbar
id="com.kk.toolbar2"
label="Charm bar">
<command
commandId="com.kk.command.showhelp"
icon="icons/help.gif"
label="Help"
style="push">
</command>
<visibleWhen
checkEnabled="false">
<test
forcePluginActivation="true"
property="com.kk.isKKPerspective"
value="true">
</test>
</visibleWhen>
</toolbar>
</menuContribution>
</extension>
visibleWhen has no effect on toolbar
https://bugs.eclipse.org/bugs/show_bug.cgi?id=201589
Workaround for this problem is, adding visibleWhen for each command.
By adding visibleWhen on each command, toolbar is automatically getting disappeared if there are no visible elements
In my case, I want to add add a righside trim toolbar with some tool items. But I wanted to show this only in my perspective 'KKPerspective'.
<extension
point="org.eclipse.ui.menus">
<menuContribution
allPopups="false"
locationURI="toolbar:org.eclipse.ui.trim.vertical2">
<toolbar
id="com.kk.toolbar2"
label="Charm bar">
<command
commandId="com.kk.command.showhelp"
icon="icons/help.gif"
label="Help"
style="push">
<visibleWhen
checkEnabled="false">
<test
forcePluginActivation="true"
property="com.kk.isKKPerspective"
value="true">
</test>
</visibleWhen>
</command>
</toolbar>
</menuContribution>
</extension>
<extension
point="org.eclipse.core.expressions.propertyTesters">
<propertyTester
class="com.kk.KKPerspectiveTester"
id="com.kk.propertyTester2"
namespace="com.kk.propertyTester2"
properties="isKKPerspective"
type="java.lang.Object">
</propertyTester>
</extension>
Tuesday, September 16, 2014
Conventions for naming git branches for your development
Some practices which I follow for naming git branches.
If you are working on sprint/agile development, you might have planned certain activities for each sprint.
let's say, every sprint development is for 1 month,so for every sprint we can maintain different branches as mentioned below.
Example: In Development mode
Sprint 1 => Branch name: dev-1.0.1
here, dev-<Major version>.<Minor version>.<Sprint version>
While handing over your work to QA team, we can promote this branch to QA branch.
Example: In QA mode
dev-1.0.1 will become qa-1.0.1
If you are providing builds one top of dev branches.
Example: For sprint 1 on dev branch
com.kk.product_dev-1.0.1.0.jar
Here, <pluginname>_<<branch name>.<build number>>.jar
on QA builds generation,
com.kk.product_qa-1.0.1.0.jar
If many people are working on sprint on various features, then we can create a different branch for each feature(ex: dev-1.0.1_explorer), once the feature is stabilized then we can merge this with the main sprint branch i.e dev-1.0.1
If you are working on sprint/agile development, you might have planned certain activities for each sprint.
let's say, every sprint development is for 1 month,so for every sprint we can maintain different branches as mentioned below.
Example: In Development mode
Sprint 1 => Branch name: dev-1.0.1
here, dev-<Major version>.<Minor version>.<Sprint version>
While handing over your work to QA team, we can promote this branch to QA branch.
Example: In QA mode
dev-1.0.1 will become qa-1.0.1
If you are providing builds one top of dev branches.
Example: For sprint 1 on dev branch
com.kk.product_dev-1.0.1.0.jar
Here, <pluginname>_<<branch name>.<build number>>.jar
on QA builds generation,
com.kk.product_qa-1.0.1.0.jar
If many people are working on sprint on various features, then we can create a different branch for each feature(ex: dev-1.0.1_explorer), once the feature is stabilized then we can merge this with the main sprint branch i.e dev-1.0.1
Monday, September 15, 2014
Eclipse Plugin name and package name conventions
I will follow below conventions for naming any new plug-in which I am contributing.
Plug-in names should follow the standard Eclipse Naming conventions. That means that,
(i) The project name on disk(Plug-in name) is the same as the plug-in id and
(ii) Plug-in packages should start with plug-in name.
(iii) Don’t mix generated code plug-in and implementation plugins
com.kk.studio.<component name>
com.kk.studio.<major component name>.<minor component name>
Examples:
com.kk.studio.sky => Implemented code plug-in
com.kk.studio.sky.model => EMF model based generated code plug-in
Package Names:
com.kk.studio.sky => Plug-in name/Plug-in id
com.kk.studio.sky
com.kk.studio.sky.explorer
com.kk.studio.sky.explorer.model
com.kk.studio.sky.explorer.view
com.kk.studio.sky.explorer.view.actions
com.kk.studio.sky.explorer.view.dialogs
com.kk.studio.sky.explorer.view.dialogs.data
com.kk.studio.sky.explorer.view.providers
com.kk.studio.sky.i18n
com.kk.studio.sky.util
Eclipse Resources:
http://wiki.eclipse.org/Development_Resources/HOWTO/Project_Naming_Policy
http://wiki.eclipse.org/index.php/Naming_Conventions#Eclipse_Workspace_Projects
Plug-in names should follow the standard Eclipse Naming conventions. That means that,
(i) The project name on disk(Plug-in name) is the same as the plug-in id and
(ii) Plug-in packages should start with plug-in name.
(iii) Don’t mix generated code plug-in and implementation plugins
com.kk.studio.<component name>
com.kk.studio.<major component name>.<minor component name>
Examples:
com.kk.studio.sky => Implemented code plug-in
com.kk.studio.sky.model => EMF model based generated code plug-in
Package Names:
com.kk.studio.sky => Plug-in name/Plug-in id
com.kk.studio.sky
com.kk.studio.sky.explorer
com.kk.studio.sky.explorer.model
com.kk.studio.sky.explorer.view
com.kk.studio.sky.explorer.view.actions
com.kk.studio.sky.explorer.view.dialogs
com.kk.studio.sky.explorer.view.dialogs.data
com.kk.studio.sky.explorer.view.providers
com.kk.studio.sky.i18n
com.kk.studio.sky.util
Eclipse Resources:
http://wiki.eclipse.org/Development_Resources/HOWTO/Project_Naming_Policy
http://wiki.eclipse.org/index.php/Naming_Conventions#Eclipse_Workspace_Projects
java.lang.OutOfMemoryError: unable to create new native thread
One of the developer reported "java.lang.OutOfMemoryError: unable to create new native thread" while working with eclipse on his application.
Below is the error log.
java.lang.OutOfMemoryError: unable to create new native
thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at java.lang.ref.Finalizer$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.ref.Finalizer.forkSecondaryFinalizer(Unknown Source)
at java.lang.ref.Finalizer.runFinalization(Unknown Source)
at java.lang.Runtime.runFinalization0(Native Method)
at java.lang.Runtime.runFinalization(Unknown Source)
at java.lang.System.runFinalization(Unknown Source)
at org.eclipse.ui.internal.ide.application.IDEIdleHelper$3.run(IDEIdleHelper.java:182)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
This is what i can think why he encountered with this issue.
User is running on 32 bit machine with
Since he is running on 32 bit machine, you need to allocate –Xmx and -XX:PermSize carefully. Since 32 bit machines can address maximum of 4GB address space.
Since we allocated -Xmx is 1024m and -XX:PermSize is 512m, there is very less space is remaining to create a new Java native threads by OS.
To make it work, reduce -XX:PermSize to 256m and –Xmx to 512m(unless 1024 is required).
Expanding a trim view Vertically in programmatic way in Eclipse e4
Generally, If you have minimized a view, It will go and add it to the trimbar as shown on the left hand side.
If you click on tool item from the trimbar, it will show as a fast view. Means, It won't expand completely either in horizontally or vertically. But, user can do this by changing the orientation as show on the image.
To achieve this programmatically, we have to use Eclipse e4 workbench presentation engine component
For Vertically:
IPresentationEngine.ORIENTATION_VERTICAL
For Horizontal:
IPresentationEngine.ORIENTATION_HORIZONTAL
WorkbenchPartReference myView = page.findViewReference("myviewid");
MUIElement element = ((WorkbenchPage) page).getActiveElement(myView);
WorkbenchWindow activeWorkbenchWindow = (WorkbenchWindow) PlatformUI.getWorkbench().getActiveWorkbenchWindow();
if (activeWorkbenchWindow != null) {
MWindow window = activeWorkbenchWindow.getModel();
if (window != null) {
EModelService modelService = window.getContext().get(EModelService.class);
if (modelService != null) {
element.getTags().add(IPresentationEngine.ORIENTATION_VERTICAL);
}
}
}
By adding a element tag sets the behaviour for a particular element.
From Eclipse, "This tag can be applied to an element as a hint to the renderers that the element would prefer to be vertical. For an MPart this could be used both as a hint to how to show the view when it's in the trim but could also be used when picking a stack to add a newly opening part to. It could also be used for example to control where the tabs appear on an MPartStack."
If you click on tool item from the trimbar, it will show as a fast view. Means, It won't expand completely either in horizontally or vertically. But, user can do this by changing the orientation as show on the image.
To achieve this programmatically, we have to use Eclipse e4 workbench presentation engine component
For Vertically:
IPresentationEngine.ORIENTATION_VERTICAL
For Horizontal:
IPresentationEngine.ORIENTATION_HORIZONTAL
WorkbenchPartReference myView = page.findViewReference("myviewid");
MUIElement element = ((WorkbenchPage) page).getActiveElement(myView);
WorkbenchWindow activeWorkbenchWindow = (WorkbenchWindow) PlatformUI.getWorkbench().getActiveWorkbenchWindow();
if (activeWorkbenchWindow != null) {
MWindow window = activeWorkbenchWindow.getModel();
if (window != null) {
EModelService modelService = window.getContext().get(EModelService.class);
if (modelService != null) {
element.getTags().add(IPresentationEngine.ORIENTATION_VERTICAL);
}
}
}
By adding a element tag sets the behaviour for a particular element.
From Eclipse, "This tag can be applied to an element as a hint to the renderers that the element would prefer to be vertical. For an MPart this could be used both as a hint to how to show the view when it's in the trim but could also be used when picking a stack to add a newly opening part to. It could also be used for example to control where the tabs appear on an MPartStack."
Subscribe to:
Posts (Atom)