tag:blogger.com,1999:blog-6917071644715743308.post2857553315594216408..comments2023-09-01T05:42:40.590-07:00Comments on Contraptions for programming: Approaches to Extending JDTAndrew Eisenberghttp://www.blogger.com/profile/07897697507691706588noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6917071644715743308.post-55862046621115365692010-02-26T13:37:01.347-08:002010-02-26T13:37:01.347-08:00Thanks for clearing that up, Stephan. If you were...Thanks for clearing that up, Stephan. If you were to restart the OT integration with JDT today, would you go with a feature patch, or would OT be sufficient?<br /><br />The reason why AJDT and Scala do not require a core patch is that they both had a lot of work going into the plugin, including their own builders, before starting to use JDT weaving. This means that the integration points were small and well-defined enough so that AspectJ was a reasonable way to go.Andrew Eisenberghttps://www.blogger.com/profile/07897697507691706588noreply@blogger.comtag:blogger.com,1999:blog-6917071644715743308.post-88373886959294780782010-02-26T13:29:36.341-08:002010-02-26T13:29:36.341-08:00Yes for the JDT Extensions project!
To answer why...Yes for the JDT Extensions project!<br /><br />To answer why OT has its own JDT core patch: (1) we didn't have OT/J when we implemented the OT/J compiler :) and (2) due to the tight integration of OT/J into Java we need such a large number of changes that refactoring to aspect would be a *big* project. For 10 other plugins adaptation with OT/Equinox satisfies all our desires - for several years now.<br /><br />StephanUnknownhttps://www.blogger.com/profile/11220073186144669148noreply@blogger.comtag:blogger.com,1999:blog-6917071644715743308.post-17956604729774409632010-02-26T11:53:26.314-08:002010-02-26T11:53:26.314-08:00I think the only long term solution is a common JD...I think the only long term solution is a common JDT Extensions project, and this is something that we will talk about at this year's EclipseCon.<br /><br />As for which approach is best, I am not sure OT would be best. The OT project itself uses a JDT core patch, presumably because the locations that need to be affected are not compatible with the OT approach (this is the same reason why we did not use JDT Weaving for Groovy).Andrew Eisenberghttps://www.blogger.com/profile/07897697507691706588noreply@blogger.comtag:blogger.com,1999:blog-6917071644715743308.post-84407304004726450342010-02-25T08:14:18.199-08:002010-02-25T08:14:18.199-08:00My vote would be OT. It seems as the cleanest appr...My vote would be OT. It seems as the cleanest approach to me, and extension points could easily be tested in practice before given to other projects.<br /><br />Isn't this similar to circular dependencies problem? How do we solve it? We introduce "common" project.<br /><br />IMHO OTDT, Groovy, Scala IDE and AJDT should start a new "JDT extensions project" as an incubator for future JDT extensions. They should equally participate in it.<br /><br /><br />I have some experience with equinox aspects and <br />I don't think JDT weaving approach is maintainable (at least not as OT/J).Anonymousnoreply@blogger.com