[aspectj-users] SCM & aspectj

[Eric.D.Friedman@xxxxxxxxxxxxxx]

I have a somewhat lengthy question about software configuration management
(SCM) practices and aspectj.  I'd be grateful for any insight you folks can
offer.

On a large project, it's quite common to break the code base up into
separate libraries that roughly equate to the "separation of concerns" in
the design.  So, for example, a large web application might contain several
jar files of "application" code, in addition to the usual servlets and other
GUI related code.   The goal of this practice would be to enable developers
to work on those underlying libraries independently of the web application
context.  This is a good practice because it increases the likelihood that
the underlying libraries can be reused in other (non-web) contexts as well.
As a matter of developer efficiency, this approach also allows for "build
avoidance" -- if you're working on the GUI, you don't need to keep
recompiling the underlying libraries, and vice versa.

It's also quite common, in my experience, for those underlying libraries to
have their own unit test suites to cover the behavior of the library in a
manner that doesn't assume usage in the web context.  Finally, it's common
to want to "certify" a version of the library in its own right,
independently of the application(s) in which it's deployed.  It's therefore
important the library be buildable in a consistent and repeatable way no
matter which application ends up using it.

Consider the following example:  a project contains 3 distinct layers,
packaged as jars, and organized in separate builds for the reasons described
above:
base messaging layer -- a distributed messaging framework of some kind, say
SOAP  [layer 1]
business logic layer -- components that represent business entities and that
rely on the base messaging layer to get things done [layer 2]
presentation layer -- web stuff, say struts actions -- implemented in terms
of the business logic layer [layer 3a]

Let's further suppose that the two first two layers are reused in a second
application, one with a different presentation layer (a conventional GUI, or
command line interface) [layer 3b].

So, there are two applications, but they share two underlying libraries in
common.  Application A = layers {1,2,3a} ; Application B = layers {1, 2, 3b}

Enter AspectJ.  As you're aware, it is not possible to weave the same
bytecode more than once in AspectJ.  What's the "best" way to manage aspects
that cut across layers?  Assume that you are using aspects to implement some
fundamental, er, aspect of the application, not merely bolting on logging,
tracing, or timing after the thought.  How do you deal with cases in which a
higher layer (3a or 3b) wants to introduce advice of an application-specific
nature into the shared libraries' classes, which may already be woven with
aspects of their own?

One answer is obviously to pull all aspects up to the top-level build (the
one that rolls up the different layers into application A or B).  But this
doesn't let you use aspects in the lower layers as more than an
afterthought.  That is, you couldn't implement fundamental behavior of a
lower layer in an aspect and expect that layer's unit tests to run or even
compile.

Another incomplete answer would be to spread aspects across the layers, but
then you have to be extremely careful to avoid the one-weave restriction.
It's not hard to conjure up real applications for which this would not work.

the only approach I know of that would work in all cases is to always
compile everything, but then you lose the build avoidance benefits, and you
increase the risk of library and application code being co-mingled.  Also,
you lose the ability to test/certify a library without regard to the
application that uses it.

Many thanks in advance for your thoughts on this one,
Eric Friedman