Re: [forge-dev] Support for the Gradle build system as a plugin for Forge

Just a warning about using groovy eclipse plugin - it historically have had a dependency on a patched Eclipse JDT meaning it's not installable on just any eclipse version. I would hope if you just need a groovy parser that you don't have a depenency on Eclipse JDT for that - but if you do then that might become tricky (might also be osgi dependencies to deal with, but that is another concern ;) If the dependency will be included into eclipse as a forge loaded lib we might avoid it all - but since forge itself also have a dependency on JDT it is something to keep an eye on for possible version mismatches. /max On Sun, May 12, 2013 at 06:00:20PM +0200, Adam Wyłuda wrote: >Hi Lincoln! >Thank you for your response, it's nice to hear that my proposal is rated >positively. > >I first thought that creating our own Groovy parser which works directly on >Groovy AST would be a good idea because that would give us more >possibilities than existing solutions, but you are right - there is a risk >that it might take more time than planned (although basic support could be >provided which could be sufficient to work on Gradle project files). > >I have found this paper which gave me some insights on problems related to >Groovy script parsing and modification: >http://groovy.ifs.hsr.ch/groovy-refactoring.pdf > >It seems that the biggest issue is how to rewrite code without changing its >formatting and how to keep comments in code. Groovy AST doesn't contain >comment nodes so if we want to use pure Groovy AST to parse it, we need to >include all whitespace and comments in our model, what is possible because >Groovy AST nodes include position in source information, so we could just >substring our source between statements, but it's hard because we need to >check thoroughly every expression as comments can appear between any nodes, >like this: >x = y + /* comment */ z > >So as you said, it's better to use existing solution so we won't reinvent >the wheel. I think that Groovy Eclipse plugin is the best candidate because >it's API is similar to JDT plugin used in JavaParser (actually Groovy >plugin uses JDT and it even seems to be a part of JDT), so it will be more >convenient for other developers with JavaParser experience to maintain it. >The are also alternatives like NetBeans or IntelliJ IDEA plugin, but I >think Eclipse plugin is sufficient enough to work effectively with Groovy >sources. > >Like you suggested I updated my proposal to give myself some time to >understand Groovy Eclipse plugin API and start working on Gradle project >support earlier. > >2013/5/7 Lincoln Baxter, III <lincolnbaxter(a)gmail.com&gt; > >> Hey Adam, >> >> Thank you so much for your proposal! We have reviewed your submission and >> so far all the mentors have given it a high rating :) >> >> I took a look at your prototype groovy-manager project, which looks very >> interesting. You are doing source parsing for groovy, which is pretty >> challenging. >> >> While writing a parser from scratch can be a thrilling challenge, I have >> to say that it can be quite a burden! We started writing our own >> Java-parser for Forge, but quickly came to find that even parsing a >> type-safe language is incredibly difficult. >> >> We ended up using the Eclipse JDT as a base implementation for our >> JavaParser. >> >> Have you looked for any Groovy parsers that may already exist today? This >> would give you a quick boost when working on this project. It may be the >> case that the parser would require some usability improvements to make >> integration with Forge simpler, and simpler for plugin devs, but I think it >> is safe to say that a search for existing parsers is warranted. >> >> If a suitable parser can be found, I would suggest that we revise your >> proposal to allow for several weeks to become familiar with that parser, >> and then allocate the rest of the time to actually working with it to >> implement the gradle support. >> >> I'd suggest starting here, with the Groovy Eclipse Plugin - they almost >> certainly already support groovy syntax: >> http://groovy.codehaus.org/Eclipse+Plugin#EclipsePlugin-KeyFeatures >> >> The problem with writing your own parser is that you have to maintain it >> :) Better to delegate. >> >> ~Lincoln >> >> >> >> >> On Sun, May 5, 2013 at 5:05 PM, Adam Wyłuda <adamwyl92(a)gmail.com&gt; wrote: >> >>> Hello JBoss community, >>> This year I want to participate in an OS project and GSoC gives me great >>> opportunity to do so. >>> Here is my idea as GSoC 2013 proposal: >>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/adamw/1 >>> I'd be very happy to hear your opinions (I hope it's not too late). >>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >>> >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >_______________________________________________ >forge-dev mailing list &gt;forge-dev(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev