Hi Gilles, Aspects have to be placed under <aspectSourceDirectory/>. What do you call inner aspects? Aspects that are declared inside a standard java source file? If so, then these files would need to be put under <aspectSourceDirectory/> but that would work I think.
Now WRT the different scenarios. That's fine but I'm only talking about weaving aspects in project files ATM. That's the goal of this aspectj plugin (that was my goal when I created it a year or so ago and I'd like to keep it like this). For other use cases, I'd suggest to create other plugins but not to mix concerns. For example, I have on my laptop an ajtest pluging which performs aspectj unit testing (i.e. it weaves aop unit tests located in a src/aspectj-test directory and run junit tests). Other scenarios can be accommodated by other plugins. Nonetheless, thanks for all these nice ideas! :-) Thanks -Vincent > -----Original Message----- > From: Gilles Dodinet [mailto:[EMAIL PROTECTED] > Sent: 21 September 2003 14:45 > To: Maven Developers List > Subject: Re: [aspectj] Changing behavior of aspectj plugin, is it ok? > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
