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:

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@gmail.com>
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.



On Sun, May 5, 2013 at 5:05 PM, Adam Wyłuda <adamwyl92@gmail.com> 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

Lincoln Baxter, III
"Simpler is better."

forge-dev mailing list