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.
Wednesday, May 28, 2008
Monday, May 26, 2008
Eclipse Monkey - Core design notes
I am currently working on the new Eclipse monkey, starting this week. You know it is amazing how much time unemployment can free up for you or, er, contract sabbatical. I will make available a temporary public repository when I have something to show for this. I am always open to comments. I am writing this blog entry in order to state what are the design goals for this version of monkey, in particular the core plugin.
In many ways it is very very tempting to just take Groovy Monkey, rename a few packages and classes and then voila, here is the new Eclipse Monkey. There would be nothing wrong with that, I am after all proud of Groovy Monkey, its simple and it works. Still I would be remiss if I did not take advantage of this natural break to consider some refactoring and or redesign.
The main consideration I wish to take into account for the new version of Eclipse Monkey is to make it more modular. What I mean by that, is that I wish it to be possible to use monkey across the full spectrum of the Eclipse platform. Now what does that mean? I think I would be best able to explain it in terms of goals. It is a goal to allow people developing using just an OSGi container to be able to leverage some useful subset of Eclipse Monkey functionality in their applications. Allowing a bundle developer to be able to run scripts embedded in a bundle, specified via a URI/URL or specified directly in a string. Another goal would be to allow that core functionality plus some additional support to be used by a developer of Eclipse RCP applications. At the RCP level, there is now the notion of a workspace, SWT/JFace UI API and Eclipse jobs, so the monkey functionality to support that should be available. The same idea would apply to Eclipse Platform, JDT and finally the PDE (which would constitute the full Eclipse SDK).
There are some consequences of these decisions. There will be more bundles/fragments than would be otherwise, but at least those components should be simpler and smaller in size. I will focus on those that deal with the new org.eclipse.monkey.core component, which will run in the base OSGi container only.
We will have to consider OSGi services (perhaps declarative services), since we are missing Eclipse extension points for one. This will be decidedly different from Groovy Monkey where language extensions and DOM(s) are specified via extension points. Hopefully this will be possible without too much difficulty, also consideration will be made to allow parallel extension points, since the PDE support for extension points is much further along than with OSGi services. Of course allowing for parallel definitions, we will hopefully not have too many headaches with monkey bundle developers trying to define their extensions as both OSGi services and Eclipse defined extension points.
Another consequence of the OSGI only approach is that there will be no IResources API, so there will need to be support for allowing scripts to be embedded in a bundle, located via URI/URL or even to allow script text to be taken in verbatim. This will be a significant difference from Groovy Monkey where everything is assumed to be a resource in the workspace.
Finally, another major impact of this choice, will be the fact that support for threading through the Eclipse Jobs API will not be available. This in and of itself also makes me want to abandon the OSGi only approach. This means that use of IWorkspaceRunnable and Eclipse Jobs will commence only when the org.eclipse.core.runtime bundle is available.
There are two other things that this line of thinking has led me to consider. One, the metadata keywords and definitions should be pluggable themselves. As of right now in Groovy Monkey the script metadata is pretty statically defined in the code for the core plugin. If the layering support is to work, they have to be plugged by different plugins/fragments depending on the framework that monkey is being run in. Second, probably need a way to define which bundles are required or which platform the script is meant to run against. For instance, putting in a Job definition for a script running in an OSGi container is nonsense, however once in the RCP level, it is required. I think that there should be probably hardcoded values: OSGi, RSP, RCP, Platform, JDT and PDE. RSP would be the OSGi container plus the org.eclipse.core.runtime and org.eclipse.core.resources plugins, but no UI support.
Finally, all this work has to be done with the idea of backwards compatibility in mind. Hey I have written lots of monkey scripts I don't wanna throw away either.
In many ways it is very very tempting to just take Groovy Monkey, rename a few packages and classes and then voila, here is the new Eclipse Monkey. There would be nothing wrong with that, I am after all proud of Groovy Monkey, its simple and it works. Still I would be remiss if I did not take advantage of this natural break to consider some refactoring and or redesign.
The main consideration I wish to take into account for the new version of Eclipse Monkey is to make it more modular. What I mean by that, is that I wish it to be possible to use monkey across the full spectrum of the Eclipse platform. Now what does that mean? I think I would be best able to explain it in terms of goals. It is a goal to allow people developing using just an OSGi container to be able to leverage some useful subset of Eclipse Monkey functionality in their applications. Allowing a bundle developer to be able to run scripts embedded in a bundle, specified via a URI/URL or specified directly in a string. Another goal would be to allow that core functionality plus some additional support to be used by a developer of Eclipse RCP applications. At the RCP level, there is now the notion of a workspace, SWT/JFace UI API and Eclipse jobs, so the monkey functionality to support that should be available. The same idea would apply to Eclipse Platform, JDT and finally the PDE (which would constitute the full Eclipse SDK).
There are some consequences of these decisions. There will be more bundles/fragments than would be otherwise, but at least those components should be simpler and smaller in size. I will focus on those that deal with the new org.eclipse.monkey.core component, which will run in the base OSGi container only.
We will have to consider OSGi services (perhaps declarative services), since we are missing Eclipse extension points for one. This will be decidedly different from Groovy Monkey where language extensions and DOM(s) are specified via extension points. Hopefully this will be possible without too much difficulty, also consideration will be made to allow parallel extension points, since the PDE support for extension points is much further along than with OSGi services. Of course allowing for parallel definitions, we will hopefully not have too many headaches with monkey bundle developers trying to define their extensions as both OSGi services and Eclipse defined extension points.
Another consequence of the OSGI only approach is that there will be no IResources API, so there will need to be support for allowing scripts to be embedded in a bundle, located via URI/URL or even to allow script text to be taken in verbatim. This will be a significant difference from Groovy Monkey where everything is assumed to be a resource in the workspace.
Finally, another major impact of this choice, will be the fact that support for threading through the Eclipse Jobs API will not be available. This in and of itself also makes me want to abandon the OSGi only approach. This means that use of IWorkspaceRunnable and Eclipse Jobs will commence only when the org.eclipse.core.runtime bundle is available.
There are two other things that this line of thinking has led me to consider. One, the metadata keywords and definitions should be pluggable themselves. As of right now in Groovy Monkey the script metadata is pretty statically defined in the code for the core plugin. If the layering support is to work, they have to be plugged by different plugins/fragments depending on the framework that monkey is being run in. Second, probably need a way to define which bundles are required or which platform the script is meant to run against. For instance, putting in a Job definition for a script running in an OSGi container is nonsense, however once in the RCP level, it is required. I think that there should be probably hardcoded values: OSGi, RSP, RCP, Platform, JDT and PDE. RSP would be the OSGi container plus the org.eclipse.core.runtime and org.eclipse.core.resources plugins, but no UI support.
Finally, all this work has to be done with the idea of backwards compatibility in mind. Hey I have written lots of monkey scripts I don't wanna throw away either.
Thursday, May 15, 2008
Groovy Presentation at eBay available
I got the opportunity to present an introduction to groovy at eBay this past May 9th. It is now available from the Groovy Codehaus site at: http://groovy.codehaus.org/presentations/Groovy_eBay_2008May09/GroovyJamesErvin.html
Thanks to Dave Marsland and others at eBay for giving the the chance.
Note to Microsoft, getting WebDAV to work on Vista should not be *that* difficult.
Thanks to Dave Marsland and others at eBay for giving the the chance.
Note to Microsoft, getting WebDAV to work on Vista should not be *that* difficult.
Tuesday, May 06, 2008
New Eclipse Monkey
As you may or may not know, I have been working on Groovy Monkey for some time now. I think it is a useful tool and has a number of benefits over its predecessor Eclipse Monkey. Right now I am hoping that I will have the opportunity to take over Eclipse Monkey and take all of Groovy Monkey's improvements and make them more available to everyone.
I am writing a proposal for this (its a work in progress), you can view it at Eclipse Monkey Proposal. I would love your comments and feedback. I really hope this will happen, I wrote Groovy Monkey because I wanted a tool like that and I think others will too.
I am writing a proposal for this (its a work in progress), you can view it at Eclipse Monkey Proposal. I would love your comments and feedback. I really hope this will happen, I wrote Groovy Monkey because I wanted a tool like that and I think others will too.
Remarks from the Groovy Meetup before JavaOne
I went to the Groovy meetup yesterday in San Fransisco and I can tell you that the primary effect on me was to get me all geeked up again for Groovy. Now I don't want to leave the wrong impression, I wasn't upset with Groovy at all or anything. What I will say is that I thought that the excitement in the room was palpable and I definitely feel that Groovy is finally coming out of its 2004 pre-JSR malaise and really about to achieve its potential. Now I know being in a hotel conference room with a bunch of people who are obviously Groovy partisans does not a trend or good prediction make but I defend the statement on two grounds. One, my gut feel is not solely based on what I sensed yesterday, but rather based on what I have seen on the net and experienced as a Java developer working with Groovy. If you are a Java developer and well aware of its pain points, how can groovy not appeal to you, I mean really? Second, its my opinion, which I am entitled to have and be wrong about (which I don't believe I am wrong in this case).
One of the points that Guillaume, the Groovy project manager, brought up in his presentation, was the improvement of the performance of the 1.5+ Groovy runtime. I can say, without equivocation, that the improvement in performance is indeed extraordinary. In fact, he left out of his presentation the area that I think that Groovy 1.5+ has improved most on, was compiler performance. I would put compiler performance improvement to be on the order of magnitude better. Now I do not have any micro-benchmarks or pseudo statistics to back me up, but I will say that this is my gut feel based on my experience with Groovy Monkey. On the machine I currently use for my work (Windows Server 2003/Quad Core/8 GB RAM/IBM JVM 5.0/Eclipse 3.4M5), I would say that before Groovy 1.5, the scripts I would write that would invoke other monkey scripts, could be very very slow, on the order of a couple of minutes or more. Now those same scripts are running like well under 30 seconds and this result is not based on any changes to Groovy Monkey or any of the underlying platform. All I can say is wow!
Groovy Eclipse
I do have a comment on a slightly bitter note. I am a committer to the Groovy Eclipse project and it pained me to hear how it was mentioned that the plugin was more of a impediment than an asset to Groovy's adoption. I will admit that I myself began to get frustrated with it (and there are still some frustrations) a couple of months back. Still with the newer Groovy runtime and the latest submissions to at least the development version of the plugin, it is a far far better product.
Still there is the point that even with the latest improvements that the Groovy Eclipse plugin is still lagging significantly IDE support from IntelliJ. First off I want to mention, congrats to IntelliJ. Even though I am primarily an Eclipse developer, I am probably going to try it out just to see the Groovy support and this is a point to which I want to get back to. Still both IntelliJ and NetBeans have people working full time on the Groovy IDE support, which is great for people using those platforms, not so great for the vast numbers of developers using Eclipse. The point I want to drive home is that, as I have learned from personal experience, IDE integration is both vital to the success of a language or framework and hard to do. Now I may fiddle around with IntelliJ (or even, *gasp* NetBeans) to try out their Groovy support, but do you really think that the vast legion of Java developers using Eclipse are really going to take a hard look at Groovy without first class IDE support? I don't believe so and I would think that just about everyone would agree with me on this point.
So how do you address this? Simple, there needs to be a small group of well motivated and competent Groovy and Eclipse plugin developers that can be dedicated full time to Groovy Eclipse. In my experience, only people working full time focused on IDE support could give Groovy Eclipse that first class spit and polish which can impress developers trying Groovy for this first time. I mean, Project Zero and Scott Hickey's work with Mutual of Omaha has contributed much to the plugin and there are some nice contributions being made currently by people in their free time, but this is not their primary focus. Even though the plugin continues to evolve under current circumstances, this would not compare with the strides that could be made by people working full time. Are you listening Guillaume, Mr. Guan, others, anybody?? I mean there has some buzz about Groovy being the next version of Java and I know that Guillaume and others have stated that there is no intention of Groovy replacing Java, but can you imaging Groovy reaching its potential without great Eclipse IDE support? I know that I just repeated that point from earlier, but it bears repeating.
Back to the meetup
Now back to the Groovy meetup. I would also like to point out that I was much impressed with the presentation from the folks at Linked In. I am already a user of their product and I am even more impressed to the degree to which they appear to be driven from the Engineering perspective. Besides, they are really starting to use Groovy and Grails in anger! How cool is that man? I love the fact that they and, I believe it was, Sky television are showing that Grails is like RoR, but with stability and scalability added at no extra charge. That is so cool and can demonstrate how getting better IDE support for both Groovy and Grails could make such a difference.
I am looking forward to the future of Groovy and crossing my fingers that there wont be too much backward compatibility breaking between now and Groovy 2.0.
One of the points that Guillaume, the Groovy project manager, brought up in his presentation, was the improvement of the performance of the 1.5+ Groovy runtime. I can say, without equivocation, that the improvement in performance is indeed extraordinary. In fact, he left out of his presentation the area that I think that Groovy 1.5+ has improved most on, was compiler performance. I would put compiler performance improvement to be on the order of magnitude better. Now I do not have any micro-benchmarks or pseudo statistics to back me up, but I will say that this is my gut feel based on my experience with Groovy Monkey. On the machine I currently use for my work (Windows Server 2003/Quad Core/8 GB RAM/IBM JVM 5.0/Eclipse 3.4M5), I would say that before Groovy 1.5, the scripts I would write that would invoke other monkey scripts, could be very very slow, on the order of a couple of minutes or more. Now those same scripts are running like well under 30 seconds and this result is not based on any changes to Groovy Monkey or any of the underlying platform. All I can say is wow!
Groovy Eclipse
I do have a comment on a slightly bitter note. I am a committer to the Groovy Eclipse project and it pained me to hear how it was mentioned that the plugin was more of a impediment than an asset to Groovy's adoption. I will admit that I myself began to get frustrated with it (and there are still some frustrations) a couple of months back. Still with the newer Groovy runtime and the latest submissions to at least the development version of the plugin, it is a far far better product.
Still there is the point that even with the latest improvements that the Groovy Eclipse plugin is still lagging significantly IDE support from IntelliJ. First off I want to mention, congrats to IntelliJ. Even though I am primarily an Eclipse developer, I am probably going to try it out just to see the Groovy support and this is a point to which I want to get back to. Still both IntelliJ and NetBeans have people working full time on the Groovy IDE support, which is great for people using those platforms, not so great for the vast numbers of developers using Eclipse. The point I want to drive home is that, as I have learned from personal experience, IDE integration is both vital to the success of a language or framework and hard to do. Now I may fiddle around with IntelliJ (or even, *gasp* NetBeans) to try out their Groovy support, but do you really think that the vast legion of Java developers using Eclipse are really going to take a hard look at Groovy without first class IDE support? I don't believe so and I would think that just about everyone would agree with me on this point.
So how do you address this? Simple, there needs to be a small group of well motivated and competent Groovy and Eclipse plugin developers that can be dedicated full time to Groovy Eclipse. In my experience, only people working full time focused on IDE support could give Groovy Eclipse that first class spit and polish which can impress developers trying Groovy for this first time. I mean, Project Zero and Scott Hickey's work with Mutual of Omaha has contributed much to the plugin and there are some nice contributions being made currently by people in their free time, but this is not their primary focus. Even though the plugin continues to evolve under current circumstances, this would not compare with the strides that could be made by people working full time. Are you listening Guillaume, Mr. Guan, others, anybody?? I mean there has some buzz about Groovy being the next version of Java and I know that Guillaume and others have stated that there is no intention of Groovy replacing Java, but can you imaging Groovy reaching its potential without great Eclipse IDE support? I know that I just repeated that point from earlier, but it bears repeating.
Back to the meetup
Now back to the Groovy meetup. I would also like to point out that I was much impressed with the presentation from the folks at Linked In. I am already a user of their product and I am even more impressed to the degree to which they appear to be driven from the Engineering perspective. Besides, they are really starting to use Groovy and Grails in anger! How cool is that man? I love the fact that they and, I believe it was, Sky television are showing that Grails is like RoR, but with stability and scalability added at no extra charge. That is so cool and can demonstrate how getting better IDE support for both Groovy and Grails could make such a difference.
I am looking forward to the future of Groovy and crossing my fingers that there wont be too much backward compatibility breaking between now and Groovy 2.0.
Subscribe to:
Posts (Atom)
Posts
