RE: [aspectj-users] weaving among several aspectj projects in eclipse

["Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>]

Conceptually I think that there are cases where it is awkward to have a
strict dependency order: it's fairly common to see a Java source project
that is woven by a project with aspects that depend on the types in the Java
source project. For aspects that have some interactions with classes, I've
certainly seen this case arise. In a case like this, you probably have
logical dependency from the project with aspects to the project without
them.

Here's a discussion from the draft of an article I'm working on:

When working in a large, multi-module system, one of the big challenges is
avoiding circular _build_ dependencies. In this section I am using modules
to refer to build units (e.g., Eclipse projects, ant projects, or IntelliJ
modules). Circular build dependencies can happen easily when an aspect in
one module weaves into a type defined in another. For example, consider this
simple metering aspect that tracks system usage:

aspect Metering {
    declare parents: Playable implements MeteredItem;
    private int MeteredItem.usage;
    after(MeteredItem m) returning: execution(public * Playable.*(..)) &&
this(m) {
        m.usage++;
    }
}

public interface MeteredItem {
.
}

If Metering is in a different module than Playable then its module has a
logical dependency on the Playable's module. While Playable's module doesn't
have a logical dependency on Metering's it does need to be woven by it
(i.e., it needs to be linked with the other module). This is generally
solved by building the modules in the order of logical dependencies and then
weaving in a later step. This might be done by using load-time weaving, or
by a separate weave task in ant. In an IDE, this is a little trickier to
handle. Today, the best practice for visualizing the effect aspects in a
large, multi-module system is to set up additional projects and to build a
chain of weaving like this:

[woven-into modules] - > [dependent aspect modules] -> [linked source folder
modules]

By a "linked source folder" module I mean an AJDT project in Eclipse that
uses the linked source folder feature that include all the sources of the
woven into project as source folders, has the dependent aspect module(s) on
its aspectpath and that includes all the classpath entries of the woven into
project. It can even be closed during quick incremental development and
reopened for building when you want to do visualization.

Of course, the best case is to avoid this complexity altogether. In simple
cases, you can use localized aspects that are built within a single module
and have no effects on other modules. A more general strategy is to have
abstract aspects that depend just on interfaces they publish and to have
concrete aspects that are local to a module that apply them (this is related
to Ramnivas Laddad's Partipicant Pattern, although I think it's better to do
this per module, rather than per class). It's worth writing aspects in their
"natural" modules and trying to avoid these aspect dependencies, rather than
creating a "ghetto" project that contains all the aspects in the system. If
you use an .aj file extension for aspects, most tools will not have problems
handling them. Failing that, I'd recommend using a separate source tree in
existing modules rather than separate modules for them.

When there are circular logical dependencies among modules that contain
aspects, the Dependency Inversion Principle applies just as in OO: make one
type depend on an interface and not an implementation, such as by moving
Metering to a separate module so that the Playable module can depend on it
without depending on the Metering implementation. 

Note: Hopefully in future AJDT will support visualizing the effects of
weaving on inpath entries, but it doesn't currently (see bugzilla at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=117911 for details). When that
issue is fixed, you can instead weave into other projects in the dependent
aspect project.

Ron

-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Matt Chapman
Sent: Friday, January 13, 2006 9:14 AM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] weaving among several aspectj projects in
eclipse

On 12/01/06, gilbert.gao@xxxxxxxxxxx <gilbert.gao@xxxxxxxxxxx> wrote:
> I created several aspectj projects in eclipse.  Sometimes, they need
> to weave into each other. When I put them into one  eclipse project,
> they compile and weave correctly. However, when I  separate them into
> different projects, I get errors, such as duplicate  method introduction.
> I am using eclipse 3.0.2, ajdt 1.2.1 and java  1.4.2_06. I am wondering
> how I should set up my projects so that I can  compile them as they are
> in the same project. Does the order of  compiling different projects
> matter in this case?

Hi Gilbert,

There are several different ways of connecting projects together and
weaving aspects across projects. The "Managing multiple projects"
section of this article might provide some useful tips:
http://www.ibm.com/developerworks/java/library/j-aopwork9/

I'd say it is usually best to arrange your projects in a strict
dependency order, which defines the compilation order, and for the use
of aspects to follow the same order - e.g. the aspects from project A
are woven into project B, but not the other way round.

Regards,

Matt.
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users