> -----Original Message----- > From: Michal Maczka [mailto:[EMAIL PROTECTED] > Sent: 21 September 2003 13:42 > To: Maven Developers List > Subject: RE: [aspectj] Changing behavior of aspectj plugin, is it ok? > > > > > -----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.
I'm just talking about consumer goals. Producer goals can be added and is orthogonal to producer ones. > > > > 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 :) cool -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
