maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Dodinet <>
Subject Re: [aspectj] Changing behavior of aspectj plugin, is it ok?
Date Sun, 21 Sep 2003 12:45:14 GMT
i havent used the aspectj plugin yet, so i wonder how well inner aspects 
are managed. i guess it might cause some problems, since those inner 
aspects are indeed defined inside a class located under 
${} so i think a regular java:compile wouldnot 
work in that case. Also as michal pointed it out, i think aspectj plugin 
should be properties-driven so that injars and outjars option can easily 
be used. such a scenario :

     + aspects-lib-project => should be built with -noweave options
           + aspectSrcDir => contains aspects that should be included 
into the library
           + testDir => contains both test aspects and test classes ??? 
sounds bad.
                         => seems like there should be another directory 
like testAspectSourceDirectory (it may also be true for mixed-project below)
     + java-project => aspects defined in aspects-lib-project should be 
weaved into produced artifact
     + mixed-project 
          + srcDir  => contains both java classes and java classes with 
inner aspects => implies that javac shouldnot be used but rather ajc
          + aspectsDir => aspects that should be weaved into classes 
located under srcDir, testDir, utTestDir
Also if creating an aspect libraries, we want also to include test 
aspects, something like that :.

  testDir contains both :

  public aspect PersistenceDeclarationTest {
      declare parents: Contract implements IPersistentObject; 

  public class ContractDao implements IDao {
      //please note that aspect below should *not* externalized since it 
really makes sense only within ContractDao which is the only entity that 
has the knowledge of which fields are lazyloaded
      private static aspect ContractLazyLoadingAspect extends 
LazyLoadingAspect {
         protected pointcut getLazyLoadedField(): get(Product 
Contract.product) || get(Partner Contract.partner);
         protected pointcut setLazyLoadedField(): set(Product 
Contract.product) || set(Partner Contract.partner);      

above is a dummy example, and so i guess you might have some objections, 
however i think supporting inner aspects is really important. Perhaps it 
is what you meant by "verify if there are aspects present in the source 

 just my 2 cents..

-- gd

Michal Maczka wrote:

>>-----Original Message-----
>>From: Vincent Massol []
>>Sent: Sunday, September 21, 2003 11:51 AM
>>To: 'Maven Developers List'
>>Subject: [aspectj] Changing behavior of aspectj plugin, is it ok?
>>I'd like to change the way the aspectj plugin works. Here's what I'd
>>like to implement:
>>- make it a pre-goal of jar:jar
>>- verify if there are aspects present in the source tree
>>- if there are, weave the aspects on the *bytecode* (classes compiled by
>>the java plugin)
>>- the generated jar of the jar plugin will then contain the aspects
>>This way, building an aspected project will be seamless. Of course we
>>could have a property to turn off automatic aspecting if we want.
>>Would that be ok?
>I hope that soon AspectJ will be used on daily basis and there will be more
>and more libraries containing aspects.
>So any project can be both consumer and producer of such libs.
>Your scenario is bit to simple to handle such cases.
>>Note: The only fear I have is when Maven users using aspects also define
>>a pre-goal on jar:jar. Would the aspect pre-goal be run before or after
>>the user one? I think the user one should run before the aspect one. But
>>is that what is going to happen?
>Order of execution is unknown.
>Any way: +1 on any improvments of this plugin :)
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message