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
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
On Sun, May 12, 2013 at 06:00:20PM +0200, Adam Wyłuda wrote:
Thank you for your response, it's nice to hear that my proposal is rated
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,
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
Like you suggested I updated my proposal to give myself some time to
understand Groovy Eclipse plugin API and start working on Gradle project
2013/5/7 Lincoln Baxter, III <lincolnbaxter(a)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
> 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
> 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:
> 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(a)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:
>> 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
forge-dev mailing list