Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] weaving among several aspectj projects in eclipse

Hi All -

Following Ron's example, below is some material on point
slated for the aspect development environment guide.
(I should add that I agree with Matt and Ron's replies.)

It's important when setting up projects and build systems 
to distinguish between kinds of dependencies, at least:

- optional, e.g., class C may be woven with aspect A
- required
  - runtime: aspect woven with class C or it fails at RT
  - compile-time: aspect compiled with class C or...
    - link: aspect A or class C won't compile 
      (A refers to C or C to A)
    - construction: class C won't compile 
      (inter-type declarations in A on C relied-upon
       by clients of C (including C)(same for A-A'))

Abbreviating all by path, e.g., "construction" as 
RCC (required-compile-construction) then:

  O => !(RR || RCL || RCC) (definition)
  (RCL || RCC) => RR       (simplifying assumption)

so for projects

- if RCC && RCL, then A and C must be in same project

- if RCC && !RCL, then A and C can be in different
projects,
  but C must be compiled by ajc with A on the aspectpath

- if !RCC && RCL, then A and C can be in different
projects,
  but A must be compiled with C on the classpath

- if {!RCC && !RCL &&} RR, then then C must be woven 
  with A on the aspectpath (but may be compiled with javac)
  (fyi, LTW only works if !RCC && !RCL)

- if O, then C may be compiled or woven with A

That's what's possible.  What's desirable is often a 
question of IDE support and incremental compilation, and 
the output form.  For IDE support, the cost/benefit of 
segregating projects and integrating them using inpath, 
aspectpath, linked source folders, and extrinsic weaving 
(either Ant or load-time) varies with AJDT et al's feature 
set, typically degrading the further you get away from 
source files, with a trade-off now between .aj (AJDT 
features, correct squiggles) and .java (JDT features).  
Depending on the size of the project and how well 
incremental compilation is working, you might save time or 
space by breaking things up or integrating them.  And if 
your output form is, say, a web jar, it's nice to just be 
able to gather all the output from a project into that jar.
 
Matt's article is a good source for these trade-off's.


Next, the dependencies change during development; e.g., as 
Ron suggested you might add RCL or have to work around it 
with a new layer of interfaces (and more complexity - 
yuck!).  It's a drag to have to change project structure or

build relationships or add interface layers just to write 
one aspect, so it's a benefit to have a project structure 
that doesn't change.

Given all this, when starting I tend to put all into one 
project to get the benefit of AJDT/IDE integration, but use
source suffixes and folders to segregate dependencies.
For example, I use .java for pure-java files and .aj for
aspectJ files, testsrc/ for files requiring JUnit and the
corresponding source folders, and aspectsrc for standalone 
aspects.  Then I have an Ant build file that builds things 
separately (e.g., javac for pure-java sources) so I have a 
check for when I change the dependencies.  If a change was 
accidental or I want to reverse it, I do, often just by 
changing a source suffix or moving a file to a different 
folder.  Either way, I can change it then or continue 
development (e.g., a refactoring) and fix it later, rather 
than messing around with project build issues.  Having the 
secondary Ant build can help with producing different
output 
jars from subsections, and, once development has settled, 
serves as a template for breaking out the prototype into 
actual projects and their build relationships.  (This also 
tends to be the time I generalize the aspects to be 
reusable.)

hth - Wes


On Sun, 15 Jan 2006 20:37:47 -0800
 "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx> wrote:
> 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
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users



Back to the top