Tuesday, September 29, 2009

Groovy-Eclipse plugin now supports Eclipse 3.5.1

The Groovy-Eclipse plugin can now be installed into Eclipse 3.5.1. As always, the update site is here:


You can stop reading here if you don't care how I got this to work, or why I am a little bit surprised by this.

The Groovy-Eclipse plugin uses a feature patch on the JDT core bundle in order to achieve a high level of integration with JDT. Typically, feature patches can only apply to a specific version of a feature (e.g., 3.5.0.v20090527-2000-7r88FEeFJePyvYeA33DjZ_c1 or some ugliness). This means that Groovy-Eclipse, until recently could only install in a specific version of Eclipse, the one that ships the JDT feature version 3.5.0.v20090527-2000-7r88FEeFJePyvYeA33DjZ_c1. However, Andrew Niefer describes how to get around this by editing the content.xml file to widen the range that the patch applies to. Excellent stuff, and lucky for me, because I didn't want to branch the Groovy-Eclipse code base every time a new service release of Eclipse comes out.

Unfortunately, his instructions were not entirely accurate. Andrew mentions that the range attribute in the <patchscope> element needs to be widened in order allow the patch to be installable on multiple versions. I tried exactly what he suggested, but could not get my patch to install in both 3.5.0 and 3.5.1. After a little bit of exploration, I found that I also needed to change the range attribute in the <lifecycle> element.

All this meant was adding a single line to my ant script, to be executed after the p2 repository is generated:

<replace file="${updateSiteDir}/content.xml"
summary="yes" token="${orig.jdt.feature.version.range}"

