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.
Monday, May 26, 2008
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.
Thursday, April 03, 2008
New stuff coming for Groovy Monkey
I know I have been negligent over the past few months about keeping up with new features to groovy monkey. I also know and appreciate the fact that there are those of you out there who use the tool *in anger* so to speak. First off all you should know that the project is not *dead* in any real sense. Secondly, I make use of the tool daily and have been making some commits to enhance groovy monkey. Third, I saw some cool stuff out of EclipseCon that I would like to integrate into Groovy Monkey.
On the first point, after going to EclipseCon and seeing that there was very little activity with Eclipse Monkey along with the fact that it still has the same weaknesses that led me to write Groovy Monkey in the first place, has rekindled my interest in writing new features for the plugin. I mean, Eclipse Monkey still runs everything in the UI thread, what is up with that?
On the second point, I have written a tool to allow me to automatically publish a new version to the update site, so you should be seeing more regular changes to the plugin. Now if I only had a nice script to automate publishing new releases as well.
On the third and final point, at EclipseCon I saw a couple of things that I would love to integrate with Groovy Monkey. First something called glimmer and second something called Plugin spy.
First off I was introduced to something called Glimmer by Andy Maleh. The reason that this project is of note is that I do not want to forget those people who want to use that language Ruby. Glimmer is a cool utility that is in effect a SWT/JFace builder. In fact, it is a far cooler builder than the one we have available from Groovy. I look forward to trying this and to updating the jruby libraries in Groovy Monkey.
Second is Chris Aniszczyk's new tool called Plugin spy. It is due to come out with Eclipse 3.4 (you can try it out now in version 3.4M5) and it is soooo cool. Actually I saw the tool earlier when he demonstrated it at the Eclipse Demo camp in Austin last December, but the epiphany came at EclipseCon. There is a killer feature, where you select a ui element in the workbench, hit ALT-shift-F1 and it will show a dialog with the class that represents that element, plus any additional information like extension points, etc... It is killer if you have ever tried to write a plugin extending the workbench you know that oftentimes over half the battle is just finding something. This tool can point you straight at what you want to see. So you say, where does Groovy Monkey come in and what about this life-changing epiphany? (Its so cool now that I know how to spell epiphany now.) The idea is if we could get an extension point into the Plugin spy so that Groovy Monkey could add a link and then be invoked with the information in that dialog it could be used to create a script. Why would that be cool? Imagine for a second that you are looking around the workbench and then want to see what is implementing a given feature, you use the plugin spy to see what is doing it. Well that is great, but how about trying it out? You would need to create groovy script, remembering all the details like the bundle, class name, etc... What if you could click the link in the plugin spy dialog and then use that information to create a template script? It would save alot of clicks and hassle, now that would be cool.
On the first point, after going to EclipseCon and seeing that there was very little activity with Eclipse Monkey along with the fact that it still has the same weaknesses that led me to write Groovy Monkey in the first place, has rekindled my interest in writing new features for the plugin. I mean, Eclipse Monkey still runs everything in the UI thread, what is up with that?
On the second point, I have written a tool to allow me to automatically publish a new version to the update site, so you should be seeing more regular changes to the plugin. Now if I only had a nice script to automate publishing new releases as well.
On the third and final point, at EclipseCon I saw a couple of things that I would love to integrate with Groovy Monkey. First something called glimmer and second something called Plugin spy.
First off I was introduced to something called Glimmer by Andy Maleh. The reason that this project is of note is that I do not want to forget those people who want to use that language Ruby. Glimmer is a cool utility that is in effect a SWT/JFace builder. In fact, it is a far cooler builder than the one we have available from Groovy. I look forward to trying this and to updating the jruby libraries in Groovy Monkey.
Second is Chris Aniszczyk's new tool called Plugin spy. It is due to come out with Eclipse 3.4 (you can try it out now in version 3.4M5) and it is soooo cool. Actually I saw the tool earlier when he demonstrated it at the Eclipse Demo camp in Austin last December, but the epiphany came at EclipseCon. There is a killer feature, where you select a ui element in the workbench, hit ALT-shift-F1 and it will show a dialog with the class that represents that element, plus any additional information like extension points, etc... It is killer if you have ever tried to write a plugin extending the workbench you know that oftentimes over half the battle is just finding something. This tool can point you straight at what you want to see. So you say, where does Groovy Monkey come in and what about this life-changing epiphany? (Its so cool now that I know how to spell epiphany now.) The idea is if we could get an extension point into the Plugin spy so that Groovy Monkey could add a link and then be invoked with the information in that dialog it could be used to create a script. Why would that be cool? Imagine for a second that you are looking around the workbench and then want to see what is implementing a given feature, you use the plugin spy to see what is doing it. Well that is great, but how about trying it out? You would need to create groovy script, remembering all the details like the bundle, class name, etc... What if you could click the link in the plugin spy dialog and then use that information to create a template script? It would save alot of clicks and hassle, now that would be cool.
Subscribe to:
Posts (Atom)
Posts
