[aspectj-users] Binary dependencies on the Aspect Path

["Andrew Eisenberg" <andrew@xxxxxxxxxxxx>]

When working in Eclipse, it is common practice to add the output
folder of one project to be on the aspect path of another project.
This, however, is not the proper way of adding dependencies between
projects.

In the past, this was done because there was no other option to put
aspects on aspect paths.  This causes a problem in that it may cause
spurious second builds of projects after a full build.

Since AJDT 1.5.3 and the latest dev version of AJDT 1.6, the proper
way of adding dependencies between projects is to add the project
itself to the aspect path.  This will cut the time for a full build by
almost one half if there are many aspect paths being used.

For those of you interested in the details as to why there are
spurious builds, continue reading.  Everyone else may simply move on
to the next message in your inbox...

After a full build in Eclipse, all output folders have been wiped and
recreated.  If there is a project that depends on a binary folder that
is the output folder of another project, the timestamp on the contents
of the binary folder will be newer than the timestamp on the source
folder of the dependent project.  This will cause a second build
*after* the full build completes.

An illustration may make this more clear:

Consider a dependent AJ project A that has the binary folder B/bin (of
an AJ project B) on its aspect path. Here is what happens on a full
build:

1. A & B's output folders are wiped clean
2. Projects A & B are built in an unspecified order (actually, the
order seems to be alphabetical)
3. Since Project B's bin folder may be empty when project A is built
project B's aspects may not be woven into Project A (this will occur
if project A is built first).
4. Regardless of the build order, after the build completes, the
timestamp on Project B's output folder is new than the timestamp on
Project A's source folder.
5. This causes a second build, incremental in Project A so that its
source files are properly woven with B's binary files.

The result is a correctly woven project A, but it takes an extra build
to get there.  Again, the solution is to use project dependencies
instead of binary dependencies.

I will soon be adding a check to the build path that flags the user
when there is this kind of binary dependency.

--a