Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of rmuntean@adobe.com designates
 64.18.1.189 as permitted sender)
From: Robert Munteanu <rmuntean@adobe.com>
To: "dev@felix.apache.org" <dev@felix.apache.org>
Date: Fri, 15 Jun 2012 13:24:40 +0100
Subject: RE: Reimplementing the SCR Generator using annotation processing
 (FELIX-3550)
Thread-Topic: Reimplementing the SCR Generator using annotation processing
 (FELIX-3550)
Thread-Index: Ac1K6hzzbXR00xhcR3moY1Xn0beUEAABLHaw
Message-ID: 
 <C9EEB58A3CFB214DA765738FFB6AE6C6016E9E9B80CD@eurmbx02.eur.adobe.com>
References: 
 <C9EEB58A3CFB214DA765738FFB6AE6C6016E9E9B7E46@eurmbx02.eur.adobe.com>
 <CAKkCf4oQmGe_GKDa2kttoAtFokRZ+v+Ad2qeTXebc_RTSnizBg@mail.gmail.com>
In-Reply-To: 
 <CAKkCf4oQmGe_GKDa2kttoAtFokRZ+v+Ad2qeTXebc_RTSnizBg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Carsten,

> Hi Robert,
>=20
> thanks for starting this discussion. It really would be nice to base
> the implementation on the javax.annotation.proessing stuff.
>=20
> 2012/6/14 Robert Munteanu <rmuntean@adobe.com>:
> > 1. Configuration
> >
> > There is a standard way of passing compiler arguments when invoking
> javac (-Akey=3Dvalue ) but it would require configuring the compiler
> rather than the scr plugin. At least for maven builds this is less
> convenient.
>=20
> Yes, I guess this is one of the biggest challenges. Now, we might
> simply pass the information through a static field in some common
> class. However this would be problematic with parallel builds like
> Maven. So we maybe could use a thread local which would only work if
> the same thread is used. But I guess we could find a solution here. If
> we are able to pass objects into the processor, we can use these
> objects to pass back the result. For example, the Maven plugin is
> creating a manifest header afterwards.

I _think_ that the arguments are passed to each processor instance individu=
ally, so we should be safe here. As far as I remember not even Eclipse reus=
es instances between processing runs.

>=20
> >
> > 2. Incremental builds
> >
> > When performing a partial build ( for instance in Eclipse, but I
> think it also applies to Maven ) not all annotated classes are passed
> to the processor so the SCR generator should either only work on full
> builds by deign or be able to perform incremental builds.
>=20
> Incremental builds should not pose a problem. Right now, all
> descriptors are written into a single xml file, however we can change
> this easily with generating a file for each component. This can easily
> be updated incrementally (as long as we can handle deletes etc.)

OK, I was under the impression that there has to be a single xml file. Havi=
ng one file per annotated component will greatly simplify matters.

>=20
> But I see some problems in the general processing: right now the tool
> is parsing two different kinds of classes: classes belonging to the
> project and classes from dependencies as a project class might inherit
> from a dependency and it might want to inherit the descriptors as
> well.  I guess we would still need ASM for handling the dependencies.
> The result of a component descriptor is the assembly of several
> annotations and these annotations are pluggable and therefore are
> processed by different processors. So we need a way to first assemble
> all annotations and once all annotations of a particular class are
> assembled, process them in one go. I'm not sure if this is possible.

If I understand correctly one particular annotated class can also depend on=
 another annotated class and perhaps on files on the compiler classpath . A=
n annotation processing engine should be able to=20

- supply complete type information when processing an annotated class - thi=
s includes all superclasses and their annotations
- supply all the classes which require compilation in the same annotation p=
rocessor invocation . One notable exception is Eclipse - when running an in=
cremental compilation only the changed classes are set up for processing.

Also, an annotation processor can be declared to handle multiple annotation=
s, so we don't have to implement one processor for each annotation. For fle=
xibility we can implement multiple annotation handlers, but we will hook in=
 a single class in the compilation process.

Robert

>=20
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org