| [aspectj-users] Proposal for Aspect Configuration, Relevant for Simplifying Incremental Compilation |
I think better support for _incremental_ compilation of aspects could be optimized for a common idiom whereby aspects are restricted to apply to some subset of code.Today, we tend to use a common idiom for scoping the application of aspects:
public abstract aspect ExecutionTracer {
protected abstract pointcut scope();
public pointcut tracedExecs() : scope() && execution(* *(..));
before() : tracedExecs() { ... }
}
...
aspect DomainTracer extends ExecutionTracer {
pointcut scope() : within(com.example.package..*);
}
I often use a similar idiom to explicitly define the scope of application for concrete aspects. It should be possible to calculate the set of types that are possibly affected by an aspect; each advice and inter-type decl.(ITD) could be bounded by some description. However, this would surely take a lot of work to implement.
I wonder if incremental compilation could be optimized by extending AspectJ to explicitly configure the "scope of application" of a concrete aspect. This might look like:
aspect TraceDomain affects com.example.package..* {
}
of course, you could get a lot of leverage with ITD's:
aspect TraceDomain affects Traceable {
declare parents: com.example.package..* implements Traceable;
}
in some cases you could even make the library aspect concrete:
aspect ExecutionTracer affects Traceable {
}
aspect TraceDomain affects Traceable {
declare parents: com.example.package..* implements Traceable;
}
The restriciton would then be implicitly used to restrict PCD's and advice and inter-type decl's (include declare soft, declare error, etc.) in the aspect: PCD's would be restricted by an implicit && within(TypePattern), and ITD's would be restricted by an implicit && TypePattern.
This proposal would also address a common desire for separating aspect configuration from definition, which led to a desire for extensible pointcuts. Does this sound useful to others for making the aspect configuration idiom explicit? Would it make it easier to implement incremental aspect compilation? One challenge might be handling ITD's with a TypePattern that currently only support a Type (e.g., declare soft). Would it be more tractable with a simpler definition of affects (e.g., requiring a simple Type)?
Ron
p.s. I'm not a fan of the approach, but it would be possible to use XML deployment descriptors to define the scope of application external to the code.
Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895
> ------------Original Message------------
> From: Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>
> To: <aspectj-users@xxxxxxxxxxx>
> Date: Fri, Nov-14-2003 12:40 PM
> Subject: Re: [aspectj-users] Future plans for AJDT
>
> > That could represent the most
> > efficient way of working on large aspects, as long as there is a clear UI
> > and shortcut for invoking an *incremental* build of the aspects.
>
> What would an *incremental* build of the aspects constitute? Is it different
> from a normal incremental build?
>
> > I shy away
> > from it some because it might cause people to consider their aspects and
> > classes with undue separation
>
> I agree in theory. In practice, changing an aspect always requires a full
> rebuild, making the process of changing it very different from the process
> of changing a simple Java file. So there's already a separation caused by
> the performance characteristics.
>
> Looking forward to the UI document.
>
> Cheers,
> Nick
>
> On 11/14/03 1:08 PM, "Mik Kersten" <beatmik@xxxxxxxxx> wrote:
>
> > (Sorry about the blank messages. And I think that Jan only intends to meet
> > with me and not the entire users list, although that could be fun too :)
> >
> > Nick,
> >
> > Right--we could change the AJDT option to "suppress automatic builds of
> > aspects" (or perhaps "of .aj files"). That could represent the most
> > efficient way of working on large aspects, as long as there is a clear UI
> > and shortcut for invoking an *incremental* build of the aspects. I shy away
> > from it some because it might cause people to consider their aspects and
> > classes with undue separation. But I'm working on a UI document right now
> > and will include this as a design option for invoking builds. The document
> > will be sent out to the users list for feedback and all will be able to vote
> > for the desired default and exposed options.
> >
> > Thanks for the suggestion,
> >
> > Mik
> >
> >> -----Original Message-----
> >> From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-
> >> admin@xxxxxxxxxxx] On Behalf Of Nicholas Lesiecki
> >> Sent: Friday, November 14, 2003 11:42 AM
> >> To: aspectj-users@xxxxxxxxxxx
> >> Subject: Re: [aspectj-users] Future plans for AJDT
> >>
> >> Would it make sense to trigger a build for changes in java files but not
> >> it
> >> aspect files?
> >>
> >> Cheers,
> >> nick
> >>
> >> On 11/14/03 12:33 AM, "Mik Kersten" <beatmik@xxxxxxxxx> wrote:
> >>
> >>> Hi Chad,
> >>>
> >>> I agree with you that the lack of JDT-style build invocation is a major
> >>> problem and have set up a high-priority bugzilla report. If you add
> >>> yourself to the CC you will be notified when this is fixed.
> >>>
> >>> As Wes points out, changes in aspects trigger a full rebuild. So we
> >> will
> >>> keep the option of suppressing automatic builds for AspectJ projects.
> >> The
> >>> default is another question. If you have a strong feeling for what it
> >>> should be please add it as a note to the bugzilla report.
> >>>
> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=46653
> >>>
> >>> Mik
> >>>
> >>>> -----Original Message-----
> >>>> From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-
> >>>> admin@xxxxxxxxxxx] On Behalf Of Chad Woolley
> >>>> Sent: Thursday, November 13, 2003 10:27 AM
> >>>> To: aspectj-users@xxxxxxxxxxx
> >>>> Subject: [aspectj-users] Future plans for AJDT
> >>>>
> >>>> Adrian Colyer wrote:
> >>>>> the purpose of this email is to give you a heads up on our plans and
> >>>>> direction, and to invite your feedback and contributions.
> >>>>
> >>>> <vent>
> >>>> Three words: Please Fix Autobuild. :)
> >>>>
> >>>> I don't know about anybody else, but I can never get this working (the
> >>>> faq indicates that it should, but developer posts on the newsgroup
> >>>> indicate it doesn't). This is a huge annoyance to me, and prevents me
> >>>> from using the plugin (because I can't remember to manually compile
> >>>> every time before I run my unit tests, and therefore get "false
> >>>> positives"). It might be useable if ctrl-B even worked, but that
> >>>> doesn't seem to either.
> >>>> </vent>
> >>>>
> >>>> On a positive note, the future plans sound great, and I'm looking
> >>>> forward to see them completed.
> >>>>
> >>>> Thanks!
> >>>> Chad
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> aspectj-users mailing list
> >>>> aspectj-users@xxxxxxxxxxx
> >>>> http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>>
> >>> _______________________________________________
> >>> aspectj-users mailing list
> >>> aspectj-users@xxxxxxxxxxx
> >>> http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>
> >> _______________________________________________
> >> aspectj-users mailing list
> >> aspectj-users@xxxxxxxxxxx
> >> http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>