From 632b63757bd557c60764dc55c7f7b5716cd6b363 Mon Sep 17 00:00:00 2001 From: aclement Date: Tue, 16 Dec 2008 18:51:17 +0000 Subject: 163 readme --- docs/dist/doc/README-163.html | 84 +++++++++++++++++++++++++++++++++++++++++++ docs/dist/doc/index.html | 1 + 2 files changed, 85 insertions(+) create mode 100644 docs/dist/doc/README-163.html (limited to 'docs/dist/doc') diff --git a/docs/dist/doc/README-163.html b/docs/dist/doc/README-163.html new file mode 100644 index 000000000..253d5739f --- /dev/null +++ b/docs/dist/doc/README-163.html @@ -0,0 +1,84 @@ + + +AspectJ 1.6.3 Readme + + + + +
+© Copyright 2008 Contributors. +All rights reserved. +
+ +

AspectJ 1.6.3 Readme

+ + +
+ +

Split matching/weaving

+

The main goal of AspectJ 1.6.3 was to make the line between matching and weaving more explicit and +introduce the notion of a matcher artifact. This matcher would enable reuse of the semantics of +AspectJ pointcut matching without including the unnecessary code that is the weaver. Why? In some +environments, for example Spring AOP, the weaving may be done in an entirely different way and the +default weaver included in aspectjweaver.jar is just unnecessary code. Some users also find they have trouble getting +approval for using the 'aspectjweaver.jar' in their projects because it includes a bytecode +modification library, even when they are not using that code. +

The result of this work is documented in bug 246125 +and there is now a new jar file in the distribution called org.aspectj.matcher.jar that includes +a first pass at the matching code. It is not quite as slimmed down as it could be but is a first +pass that includes no bytecode modification toolkit. +

To use this matcher standalone it simply requires an abstraction of some type system to be plugged in. +The matcher code can then be used to parse standard pointcuts and answer questions about whether they match against +that type system. There is no documentation on how to do this yet, as we don't think many users will +be contributing new type systems, but internally we are working on an Eclipse JDT type system abstraction that will +enable us to show matches in AJDT without actually compiling code (currently the two type system abstractions +we ship are bytecode based and reflection based - both of which require compilation). +

+ +

Bugs fixed

+

The complete list of issues resolved for AspectJ 1.6.3 (more than 50) can be found with +this bugzilla query: +

 +

During 2008, there have been four AspectJ releases, fixing almost 200 issues. +

+ +

Notable bug fixes

+ + + +
+ +

What's next?

+ +

The JDT World should be completed in the 1.6.4 timeframe and that will surface as benefits in AJDT, possibly leading to better +LTW tooling. Some improved syntax for intertype declarations is a possible candidate feature (see discussion in +this mailing list thread). +A possible introduction of a code style syntax for the mixin style that is @DeclareParents (and a renaming of +@DeclareParents to perhaps DeclareMixin or DeclareDelegate). + +

+ + + + diff --git a/docs/dist/doc/index.html b/docs/dist/doc/index.html index af371fc32..a77affe2b 100644 --- a/docs/dist/doc/index.html +++ b/docs/dist/doc/index.html @@ -138,6 +138,7 @@ README's Changes and porting guide for AspectJ + 1.6.3, 1.6.2, 1.6.1, 1.6.0, -- cgit v1.2.3