You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Massol <vm...@pivolis.com> on 2003/09/21 11:50:37 UTC

[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?

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?

Thanks
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 21 September 2003 16:30
> To: Maven Developers List
> Subject: Re: [aspectj] Changing behavior of aspectj plugin, is it ok?

[snip]

> > Would that be ok?
> 
> I would take a glance at the issue raised by one of the aspectj folks.
I
> think it was raised by Wes but he outlined a good strategy for the
> plugin which I believe is similar to yours. Did you take a peek at the
> issue?

No, I haven't checked. You're right I should look at all open bugs
against the apsectj plugin. I'll do that. Thanks.

-Vincent

[snip]


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2003-09-21 at 05:50, Vincent Massol wrote:
> 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 would take a glance at the issue raised by one of the aspectj folks. I
think it was raised by Wes but he outlined a good strategy for the
plugin which I believe is similar to yours. Did you take a peek at the
issue?

> 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?
> 
> Thanks
> -Vincent
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
-- 
jvz.

Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: Gilles Dodinet [mailto:rhill@wanadoo.fr]
> Sent: 21 September 2003 16:55
> To: Maven Developers List
> Subject: Re: [aspectj] Changing behavior of aspectj plugin, is it ok?
> 
> Vincent,
> 
> Although it actually works fine when putting standard classes
containing
> inner aspects inside aspectSourceDirectory, i find it a little
> confusing. Indeed in that case the primary cu isnot an aspect by
itself
> but rather an almost pojo, and putting it in aspectSourceDirectory
just
> because it has an inner aspect seems strange to me, in particular when
> theres f.i. only a few classes that should be moved to aspects
directory
> (that is we lose some consistency here) ; I would rather see
> aspectSourceDirectory like a container for all top-level aspects only.

There might another solution: to make aspectSourceDirectory point to the
src tree. Anyway, I agree that's an interesting point to tackle.
However, that would be for the next version. I'm going to deliver a new
first release (which I need for the Cactus build). We can always improve
on it after.

> 
> As for testing aspects, i agree this can be the role of another
> plugin/goal ; but my point was that i dont clearly understand why
there
> would be a unitTestSourceDirectory element in the pom but no
> aspectUnitTestSourceDirectory since there is already an
> aspectSourceDirectory nearby the sourceDirectory element.

Completely agree. I personally don't think we should have a <build>
element in the POM. Or better, we should have something extensible with
config elements for all plugins in the POM. I made a proposal a while
ago and we discussed it with Jason and others, but we haven't
implemented it yet...

Regards,
-Vincent

[snip]



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

Posted by Gilles Dodinet <rh...@wanadoo.fr>.
Vincent,

Although it actually works fine when putting standard classes containing 
inner aspects inside aspectSourceDirectory, i find it a little 
confusing. Indeed in that case the primary cu isnot an aspect by itself 
but rather an almost pojo, and putting it in aspectSourceDirectory just 
because it has an inner aspect seems strange to me, in particular when 
theres f.i. only a few classes that should be moved to aspects directory 
(that is we lose some consistency here) ; I would rather see 
aspectSourceDirectory like a container for all top-level aspects only.

As for testing aspects, i agree this can be the role of another 
plugin/goal ; but my point was that i dont clearly understand why there 
would be a unitTestSourceDirectory element in the pom but no 
aspectUnitTestSourceDirectory since there is already an 
aspectSourceDirectory nearby the sourceDirectory element.

regards,

-- gd


Vincent Massol wrote:

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



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

Posted by Vincent Massol <vm...@pivolis.com>.
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:rhill@wanadoo.fr]
> 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:vmassol@pivolis.com]
> >>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: dev-unsubscribe@maven.apache.org
> >For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

Posted by Gilles Dodinet <rh...@wanadoo.fr>.
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:vmassol@pivolis.com]
>>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: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: Michal Maczka [mailto:mmaczka@interia.pl]
> 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:vmassol@pivolis.com]
> > 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

Posted by Michal Maczka <mm...@interia.pl>.

> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org