Do you have a suggestion for an alternate Groovy parser to use if we
use groovy eclipse?
Nope - its one of the reasons I consider Gradle as evil as Ant in many places :)
Also, even if we do, this should not (unless the Eclipse JDT does
*really bad* things), be a problem because it will be loaded in an isolated
Just please consider memory usage - these are not exactly "small" on memory
On Mon, May 13, 2013 at 12:55 PM, Max Rydahl Andersen
> 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
> 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.
> 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
> >I first thought that creating our own Groovy parser which works directly
> >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
> >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
> >like this:
> >x = y + /* comment */ z
> >So as you said, it's better to use existing solution so we won't
> >the wheel. I think that Groovy Eclipse plugin is the best candidate
> >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
> >support earlier.
> >2013/5/7 Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
> >> Hey Adam,
> >> Thank you so much for your proposal! We have reviewed your submission
> >> 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?
> >> 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>
> >>> Hello JBoss community,
> >>> This year I want to participate in an OS project and GSoC gives me
> >>> 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
> >>> _______________________________________________
> >>> 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
> forge-dev mailing list
Lincoln Baxter, III
"Simpler is better."
forge-dev mailing list