New feature: XML configuration for compilation

[Andy Clement]

I've been working on enhancement 124460.  This relates to using
aop.xml files during source compilation and not just for load time
weaving.  This will enable users to exploit the benefits of an aop.xml
at compile time and also help them get the definitions right before
deploying them at load time.

With the most recent dev build of AspectJ you have the option to
supply XML configurations on the command line, or in your <iajc> ant
invocations.  Shortly you will have the ability to tag XML files in
AJDT and they will be used for builds kicked off in the IDE.

I thought I'd give a rundown on what is possible in case anyone wants
to try it and give me some feedback.

On the command line it looks like this:

ajc  -xmlConfigured A.aj B.java myaop.xml

And in Ant:

      <iajc destdir="../bin" verbose="true">
       <sourceroots>
         <pathelement path="."/>
       </sourceroots>
       <inxml>
         <pathelement path="myaop.xml"/>
       </inxml>
      </iajc>

What is possible right now?

Defining aspects
-  If switching to an XML configured mode (pass -xmlConfigured or
define an inxml section), then aspects are only used if explicitly
named in an aspects section in the XML. (currently this is only
respected for advice, not ITDs)

Excluding types from weaving
- the weaver exclude sections in XML will be respected during
compilation.  If you exclude a type in the XML, it will not be woven
during compilation.

Scoping aspects
- this is something brand new where the developer of the aspect can
specify the expected set of types affected by their aspect.  When
developing their little aspect library and packaging it with an XML
file, they can define that it doesn't matter what the weaver
include/exclude may say in some other deployment XML, the aspect can
only affect a particular set of types.  It is written like this:
<aspects>
  <aspect name="Foo" scope="com.foo...*"/>
</aspects>
How is this different to the weaver include/exclude section?  I see
the weaver section as defining how the consumer of the aspect wants to
deploy it.  Whilst the scope on an aspect definition enables the
aspect developer to control where it could apply.


This is still a work in progress, a few things I still need to do:
- intertype declarations from aspects must be ignored if the aspect is
not included
- concrete aspect definitions from the XML need to be respected at compile time
- scope support needs to be added to LTW
- a bunch of testing needs doing

Andy
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users