Re: [aspectj] Changing behavior of aspectj plugin, is it ok?

[Gilles Dodinet]

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 
${pom.build.sourceDirectory} 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 
tree".

just my 2 cents..

-- gd

Michal Maczka wrote:

 

-----Original Message-----
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 21, 2003 11:51 AM
To: 'Maven Developers List'
Subject: [aspectj] Changing behavior of aspectj plugin, is it ok?
Hi,

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 :)

Michal



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]