[forge-dev] Support for the Gradle build system as a plugin for Forge

[Lincoln Baxter, III]

I have to agree with George here. I think that getting an early prototype
working is the best first step. Once this is functional, you could
(probably should) consider spending time on getting the GroovyParser up and
running.

What do you think?


On Sun, Jun 16, 2013 at 2:26 PM, <ggastald at redhat.com> wrote:

>  Hi Adam,
>
> Given the options, it seems that option #2 is a better way to go.
> It's important to notice that as long as this implementation allows doing
> what we already do in Maven (manipulate the descriptor by adding
> dependencies and plugins, provide a GroovyProject that allows invocation of
> build targets) I'd say that either choice is OK.
>
> Best Regards,
>
> George Gastaldi
>
>
> On 06/15/2013 09:33 PM, Adam Wyłuda wrote:
>
> So, after studying JavaParser API, I've come to conclusion that creating
> exact clone of this API for Groovy would be completely irrelevant for this
> project.
> JavaParser only works on Java class/interface/enum/annotation structures,
> there is no way to modify method logic other than manually editing its
> source code (from Method.getBody() method, which returns plain String).
> What we really need, is a util which works on imperative expressions, not
> data structures, so it should be exactly opposite of JavaParser (in Gradle
> build script there will be rarely any class declarations).
>
>  I think this issue can be dealt in two ways:
> 1) Create a full GroovyParser with all capabilities to synthesize any
> piece of code (including class structures and method bodies) - that's what
> I was thinking initially, surely nice to have, but it's very hard to even
> design an API (with statements and expressions its API size will be about
> twice of JavaParser), and implementing it. To do that we would need to
> either use one of the existing parsers which are not easy to use (mostly
> IDE plugins, which are not even available as a Maven dependencies, and they
> take quite a lot of memory space) or write our own Groovy AST rewriter
> which may be easy or hard depending on what output quality we expect from
> it - if we want to keep comments and formatting it certainly won't be easy
> to do.
> 2) Use my simple parser ( https://github.com/adamwy/simple-gradle-manager )
> or rewrite it, and start working on Gradle support from now, it's fast and
> light solution (no dependencies other than Groovy library), and it's
> sufficient to make all necessary modifications to the Gradle build script.
> I could work on GroovyParser (which I promised to do) after Gradle support
> in Forge is done, and we could think about creating a common API for
> parsing Java, Groovy and maybe other languages with full support for
> expressions inside method bodies. Having this abstraction layer addons
> which need to synthesize code could work with any supported language
> without caring in which language the class they modify is written.
>
>  What do you think is a better way? I planned to go with the first, but
> the many issue related to this made me think that maybe we should take more
> time to think and discuss how the Groovy (and probably Java) parser should
> look and work like, and it will be better to do that later (it's not
> necessary for Gradle addon, but a nice feature which we will probably need
> in the future anyway).
>
> 2013/5/5 Adam Wyłuda <adamwyl92 at gmail.com>
>
>> 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 listforge-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> --
> *George Gastaldi* | *Senior Software Engineer*
> JBoss Forge Team
> Red Hat
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130618/588b2e57/attachment-0001.html