Return-Path: X-Original-To: apmail-groovy-dev-archive@minotaur.apache.org Delivered-To: apmail-groovy-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4A74318CAB for ; Wed, 24 Jun 2015 08:33:09 +0000 (UTC) Received: (qmail 87906 invoked by uid 500); 24 Jun 2015 08:33:04 -0000 Delivered-To: apmail-groovy-dev-archive@groovy.apache.org Received: (qmail 87854 invoked by uid 500); 24 Jun 2015 08:33:04 -0000 Mailing-List: contact dev-help@groovy.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.incubator.apache.org Delivered-To: mailing list dev@groovy.incubator.apache.org Received: (qmail 87844 invoked by uid 99); 24 Jun 2015 08:33:03 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Jun 2015 08:33:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 7FF7A18195D for ; Wed, 24 Jun 2015 08:33:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.9 X-Spam-Level: *** X-Spam-Status: No, score=3.9 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, KAM_LIVE=1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id FKQ4N2RvtB34 for ; Wed, 24 Jun 2015 08:32:50 +0000 (UTC) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id B7B9825320 for ; Wed, 24 Jun 2015 08:32:49 +0000 (UTC) Received: by obbop1 with SMTP id op1so22342372obb.2 for ; Wed, 24 Jun 2015 01:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=awVs1alS8Qbh6ijZoKGx/o0Mwfjm8ikkPQa/Xfqe6Is=; b=wUouoefzdokS3OSLUtXOnDVRlq3QtUO/SDJqNwNSO9IrQS0QiH7uEsiat4DFBBRljY SNpjltK5mzDU2qDE8eUXuYylJNv9UWxv4YhXdDBpUIhRoAzsAllj4HtZehZhr6yS98vV C66BLhfDpGzzdjdYHKJsn6Wp80OqVqI+zXdrWVTn/3LAPCl++EwCpd/MiYGDZdZxHWcA C1afEVmCxPIZ3t2nywy0YYHqT0dGfR+Ev7dIpWu8Cdd0b1dLxbHmCMRtHBYiKWRs+3Ob EHnMD/M9oGzQnlf2ary73Vr+/UT0E7qE0qShGDvYkrMfcu9qY2eu0tLkmuyDf27FUQ3p kZvQ== MIME-Version: 1.0 X-Received: by 10.202.77.208 with SMTP id a199mr14897896oib.32.1435134768591; Wed, 24 Jun 2015 01:32:48 -0700 (PDT) Received: by 10.202.95.131 with HTTP; Wed, 24 Jun 2015 01:32:48 -0700 (PDT) In-Reply-To: <558A3B6B.3000402@gmx.org> References: <5588DF19.9010708@gmx.org> <1435051341560-5725508.post@n5.nabble.com> <55894A4A.3040406@gmx.org> <1435071263949-5725516.post@n5.nabble.com> <55899C9D.1090804@gmx.org> <1435096731481-5725519.post@n5.nabble.com> <558A3B6B.3000402@gmx.org> Date: Wed, 24 Jun 2015 10:32:48 +0200 Message-ID: Subject: Re: java parser usage in Groovy From: Guillaume Laforge To: dev@groovy.incubator.apache.org Content-Type: multipart/alternative; boundary=001a1134fb061639de05193f5aaa --001a1134fb061639de05193f5aaa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Annotation processors can modify classes and such, and indeed, this couldn't work for Groovy classes. But in the case of Dagger 2, it's just generating new classes, and not modifying those that are annotated. So Dagger 2 is happy with this as it doesn't have to change Groovy's classes at all. So the stubs are enough for Dagger 2. 2015-06-24 7:08 GMT+02:00 Jochen Theodorou : > Am 23.06.2015 23:58, schrieb werickson: > >> I guess letting groovy do a annotation processor implementation is not >>> really a solution, is it? >>> >> >> There is a JIRA for this: >> https://issues.apache.org/jira/browse/GROOVY-3361 >> >> Theoretically it might be possible to wrap a Java Annotation Processor >> inside of a Groovy AST, but correctly mapping the helper classes that Ja= va >> provides to Annotation Processors seemed difficult when I last looked in= to >> it. >> >> When I talked to C=C3=A9dric and Guillaume about adding support for Java >> Annotation processors to Groovy earlier this year, they suggested the >> joint >> compilation stub approach for getting the Dagger2 annotation processor >> working with Groovy. >> > > Actually thinking about this further I see that there is a part that I > don't understand. > > Dagger2 is an annotation processor, as such it works on java sources. Ok, > no problem, it can work on stubs. But I thought it will also change the > class generation. As such it should either modify the sources inside java= c > or modify the resulting class files on bytecode level. In case 1 it canno= t > do changes to groovy files, because the stubs are forgotten later. In cas= e > 2 it can still work on precompiled files. Normally annotation processors = do > case 1 using the tree api (or even javac internals). But as I said, this > can't work for Groovy, not if the file's AST itself is supposed to be > modified. > > So I can see how you can write a module in Groovy to be used by dagger2. > But I fail to see how Dagger2 is supposed to handle a Groovy file with an > @Inject annotation. Can somebody explain? > > > bye blackdrag > > -- > Jochen "blackdrag" Theodorou > blog: http://blackdragsview.blogspot.com/ > > --=20 Guillaume Laforge Groovy Project Manager Product Ninja & Advocate at Restlet Blog: http://glaforge.appspot.com/ Social: @glaforge / Google+ --001a1134fb061639de05193f5aaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Annotation processors can modify classes and such, and ind= eed, this couldn't work for Groovy classes.
But in the case of Dagg= er 2, it's just generating new classes, and not modifying those that ar= e annotated.
So Dagger 2 is happy with this as it doesn't hav= e to change Groovy's classes at all.
So the stubs are enough = for Dagger 2.

2015-06-24 7:08 GMT+02:00 Jochen Theodorou <blackdrag@gmx.org&= gt;:
Am 23.06.201= 5 23:58, schrieb werickson:
I guess letting groovy do a annotation processor implementation is not
really a solution, is it?

There is a JIRA for this:
https://issues.apache.org/jira/browse/GROOVY-3361

Theoretically it might be possible to wrap a Java Annotation Processor
inside of a Groovy AST, but correctly mapping the helper classes that Java<= br> provides to Annotation Processors seemed difficult when I last looked into<= br> it.

When I talked to C=C3=A9dric and Guillaume about adding support for Java Annotation processors to Groovy earlier this year, they suggested the joint=
compilation stub approach for getting the Dagger2 annotation processor
working with Groovy.

 Actually thinking about this further I see that there is a part that I don&= #39;t understand.

Dagger2 is an annotation processor, as such it works on java sources. Ok, n= o problem, it can work on stubs. But I thought it will also change the clas= s generation. As such it should either modify the sources inside javac or m= odify the resulting class files on bytecode level. In case 1 it cannot do c= hanges to groovy files, because the stubs are forgotten later. In case 2 it= can still work on precompiled files. Normally annotation processors do cas= e 1 using the tree api (or even javac internals). But as I said, this can&#= 39;t work for Groovy, not if the file's AST itself is supposed to be mo= dified.

So I can see how you can write a module in Groovy to be used by dagger2. Bu= t I fail to see how Dagger2 is supposed to handle a Groovy file with an @In= ject annotation. Can somebody explain?


bye blackdrag

--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/




--
=
=
Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet

--001a1134fb061639de05193f5aaa--