felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Munteanu <rmunt...@adobe.com>
Subject RE: Reimplementing the SCR Generator using annotation processing (FELIX-3550)
Date Fri, 15 Jun 2012 12:24:40 GMT
Hi Carsten,

> Hi Robert,
> 
> thanks for starting this discussion. It really would be nice to base
> the implementation on the javax.annotation.proessing stuff.
> 
> 2012/6/14 Robert Munteanu <rmuntean@adobe.com>:
> > 1. Configuration
> >
> > There is a standard way of passing compiler arguments when invoking
> javac (-Akey=value ) but it would require configuring the compiler
> rather than the scr plugin. At least for maven builds this is less
> convenient.
> 
> 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 individually, so we should
be safe here. As far as I remember not even Eclipse reuses instances between processing runs.

> 
> >
> > 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.
> 
> 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. Having one file per
annotated component will greatly simplify matters.

> 
> 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 . An annotation processing engine should
be able to 

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

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

Robert

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

Mime
View raw message