[aspectj-dev] AJDT Development Principles and Vancouver Release Plan.

["Adrian Colyer" <adrian_colyer@xxxxxxxxxx>]

We've been discussing plans for the
next major release of AJDT (codenamed "Vancouver"), In this series
of mails I want to lay out the objectives for the Vancouver release, and
then start a discussion about how we best should tackle them. Here's a
set of guiding principles to shape what we do:

(Martin, Kai - I've copied you on this
first mail, the follow-on discussion should happen on ajdt-dev if you are
interested in following (and contributing) to our design discussions...).
Same goes for aspectj-dev subscribers.

Principles:

1) Don't break the JDT tools.
When you install AJDT, there should
be no impact on your Java projects in Eclipse. Note that we currently break
this rule in a number of ways (mostly because editor associations are global
in Eclipse) - we use the AspectJEditor for all .java files, and we turn
off early error annotations etc..

2) Files with a ".java" extension
only contain Java source code. 
In practice this means that all aspects
need to be declared in files with a ".aj" extension (and the
new NewAspectWizard now supports this). There are ramifications for classes
that use AspectJ features too. How we handle extensions is a difficult
topic and the subject of another note.

3) We control the glass.
Don't present the user with menu options
etc. that are not applicable (or not yet working) in AspectJ projects.
This may have ramifications for the way we integrate (or not) with the
JDT views. We should delegate to the JDT classes to reuse as much function
as we possibly can wherever possible of course.

4) TDD.
Nothing gets into the new AJDT without
a solid test base in place first. Erich Gamma's new book "Contributing
to Eclipse" has good examples of how to do TDD for plugin development.

5) Production Quality
No short-circuiting on error handling,
full II8N etc. 

6) Built using AspectJ and AJDT
We will use our own language and tools
to build AJDT - it's the best way to harden the tools and make sure they
work well for everyday development, and it also creates a large open source
AspectJ project as a reference.

7) Good Eclipse Citizen
Obey the Eclipse platform rules (again,
see Erich's book), and exploit the facilities of the Eclipse platform fully.



And here's a draft of the plan content:

Vancouver Plan Content:

Restructure:
We need to undertake another restructure
of the core AJDT plugin for Vancouver, to move AJDT into the realm of product-level
quality. This time around the focus is on pulling out common functions
into utility classes, cleaning up the code, and putting in place a solid
unit test foundation as we go that will serve as a basis for delivering
high quality releases.  We will also switch to building AJDT as an
AspectJ project, and will be introducing enforcement aspects and also functional
aspects as part of the refactoring work. How we go about this restructuring
is the major topic of the next few emails...

One option to investigate here is whether
we can leverage the JDT tests or test-fixtures to get a leg-up on AJDT
testing.

AspectJ Model :
The end-user items enabled by this are
full incremental compilation (w. structure model generation), eager parsing
which gives eager outline update, and inclusion of AspectJ structural elements
in views such as package explorer and type hierarchy, and a public API
and extension points for other plugins to build on top of us. This will
require coordinated activity across the AJDT and AspectJ projects.

AspectJEditor rewrite:
Rewrite this as a principled extension
of the Java editor, following the example set in the JDT family examples
plugin. We had extensive discussions with Kai about the best way to do
this, and I will summarize in a follow-on note. Will be based on document
partitioning to divide responsibilities between Java and AspectJ partitions.

AJDT Scalability:
Needs to be done in conjunction with
AspectJ project. Doesn't make sense to start on this until the AspectJ
Model work is done as any measurements we take will be invalidated.

Cross-Reference View:
We've been working on a separate view
that shows crosscutting structure, so that this information will be available
from any selected item in any view, not just in the outline. It is also
better for navigation. A couple of changes need to be made yet - the architecture
is open so that relationship providers can be plugged in, currently we
eagerly initialise them, we should do so lazily. Will also build an "in-place"
cross-reference view akin to the in-place outline. This gives relationships
"on-demand" even when the main view is not open. Finally, the
view tracks workbench selections, but not in-editor selections. We need
to add that functionality. Then we will write an AspectJ provider and move
relationships from the outline view (preparation step for main JDT model
integration work).

New Aspect Wizard:
For various reasons (complex) it is
not possible to create aspects using the ".aj" extension from
the current new aspect wizard (which is a subclass of the new class wizard).
If you look closely, the wizard also has some options that are not strictly
appropriate. The new aspect wizard has been rewritten to avoid this problem,
and a preference added to indicate whether .aj or .java extension is preferred.

(Complete)

Integrated Samples:
The AspectJ samples and examples will
be integrated via a simple "new -> examples -> aspectj examples"
wizard. It is easy to add new examples into the plugin with no extra programming.

(Complete)

Pointcut Wizard:
We've begun work on a set of wizard
pages that make it easy(/ier)  to enter pointcut definitions, These
will be packaged into a new -> pointcut wizard.

Crosscutting Delta View:
This compares the results of a project
build to the previous compilation. Tells the user of any new aspects, and
any differences in advice / itd matching since the last compilation. (Assists
in catching unintentional side-effects of refactoring, until AJDT properly
integrates with eclipse refactoring apis).

(First version complete, more work in
progress)

Code formatting, code completion,
organise imports (etc.):
Like to get at least these three into
the Vancouver release (they are the major pain points). They will happen
as part of the AspectJEditor rewrite. Code completion is now working to
a first approximation.

Debugging:
Build on the JDT debug support, but
filter out aj-synthetic items. More step options? (eg step with/without
advice)

(Mik, Julie - you may have plan items
you want to add to this list).

-- Adrian
Adrian_Colyer@xxxxxxxxxx