Wednesday, May 28, 2008

Eclipse Monkey - Extension Points it is

For the new Eclipse Monkey I was considering use of Declarative Services in OSGi since I was intending to allow at least the core set of plugins to be able to used within the context of just a OSGi container. I have decided to use extension points based on my research of the past couple of days.

Neil Bartlett has an excellent writeup of extension points versus OSGi services: http://neilbartlett.name/downloads/extensions_vs_services.pdf

My number one concern was allowing people using Equinox, Knopflerfish(really what a name right?), Apache Felix, or other OSGi container could leverage the basic ability to write scripts. This concern addressed by the fact that bundles working in the context of a pure OSGi container only has to add the following two Eclipse Equinox bundles: org.eclipse.equinox.registry and org.eclipse.equinox.common. I don't think this is a bad trade-off because of the following considerations: dynamic bundles and tooling.

The first consideration is dynamism of bundles, whether they can be hot swapped in or out. This is the number one reason to use OSGi Declarative Services, it is made to work with the fact that bundles could come up or down. I don't think this will be a major concern for monkey, extensions will be things like definitions of script metadata elements, DOM objects, etc... These are things where dynamic hot swapping of bundles is not really beneficial. Besides I always prefer to ask the Extension Registry for the list of available extensions and not cache them. Without caching references from extensions, the code will already allow for dynamic hot swapping. If performance becomes a major issue, well that is what the ExtensionTracker is for.

The second consideration is a major one for me. There is some tooling in Eclipse within the PDE for extensions. Actually there is a lot of tooling. Tooling support for OSGi services, much less Declarative Services, is pretty much non-existent.

So given the thought process outlined here, I think Eclipse Monkey is safe sticking with extension points. As long as there is an Eclipse, it will have to support Extension Points and Extensions. If there is no Eclipse, well there is no Monkey either right?

P.S.: During my research on this I have to say I was impressed with the Knopflerfish site and its Eclipse plugin. I was also almost impressed with the Ops4J Pax Cursor. Honestly, is it so hard to integrate with the PDE Knopflerfish developers? I mean do you need to create your own builder and nature? You guys are almost there, just hook into the PDE and provide an Eclipse recognizable Target Platform. That is it, a few days work maybe, and then voila your stuff will work and all the PDE tooling will work for you. Same complaint with the Pax Cursor people, y'all are further along than the Knopflerfish people in that you not only support multiple OSGi containers and integrate better with the Eclipse PDE, but could I just get an Eclipse recognizable Target Platform? I mean y'all are just one little step away. Get Chris Aniszczyk(I take back what I said about Knopflerfish's name earlier) or someone else on the PDE team to point you to how to address the last hurdle. I mean guys, what better way to get some Java developers(in particular Eclipse Plugin developers) to try out your stuff. Also I should not just beat up on the Knopflerfish and Pax Cursor guys, I mean are you listening Eclipse PDE people? Its great you can run your bundles on a launch configuration that says OSGi container, but is it really that cool given that the only container that works out of the box is the Equinox one?? I have worked with some of those containers in the past and I know this aint rocket science. Why don't I do it? As my grandmother used to say, "If wishes were horses, beggars would ride." My interests right now lie elsewhere.

4 comments:

YuanYun.Kenny.CN said...

Hi, Eclipse monkey looks very interesting and useful.
Thanks for the innovation.
For me, the most exciting thing is that we can use the Key keyword to add hotkey shortcuts, and use the onLoad keyword to have our script run on startup.
My question is that whether we can use third-party jars directly, but don't need import them as eclipse plugins?
Or we can use our java classes in monkey scripts?
Any help and reply are welcome. And please forgive my foolishness question.

James E. Ervin, IV said...

There are foolish questions, but yours was not one of them. I think that a Key option for the script would not be a bad idea, right now Groovy monkey does not contain that. The onLoad option would be something else to consider as well.

Groovy Monkey, which is the basis for future Eclipse Monkey work, already allows you to add jars from your workspace via the Include directive. You can also add folders in the workspace, which can enable use of compiled java classes in the script. So the short answer is yes it can.

YuanYun.Kenny.CN said...

Hi, James:
Thanks for your kindly reply. And I have already had some basically understanding of groovy monkey.
It is very cool.
Btw, Where can I download the source code of groovy monkey?
And how can I schedule groovy monkey scripts to run automatically and periodically?
Or can groovy monkey kindly provide such functionality in future?

James E. Ervin, IV said...

Well the source code is available from the Groovy Monkey sourceforge site. The url for the svn repository:

http://groovy-monkey.sourceforge.net/svnroot/groovy-monkey

All of the source is available there. As far as your other question, I have had the thought to add a cron like utility, but I haven't gotten around to doing it. I think it would make sense going forward.