Eclipse Community Forums: AspectJ » Configuration for aspects across plugin projects?

Help

Home

Home » Language IDEs » AspectJ » Configuration for aspects across plugin projects?

Show: Today's Messages :: Show Polls :: Message Navigator

Configuration for aspects across plugin projects? [message #49329]

Wed, 02 March 2005 18:31

Paulo Merson

Messages: 14
Registered: July 2009

Junior Member

I know this is not a new question. I've read the posts to this list and I
read Adrian Colyer's piece on the three paths before you. I was able to
make it all compile and run, but I think the solution is not satisfactory.
Here's the context of my inquiry and the issues I found. If you know a
better way that will solve the issues, I truly appreciate your help!

-----------
CONTEXT
-----------
Let's say we have 2 plugin projects:
- MyProduct.core
- MyProduct.ui
The ui plugin depends on the core plugin.

We want to write advices that would affect both plugins. First question:
where's the best place to put my aspects? In the ui plugin because it
already sees the core plugin? In a separate plugin? I couldn't find a
clear recommendation anywhere, but it seems that the latter is preferable.
So, now we have a third plugin project:
- MyProduct.aspects
which contains .aj files with aspects that will affect both the core and
ui plugins.

Ah, the versions: Eclipse 3.0.1, AJDT 1.2.0M2

-----------
SOLUTION +-
-----------
The configuration of the 3 plugin projects goes as follows:
1) All plugin projects are converted to AspectJ nature.

2) In the aspects plugin:
a) add MyProduct.core/bin and MyProduct.ui/bin to the InPath
b) add the other two plugins to the classpath by checking them under
project Properties | Java Build Path | Projects tab.
c) add as required plugins (<requires> entry in plugin.xml) all the
plugins required by both the ui and core plugins. Don't add MyProduct.core
and MyProduct.ui themselves as required plugins though--they are already
in the classpath per item b.
d) set the output jar in project Properties | AspectJ. The output jar is
MyProductAspects.jar

3) In the core and ui plugins:
a) In project Properties | AspectJ Aspect Path | Libraries tab, click Add
JARs and add MyProductAspects.jar.

4) In Window | Preferences | AspectJ | Compiler | Advanced tab, check the
Reweavable option.

5) In Window | Preferences | AspectJ | Compiler | Other tab, check option
Output weaving info messages to problems view.

After doing that, clean and rebuild all projects.

-----------
ISSUES
-----------
- Errors and warnings generated by "declare" advices show twice in the
problems view. One entry is for the build of the aspects plugin, and the
other results from the build of the ui or core plugin.

- likewise, weaving info messages are duplicated in the problems view.

- if the Reweavable preference option is not checked, the build fails with
message "... is already woven and has not been built with -Xreweavable"

- the aspects plugin needs the core and ui plugins to build; conversely
the core and ui plugins need the output jar produced by the aspects build.
This cyclic dependency eventually causes an AspectJ error dialog box to
pop up informing that FileNotFoundException was thrown. The solution I
found to this error is to remove the AspectJ nature of ui and core
plugins, build them as regular plugins, build the aspects plugin so that
the output jar is created, re-add the AspectJ nature to ui and core
plugins, build them again to go through weaving. :^0

- Adding the bin folder to the InPath as explained in item (2) is not
sufficient to make the classes in the core and ui projects visible to the
builder of the aspects plugin. Although Colyer's piece says types placed
on the inpath are available for type resolution *and* exposed to the
weaver, the AspectJ builder of the aspects plugin insists on not finding
classes if they're not in the classpath.

Thanks a lot!
Paulo Merson

Report message to a moderator