And this turned out to be very simple. Thanks for the hint!


  1. This is really great news. I'm going to install it today and see how it feels. Thanks!

  2. My Eclipse 3.5.1 has org.eclipse.jdt.core_3.5.1.v_972_R35x.jar

    When installing the plugin, it downloaded org.eclipse.jdt.core_3.5.0.xx-20090929-1600-e35.jar

  3. @Shadow

    The jdt.core bundle that comes from the update site is based on the jdt.core 3.5.1 bundle included in Eclipse 3.5.1. We have not bumped up the version number yet (but we probably should).

    Our jdt.core bundle includes some small changes so that Eclipse will integrate better with our Groovy tooling. We have done extensive testing to ensure that our changes have negligible impact on non-Groovy projects.

  4. i tried using the jdt bundled with the latest nightly build of groovy plugin and then updated the jdt feature of eclpse 3.5.1 to point to jdt core bundled with groovy plugin, but getting some security related errors.
    I am wondering the better approach might be to patch around the jdt stuff rather than bundling the entire jdt with groovy plugin.
    Andrew it would be great to know your thoughts on this.

  5. Hi Ajay,

    I'm not sure what you mean by patch around the jdt. We have considered only shipping the parts of jdt.core that we have changed. But, this would be a maintenance nightmare for us. And the only thing we would gain would be a slightly smaller install size. We are using a feature patch which is a fully supported (if seldom used) way of making changes to pre-installed plugins.

    What kind of errors have you been receiving?

  6. Hi Andrew,
    By error i meant SecurityException here.
    As groovy plugins are shipped with entire jdt-core plugin, so i need to temper my eclipse 3.5.1 jdt feature to point to groovy's jdt-core plugin, now i need to do that because jdt-core is a singleton bundle and i wont be able to compile my plugins using eclipse plugin build.
    Now as i am tempering with eclipse jdt feature, during my plugin build i am getting security related exception, even deleting META-INF(signature manifest) folder doesnt help.

    So if groovy plugins are shipped with entire jdt-core plugin then a lot of users are going to face similar issues as they need to update eclipse jdt feature.

    I believe that this is an issue specifically related to building plugins using eclipse pde build, so users who are not building plugins and only need groovy support wont be impacted by this.

    Also users wont be able to upgrade to newer eclipse releases unless until there is a corresponding release from groovy side.

  7. Hi Ajay,

    I'm still not sure what you mean by temper. At what point in the pde process is this happening? Can you send a log? Are you doing a headless build, or an export? We are building both AJDT and Groovy using a patched eclipse with no problems, so it may be something specific with the set up that you are using. If you can, please send me a log file to andrew [at] eisenberg [dot] as.

    Since your problem appears to be related to pde builds not being able to compile against the jdt core patch, have you tried setting the target environment (ie- plugin path) to be a regular (non-patched) Eclipse 3.5.1?

    As for your last point, that is true. However, we released support for 3.5.1 the Monday after 3.5.1 was released (on a Friday). Our intention is to stay on top of these releases and actually release the new core patch on the day that the new release comes out. As long as jdt core does not change much (and from our experience in the last 2 years, it has not) then keeping our patch up to date is not a huge burden.

  8. Hi Andrew,
    I am doing a headless build using eclipse pde (antrunner)
    My target environment includes eclipse 3.5.1 and groovy eclipse plugin, i am running my headless build against this target platform and getting following exception:-

    /eclipse-target/plugins/org.eclipse.pde.build_3.5.1.R35x_20090820/scripts/genericTargets.xml:106: Bundle org.eclipse.jdt.core_3.5.1.v_972_R35x failed to resolve.:
    Another singleton version selected: org.eclipse.jdt.core_3.5.1.xx-20091011-2300-e35

    So what i meant by tempering eclipse jdt is that groovy is providing jdt_patch as a feature but existing eclipse jdt feature continues to point to eclipse jdt-core plugin instead of groovy jdt-core and this might be the reason i am getting above exception, so i thought of manually changing eclipse jdt feature to point to groovy jdt-core plugin which resulted in the security exception.

    Now coming back to your second point of pointing my plugin build to a regular(non patched) eclipse, doing this simply doesnt make sense because then my plugin product build wont be having groovy related stuff and the users who wants to use my plugin wont be able to do any groovy related stuff.

    Are you building your stuff through eclipse pde build?

  9. I'm having a similar issue and just created a bug for it:


  10. Hi Joel,
    I have resolved the issue by installing groovy plugin as a feature on top of my product through p2 director. Try it out

  11. Hi Andrew,
    I want to be notified of changes in the first class groovy types (classes and methods), but it seems that registering a Rename participant doesnt seems to get call backs from the groovy plugin infrastructure.
    Any clue as to why rename participant doesnt get a call back?

  12. I don't know. I haven't written any of the refactoring code for groovy. It was written by another contributor.

    I am hoping to get http://jira.codehaus.org/GRECLIPSE-419 fixed, which may address your problem (but it may not). However, I'd still recommend raising a bug for it. Please describe what you are trying to do. And patches are always welcome. :)

  13. Hi Andrew,
    I need some help related to building groovy eclipse plugin from source, i dont see any build files as part of source code in svn repository, i need to build groovy plugin from source to test the changes i have done in groovy plugin code related to refactoring before submittimg the patch.


  14. Hi Ajay,

    What changes have you made that make it necessary to build from source? Are you able to run the tests?

    The build files are in:
    You should edit the build_local.properties and add values that make sense for your local environment. We are still building using Eclipse 3.4.2 to drive the build just because there hasn't been any need to change. The scripts may work on 3.5.1, but I have not tried.

    Also, make sure that your patch is against head as I have made quite a few changes to the refactoring support since your last comment.

  15. Hi Andrew,

    I am running into issues while building groovy pluin from source. As per your comments i am also using eclipse ganymede 3.4 as my target platform for building groovy features.
    However while building i am getting following exception:-

    Some inter-plug-in dependencies have not been satiesfied.
    Bundle org.eclipse.jdt.core:
    Another singleton version selected: org.eclipse.jdt.core_3.5.1.xx-20091211-0100-e35.

    I believe that this exception is coming because there is a jdt core plugin present as part of groovy plugin source code which is conflicting with jdt core plugin in the target eclipse.

    Could you suggest if i am missing anything here?


  16. I do not think that line is your problem. It is just a warning saying that there are 2 versions of that plugin floating around and that the later version is being used. That warning comes out in all builds of Groovy-Eclipse. See the logs of the latest build:

    What is the problem that is causing your build to fail?

    Also, you are welcome to build the plugin on your own, but I'd like to ask again, why are you doing this? Are you trying to test out a new patch?

  17. Hi Andrew,
    I am building groovy plugin from source to test out the changes i have done to support rename participant callback which gets initiated from rename refactoring of groovy code, this feature is currently missing from groovy plugin.


  18. I'd be interested in seeing the patch that you created. Can you please attach it to a bug report on http://jira.codehaus.org/browse/GRECLIPSE

  19. Hi Andrew,

    I have created a bug at http://jira.codehaus.org/browse/GRECLIPSE-575
    I have attached the patch for the same as well, please go through the patch and let me know if anything needs to be modified.


  20. Thanks. I'll try to have a look at it today.

  21. Hi Andrew,

    Just picked up latest build from repository with time stamp - 18-dec-2009 18:37 38M. But this one doesnt seems to have my changes. Could you let me know which build i should pick up for getting changes committed by me.


  22. Hi Ajay,

    I had to do some refactoring around that area after I committed. Without any tests, I didn't know that I had broken it. Sorry about that. I should have asked for a test case from you as well.

    I won't be able to have something out until tomorrow, but I'll let you know when a build is available.

  23. New build is available. Please let me know if this works for you.

  24. Hi Andrew,

    Refactoring done by you seems to be ok, but a small change was missing from RenameMethodProvider class, i have uploaded a new patch in jira, please have a look at it.


  25. Hi Andrew,
    Do you have any idea as to when change method signature refactoring is going to be supported in groovy editor? I understand that this doesnt make sense in a dynamic language but still some basic support would be great.
    By the way did you got a chance to review my latest patch for 575.


  26. Method signature refactoring is not currently on the roadmap. Would you please raise a jira for this? If you are willing to submit a patch, I'd be willing to give you some pointers.

    As for GRECLIPSE-575, it will not be able to make it into 2.0, since we are now only fixing blocker bugs in the RC release stream. However, I should probably be able to get it in soon after that.