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,

This is hard stuff, so I'll see if I can avoid messing
up...

> could you clarify what distinguishes
> RCC from RCL -
> does RCC refer to any use of static crosscutting?

My definition of RCC

> inter-type declarations in A on C relied-upon
> by clients of C (including C)(same for A-A')

means that some client has to "see" the effects of A on C.
It's typically that client which will fail to compile,
not A or C, but the client is in the same project as C.
(RCL is the ordinary use of a type reference to C or L.)
How RCC happens doesn't matter to me, though I clearly
am thinking of ITD's.  What matters is that the visibility
of effects like this to ordinary java compilers is
one of the things that can force one to compile with ajc.

> I
> don't see why C RCC A && C RCL A (but not otherwise)
> implies A and C need to
> be in the same project.

I wasn't saying "C RCC A && C RCL A".  It's simply
circular: 
RCC means C requires A, and RCL for A->C (not C->A) means A
requires C to compile.  You can't compile C at all without
A.

> An aspect A can
> have such
> dependencies on C (even RCC && RCL)

AFAIK, there's no such thing as A depending on C via RCC.

> cantFindType and
> cantFindTypeAffectJPMatch Xlint properties. These allow
> you to treat RCC and
> RCL types at compilation types as O at weaving time (or
> you could view these
> as allowing you to change RCC/RCL to O at weaving time).

I don't think those Xlint properties affect RCC.

> there are cases where (RCL || RCC) does
> not => RR 

Agreed - this can be true in Java, too, for untouched or
robust functionality.  I made the simplifying assumption
to reduce the number of variants to address.  I don't 
think this matters when setting up build environments.

I do agree that there are a variety of RCL relationships;
the class reference can be in the declaration for a field,
a parameter, a pointcut, a type parameter, etc. (directly
or by seeking supertypes), and these can bind at different
times - compilation, weaving, class-loading, runtime
execution.  The Xlint properties can help with two kinds of
relationships: concrete type pattern references and (same
for ITD's).  I can imagine this being essential in some
projects, but I'm just sure how many, so I'm not sure how
much air time is required and whether it's worth making all
those distinctions in that document.  If you don't mind,
I'll read the blog and perhaps borrow a use-case for the
devguide.

Wes

On Mon, 16 Jan 2006 14:23:58 -0800
 "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx> wrote:
> Hi Wes,
> 
> I'm glad to see there are plans to add reference
> documentation on this topic
> of aspect dependencies. I have a few questions/comments,
> if I'm
> understanding this text properly. If not, please
> elaborate on where I have
> misunderstood (e.g., could you clarify what distinguishes
> RCC from RCL -
> does RCC refer to any use of static crosscutting?) I
> think it's worth
> considering the cases of dependencies of C on A
> separately from dependencies
> of A on C.  In my experience one-way dependencies of A of
> C is a case that
> often causes more problems. 
> 
> I agree with the points when analyzing a dependency of C
> on A, except that I
> don't see why C RCC A && C RCL A (but not otherwise)
> implies A and C need to
> be in the same project. Why can't A can be complied
> separately and then
> placed on both the classpath and aspectpath of C's
> project? Clearly for
> mutual dependencies the types need to be in same project.
> In this case, I
> agree that !RCC && !RCL is required for LTW. 
> 
> For dependencies of A on C (only), I think there are a
> couple of subtleties
> when analyzing the ability to use LTW.  An aspect A can
> have such
> dependencies on C (even RCC && RCL) and still be deployed
> through LTW: C's
> dependency on A is O, but A's on C is RCC and/or RCL. C
> runs properly when
> not woven by A.
> 
> Moreover, an important change in AspectJ 5 is the
> cantFindType and
> cantFindTypeAffectJPMatch Xlint properties. These allow
> you to treat RCC and
> RCL types at compilation types as O at weaving time (or
> you could view these
> as allowing you to change RCC/RCL to O at weaving time).
> I talked a bit more
> about the uses of these Xlint properties on my blog at
>
http://rbodkin.blogs.com/ron_bodkins_blog/2005/12/a_hidden_treasu.html
> 
> This also implies there are cases where (RCL || RCC) does
> not => RR (the
> aspect simply doesn't ever perform an ITD or advise
> execution of the missing
> type).
> 
> I think it's worth breaking out weave-time dependencies
> separately, with the
> advent of these properties, since they give another
> degree of freedom to
> manage dependencies.
> 
> With respect to project dependencies of A on C,
> A RCL C would imply that C must be on the classpath of A.
> 
> A O C implies that C need not be on the classpath of A. 
> I believe that the definition of RCC excludes the
> possibility of A RCC C.
> 
> With respect to best practices with AJDT, it's certainly
> all a question of
> trade offs. One of tough cases I run into frequently is
> where an aspect
> needs to link to types in multiple existing projects
> (RCL) and will weave
> into the same even though the types in the existing
> projects have no logical
> required dependency (C O A). It's fairly easy to set up a
> correct build &
> run environment, but hard to set up effective
> visualization in this scenario
> (granting the pain of setting up linked source folders,
> or even converting
> all projects to AJ projects and adding inpath entries to
> the same).
> 
> Ron
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of
> Wes Isberg
> Sent: Monday, January 16, 2006 12:51 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: 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
> 
> _______________________________________________
> 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