I came across a video talk from Yochai Benkler about the next step in human organization: open collaborative projects. He mentions Wikipedia as an example, but I would like to include Eclipse as well.
You can find the full talk in TED.com.
Monday, July 21, 2008
Wednesday, July 16, 2008
Demo for Ganymede's security
Hi All,
Security is one of the features I was waiting to see in Eclipse and I am glad that Ganymede comes with it.
I found a good introductory demo in Eclipse Live that explains the new security features: http://live.eclipse.org/node/565. The demo is pretty clear and gives an overview of how security works in Ganymede. Don't forget to visit Equinox Security website for more info.
<>
Security is one of the features I was waiting to see in Eclipse and I am glad that Ganymede comes with it.
I found a good introductory demo in Eclipse Live that explains the new security features: http://live.eclipse.org/node/565. The demo is pretty clear and gives an overview of how security works in Ganymede. Don't forget to visit Equinox Security website for more info.
<>
Friday, July 11, 2008
org.eclipse.ui.menus
Recently I’ve been guiding our off-shore team on moving our pop-up menu actions from using org.eclipse.ui.popupMenus extension point to a newer mechanism. Eclipse 3.3 provides a new mechanism, a lot easier to use, through the org.eclipse.ui.menus extension point. This extension point adds UI contributions to the main menu, main toolbars, view menus, view toolbars, context menus, etc. and replaces the following (legacy) extension points: org.eclipse.ui.ActionSets, org.eclipse.ui.EditorActions, org.eclipse.ui.popupMenus (including 'objectContributions') and org.eclipse.ui.viewActions.
Below is a summary of the steps for migrating to the new mechanism. Since there are a number of pop-up items, the migration converts one action at a time. Here are the steps:
1) Contribute a command using org.eclipse.ui.commands extension point.
2) Refactor the action delegate class to a handler delegate class.
3) Contribute the converted handler class using org.eclipse.ui.handlers extension point and specifying the command from step 1).
4) Then, add the command to your particular menu using org.eclipse.ui.menus. Here the trick is specifying the locationURI. For example: locationURI="menu:org.eclipse.ui.main.menu?after=additions" adds a command to the main menu and locationURI="toolbar:org.eclipse.ui.main.toolbar?after=additions" add a command to the main toolbar.
The org.eclipse.core.commands.ExecutionEvent in the new handler’s execute(ExecutionEvent) method can be passed to class org.eclipse.ui.handlers.HandlerUtil. HandlerUtil provides static methods for obtaining the context when the command is executed, such as the shell, active editors, parts, menus, etc.
After testing the conversion of the old actions to the new mechanism, the next step may be adding key bindings by extending org.eclipse.ui.bindings. Remember to specify a sequence that has not been bound already.
Another consideration is enablement, as some commands may not be available all the time. Method isEnabled() in the new handler may be overridden, but when this method is called it is not possible to obtain the active editor. In cases when the user enables or disables the action through a preference page, method isEnabled() may be used. An approach to enablement is as follows:
1) Create a property tester using org.eclipse.core.expressions.propertyTesters extension point
2) Add the clause enabledWhen in org.eclipse.ui.handlers extension point and test for the above property, for example:
... inside a given extension point
...
May be used for testing that a selection (like a resource) has a particular property, that is command may applied to the selection.
At this point, the conversion should have gone fine. I hope this post helps you as a reference.
Until next…
Below is a summary of the steps for migrating to the new mechanism. Since there are a number of pop-up items, the migration converts one action at a time. Here are the steps:
1) Contribute a command using org.eclipse.ui.commands extension point.
2) Refactor the action delegate class to a handler delegate class.
3) Contribute the converted handler class using org.eclipse.ui.handlers extension point and specifying the command from step 1).
4) Then, add the command to your particular menu using org.eclipse.ui.menus. Here the trick is specifying the locationURI. For example: locationURI="menu:org.eclipse.ui.main.menu?after=additions" adds a command to the main menu and locationURI="toolbar:org.eclipse.ui.main.toolbar?after=additions" add a command to the main toolbar.
The org.eclipse.core.commands.ExecutionEvent in the new handler’s execute(ExecutionEvent) method can be passed to class org.eclipse.ui.handlers.HandlerUtil. HandlerUtil provides static methods for obtaining the context when the command is executed, such as the shell, active editors, parts, menus, etc.
After testing the conversion of the old actions to the new mechanism, the next step may be adding key bindings by extending org.eclipse.ui.bindings. Remember to specify a sequence that has not been bound already.
Another consideration is enablement, as some commands may not be available all the time. Method isEnabled() in the new handler may be overridden, but when this method is called it is not possible to obtain the active editor. In cases when the user enables or disables the action through a preference page, method isEnabled() may be used. An approach to enablement is as follows:
1) Create a property tester using org.eclipse.core.expressions.propertyTesters extension point
2) Add the clause enabledWhen in org.eclipse.ui.handlers extension point and test for the above property, for example:
... inside a given extension point
...
May be used for testing that a selection (like a resource) has a particular property, that is command may applied to the selection.
At this point, the conversion should have gone fine. I hope this post helps you as a reference.
Until next…
Friday, July 4, 2008
Ganymede
For the past couple of days, I've been trying Ganymede, the new Eclipse 3.4. So far, there are good things that I like, but there is one issue that made me go back to 3.3. First, the good things.
One of the nice features is an improved Javadoc hover. As a plugin developer, this feature has provided me with better access to Eclipse API. Also, the Javadoc hover shows the value of constants, but this shows how the constant is initialized, not its runtime value.
Another feature I like is marking read and write occurrances, giving a hint of where variables are being modified or just read.
The issue I am experiencing is with my Java EE environment. I tried to migrate my workspace from Eclipse 3.3 to Eclipse 3.4 and got the following errors in one of my "ear" projects:
- "IWAE0053E An internal error has occurred running validation on project:TheProjectEar]:TheProjectEar, check the log file for details"
Followed by errors like these:
- "The deployment descriptor of the module 'TheProjectEjb.jar' cannot be loaded."
- "The deployment descriptor of the module 'WebTheProject.war' cannot be loaded."
I haven't found a solution or an explanation yet, however when I switch back to Eclipse 3.3, I don't see this error anymore. As soon as I find what the problem is, I'll post my findings.
Until next...
One of the nice features is an improved Javadoc hover. As a plugin developer, this feature has provided me with better access to Eclipse API. Also, the Javadoc hover shows the value of constants, but this shows how the constant is initialized, not its runtime value.
Another feature I like is marking read and write occurrances, giving a hint of where variables are being modified or just read.
The issue I am experiencing is with my Java EE environment. I tried to migrate my workspace from Eclipse 3.3 to Eclipse 3.4 and got the following errors in one of my "ear" projects:
- "IWAE0053E An internal error has occurred running validation on project:TheProjectEar]:TheProjectEar, check the log file for details"
Followed by errors like these:
- "The deployment descriptor of the module 'TheProjectEjb.jar' cannot be loaded."
- "The deployment descriptor of the module 'WebTheProject.war' cannot be loaded."
I haven't found a solution or an explanation yet, however when I switch back to Eclipse 3.3, I don't see this error anymore. As soon as I find what the problem is, I'll post my findings.
Until next...
Hola
This is not my first blog, but the one I had before (Yahoo 360) wasn't visible through a Google search and I stopped updating it.
I am a software developer with experience in plug-in development using the Eclipse platform and Java EE. Also, I have special interest in software improvement, coding standards, techniques for improving development, etc. My intention is to share my knowledge and thoughts through this blog.
Hope you find it helpful.
I am a software developer with experience in plug-in development using the Eclipse platform and Java EE. Also, I have special interest in software improvement, coding standards, techniques for improving development, etc. My intention is to share my knowledge and thoughts through this blog.
Hope you find it helpful.
Subscribe to:
Posts (Atom)