On Mon, May 13, 2013 at 02:38:21PM -0400, Lincoln Baxter, III wrote:
>Do you have a suggestion for an alternate Groovy parser to use if we cannot
>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 some
>*really bad* things), be a problem because it will be loaded in an isolated
>classloader.

Just please consider memory usage - these are not exactly "small" on memory usage.

/max

>
>
>On Mon, May 13, 2013 at 12:55 PM, Max Rydahl Andersen
><manderse@redhat.com>wrote:
>
>> 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@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.
>> >>
>> >> ~Lincoln
>> >>
>> >>
>> >>
>> >>
>> >> 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
>> >>> forge-dev@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@lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>> >>
>>
>> >_______________________________________________
>> >forge-dev mailing list
>> >forge-dev@lists.jboss.org
>> >https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev@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@lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/forge-dev

_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev