On Tue, May 07, 2013 at 10:28:13AM -0400, Lincoln Baxter, III wrote:
Yes. I agree100%, but to modify the gradle build file, we will need to
able to parse and understand the source. It would be nice to include a
Groovy Parser in Forge anyway!
Is there even a defacto enough convention in gradle for where/how dependencies are
The gradle builds i've seen declared dependencies "sanely" initially and
then grows into using the power
of groovy/gradle to split things up in dependency configurations and become very nice to
use, but tricky to edit for a tool.
But maybe there is a "best practice" forge can assume/enforce?
Gradle definitely has a lot of tooling issues to overcome.
Yeah - its not exactly tooling friendly from the "editing" side at least.
On Tue, May 7, 2013 at 8:08 AM, Max Rydahl Andersen <manderse(a)redhat.com>wrote:
> AFAIK, gradle team tells tooling that want to understand gradle build files
> is to use and *run* gradle-tooling-api to parse it. Don't try parse it.
> I believe eclipse plugin uses that.
> See http://www.gradle.org/docs/current/userguide/embedding.html
> (it's one of the reasons I'm not really happy about gradle since its
> dog start/slow to run on large set of projects - they keep saying that
> will improve though...)
> On Mon, May 06, 2013 at 07:27:20PM -0400, Lincoln Baxter, III wrote:
> >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
> >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
> >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
> >> forge-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >Lincoln Baxter, III
> >"Simpler is better."
> >forge-dev mailing list
> forge-dev mailing list
Lincoln Baxter, III
"Simpler is better."
forge-dev mailing list