Re: Configuration for aspects across plugin projects? [message #49390 is a reply to message #49329]

Thu, 03 March 2005 13:41

Eclipse User

Originally posted by: hawkinsh.uk.ibm.com

> -----------
> CONTEXT
> -----------
> Let's say we have 2 plugin projects:
> - MyProduct.core
> - MyProduct.ui
> The ui plugin depends on the core plugin.

> We want to write advices that would affect both plugins. First question:
> where's the best place to put my aspects? In the ui plugin because it
> already sees the core plugin? In a separate plugin? I couldn't find a
> clear recommendation anywhere, but it seems that the latter is preferable.
> So, now we have a third plugin project:
> - MyProduct.aspects
> which contains .aj files with aspects that will affect both the core and
> ui plugins.

> Ah, the versions: Eclipse 3.0.1, AJDT 1.2.0M2

Hi Paulo,

The simplest solution is to have an abstract aspect in your core plugin,
and then a separate concrete aspect (which implements this abstract
aspect) in both your core and ui plugins. You then don't need to worry
about Inpath/aspectPath etc.

We have an example of this in the ajdt plugins. We have an abstract FFDC
aspect which lives in the org.eclipse.ajdt.core plugin. Then we have a
concrete CoreFFDC aspect in the org.eclipse.ajdt.core plugin and a UIFFDC
aspect in the org.eclipse.ajdt.ui plugin. If you want to take a look, then
go to the CVS repository perspective in eclipse, and look at the eclipse
repository (host: dev.eclipse.org, repository path: /home/technology,
username: anonymous). Navigate to org.eclipse.ajdt > AJDTsrc1.2 and check
out org.eclipse.ajdt.core and org.eclipse.ajdt.ui. The aspects you're
looking for are in packages with "ras" in the name.

Hope this helps,

Helen

Report message to a moderator

Re: Configuration for aspects across plugin projects? [message #49450 is a reply to message #49390]

Fri, 04 March 2005 15:15

Paulo Merson

Messages: 14
Registered: July 2009

Junior Member

Brilliant, clean solution. Thanks Helen!

Summarizing the solution for the proposed example:
- MyProduct.aspects plugin doesn't have inpath anymore.
- aspects plugin doesn't create output jar anymore.
- aspect in the aspects plugin is made abstract.
- aspects plugin still has the ui and core plugins in the Java build path,
so that abstract aspects can specify joinpoints in the ui and core code.
- in MyProduct.core and MyProduct.ui plugins, no aspect path is set
(there's no output jar anymore)
- in the core and ui plugins, the aspects plugin is a required plugin in
plugin.xml
- in the core and ui plugins, create (concrete) aspect that extend the
abstract aspect in the aspects plugin.
- assuming the abstract aspect has advices that will crosscut ui and core
plugin in the same manner, the concrete aspects in core and ui can be
empty! No advice code duplication.

Paulo

PS: Knowing that AJDT is itself built with AspectJ, I had downloaded
adjt.core and ajdt.ui code from CVS before your post, as an attempt to
find a solution. Well, as pointed out elsewhere, inpath and aspect path
information is stored under .metadata, so it was not in AJDT CVS
repository. I was disappointed with not being able to see the inpath &
aspect path settings and didn't notice the aspect inheritance trick. :^)

Helen Hawkins wrote:

>> -----------
>> CONTEXT
>> -----------
>> Let's say we have 2 plugin projects:
>> - MyProduct.core
>> - MyProduct.ui
>> The ui plugin depends on the core plugin.

>> We want to write advices that would affect both plugins. First question:
>> where's the best place to put my aspects? In the ui plugin because it
>> already sees the core plugin? In a separate plugin? I couldn't find a
>> clear recommendation anywhere, but it seems that the latter is preferable.
>> So, now we have a third plugin project:
>> - MyProduct.aspects
>> which contains .aj files with aspects that will affect both the core and
>> ui plugins.

>> Ah, the versions: Eclipse 3.0.1, AJDT 1.2.0M2

> Hi Paulo,

> The simplest solution is to have an abstract aspect in your core plugin,
> and then a separate concrete aspect (which implements this abstract
> aspect) in both your core and ui plugins. You then don't need to worry
> about Inpath/aspectPath etc.

> We have an example of this in the ajdt plugins. We have an abstract FFDC
> aspect which lives in the org.eclipse.ajdt.core plugin. Then we have a
> concrete CoreFFDC aspect in the org.eclipse.ajdt.core plugin and a UIFFDC
> aspect in the org.eclipse.ajdt.ui plugin. If you want to take a look, then
> go to the CVS repository perspective in eclipse, and look at the eclipse
> repository (host: dev.eclipse.org, repository path: /home/technology,
> username: anonymous). Navigate to org.eclipse.ajdt > AJDTsrc1.2 and check
> out org.eclipse.ajdt.core and org.eclipse.ajdt.ui. The aspects you're
> looking for are in packages with "ras" in the name.

> Hope this helps,

> Helen

Report message to a moderator

Re: Configuration for aspects across plugin projects? [message #49480 is a reply to message #49450]

Fri, 04 March 2005 16:11

Eclipse User

Originally posted by: hawkinsh.uk.ibm.com

Hi Paulo,

I'm glad that helped :-)

Just one thing, you mentioned:

>- aspects plugin still has the ui and core plugins in the Java build path, so
>that abstract aspects can specify joinpoints in the ui and core code. - in
>MyProduct.core and MyProduct.ui plugins, no aspect path is set (there's no
>output jar anymore)

I think what you really want to do is not have a dependency this way, as
looking at the solution, you still have a two way dependency between the
plugins. Ulitmately, your dependencies should be as follows:

core plugin depends on the aspect plugin
ui plugin depends on the core plugin

What you need to do is define one (or more) abstract pointcut(s) in your
abstract aspect in the aspect project. You can then have the advice in the
abstract aspect use the abstract pointcut(s) and do all the neccessary
processing etc. that you want to do. Then, in the concrete aspects in your
ui and core plugins all you need to do is specify what this pointcut means
in terms of those plugins.

For example, if your aspect project was implementing a tracing feature,
then your abstract aspect might contain something like the following:

public abstract pointcut tracingScope();

You would then implement the tracing policy in the abstract aspect/project
using this pointcut. In the UI and Core plugins you would then specify the
tracing scope. This way you don't need to include the ui and core plugins
on the build path of the aspect project.

> PS: Knowing that AJDT is itself built with AspectJ, I had downloaded
> adjt.core and ajdt.ui code from CVS before your post, as an attempt to
> find a solution. Well, as pointed out elsewhere, inpath and aspect path
> information is stored under .metadata, so it was not in AJDT CVS
> repository. I was disappointed with not being able to see the inpath &
> aspect path settings and didn't notice the aspect inheritance trick. :^)

The AJDT plugins don't have any inpath and aspect path settings, but as of
the fix for enhancement
https://bugs.eclipse.org/bugs/show_bug.cgi?id=40446 we now store the
compiler settings in a file under a .settings directory. Therefore, if
there were any such settings you would be able to see them.

Hope this helps,

Thanks, Helen

Report message to a moderator

Re: Configuration for aspects across plugin projects? [message #50226 is a reply to message #49480]

Thu, 24 March 2005 23:42

Paulo Merson

Messages: 14
Registered: July 2009

Junior Member

Helen Hawkins wrote:

> Hi Paulo,

> I'm glad that helped :-)

> Just one thing, you mentioned:

>>- aspects plugin still has the ui and core plugins in the Java build path,
so
>>that abstract aspects can specify joinpoints in the ui and core code. - in
>>MyProduct.core and MyProduct.ui plugins, no aspect path is set (there's no
>>output jar anymore)

> I think what you really want to do is not have a dependency this way, as
> looking at the solution, you still have a two way dependency between the
> plugins. Ulitmately, your dependencies should be as follows:

> core plugin depends on the aspect plugin
> ui plugin depends on the core plugin

> What you need to do is define one (or more) abstract pointcut(s) in your
> abstract aspect in the aspect project. You can then have the advice in the
> abstract aspect use the abstract pointcut(s) and do all the neccessary
> processing etc. that you want to do. Then, in the concrete aspects in your
> ui and core plugins all you need to do is specify what this pointcut means
> in terms of those plugins.

> For example, if your aspect project was implementing a tracing feature,
> then your abstract aspect might contain something like the following:

> public abstract pointcut tracingScope();

> You would then implement the tracing policy in the abstract aspect/project
> using this pointcut. In the UI and Core plugins you would then specify the
> tracing scope. This way you don't need to include the ui and core plugins
> on the build path of the aspect project.

I agree that the abstract pointcuts and isolated concrete pointcuts are a
good solution and avoid the 2-way dependency. It's ideal for tracing and
other cross cutting concerns that span both projects independently.
However, consider the example of an architecture reinforcement advice that
declares a warning when code in the core plugin makes explicit calls to
code in the ui plugin. In this case the pointcut expression for such
declare advice would be "within core" && "call to ui". For this example at
least, I need to refer to core types and ui types in the same place. :^/
--paulo

Report message to a moderator