<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Adam, <br>
    <br>
    Given the options, it seems that option #2 is a better way to go.&nbsp; <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<br>
    <br>
    <div class="moz-cite-prefix">On 06/15/2013 09:33 PM, Adam Wy&#322;uda
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAOzHfokT5JAxOg4NcO0dAu352PE56V6TpqLdMWmgZ0uzT5us4g@mail.gmail.com"
      type="cite">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 (&nbsp;<a moz-do-not-send="true"
          href="https://github.com/adamwy/simple-gradle-manager"
          target="_blank">https://github.com/adamwy/simple-gradle-manager</a>&nbsp;)
        or rewrite it, and start working on Gradle support from now,
        it's fast and light solution (no dependencies&nbsp;other&nbsp;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&#322;uda <span dir="ltr">&lt;<a
              moz-do-not-send="true" href="mailto:adamwyl92@gmail.com"
              target="_blank">adamwyl92@gmail.com</a>&gt;</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:&nbsp;<a
                  moz-do-not-send="true"
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 class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
forge-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/forge-dev">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      <b>George Gastaldi</b> | <i>Senior Software Engineer</i> <br>
      JBoss Forge Team<br>
      Red Hat<br>
    </div>
  </body>
</html>