<div dir="ltr">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.<div>
<br></div><div style>What do you think? </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 16, 2013 at 2:26 PM, <span dir="ltr"><<a href="mailto:ggastald@redhat.com" target="_blank">ggastald@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Adam, <br>
<br>
Given the options, it seems that option #2 is a better way to go. <br>
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. <br>
<br>
Best Regards,<br>
<br>
George Gastaldi<div><div class="h5"><br>
<br>
<div>On 06/15/2013 09:33 PM, Adam Wyłuda
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">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.
<div>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).</div>
<div>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).</div>
<div>
<br>
</div>
<div>I think this issue can be dealt in two ways:</div>
<div>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.</div>
<div>2) Use my simple parser ( <a href="https://github.com/adamwy/simple-gradle-manager" target="_blank">https://github.com/adamwy/simple-gradle-manager</a> )
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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
<div class="gmail_quote">2013/5/5 Adam Wyłuda <span dir="ltr"><<a href="mailto:adamwyl92@gmail.com" target="_blank">adamwyl92@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello JBoss community,
<div>This year I want to participate in an OS project and
GSoC gives me great opportunity to do so.<br>
<div>Here is my idea as GSoC 2013 proposal: <a href="http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/adamw/1" target="_blank">http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/adamw/1</a>
<div>
I'd be very happy to hear your opinions (I hope it's
not too late).</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><div class="im"><pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</div></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<div>-- <br>
<b>George Gastaldi</b> | <i>Senior Software Engineer</i> <br>
JBoss Forge Team<br>
Red Hat<br>
</div>
</font></span></div>
<br>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>