[aspectj-dev] 1.1.1 taskdef fix - resend

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

Sorry - first version sent prematurely - corrections below...

-------- Corrected Message --------
Subject: [aspectj-dev] 1.1.1 taskdef fix
Date: Fri, 25 Jul 2003 17:47:35 -0700
From: Wes Isberg <wes@xxxxxxxxxxxxxx>
Reply-To: aspectj-dev@xxxxxxxxxxx
To: aspectj-dev@xxxxxxxxxxx <aspectj-dev@xxxxxxxxxxx>

Ron's solution for JSP compiling prompted a long discussion
and the following fix recommendations.  Ron has offered to
test them in any 1.1.1 release candidate.  I plan to do/test
the first two for 1.1.1, absent objections, mainly because
the fixes should be safe/correct, and it would be nice to use
aspects in Tomcat JSP's.

1) no default dest dir [bug fix, but not a written bug yet]

AjcTask should not default to using "." when the dest dir
is unspecified
- javac, the Javac taskdef, and ajc all use the source dir
-> specifying resource copying will now throw a BuildException
   if the dest dir or jar is not specified

This breaks scripts implicitly relying on the bug, but
prevents new scripts from doing the same.

2) hook to modify the ajc command-line [RFE for JSP, et al]

Given an environment variable specifying a class name, the taskdef will
load, instantiate, and call the class to re-process the command line.
The solution is general because there are a lot of environments that
might invoke the task, and we don't want to anticipate all the things
they might want to do.  If there is any standardization possible, we
can work that into the AspectJ distribution.

This should not break any existing clients.

3) Tomcat JSP command-line rewriting [Ron's contribution]

Tomcat compiles JSP's using Ant's Javac task, so the user can
specify our Javac CompilerAdapter to do the compiles.  However,
the user cannot change the ant script to specify adapter-
specific options; even if they could, the options would apply to
all JSP's, but we'd like to support application-specific aspects.

Tomcat does dynamically generate the classpath based on deployed
jars, so it might be possible to deploy specific aspect libraries
to common or application-specific directories and have them show
up on the classpath.

[This is what I understand of Tomcat 4.X from Ron; please correct
me if I've misunderstood or if we've missed a way to configure
JSP compiles, let us know.]

The JSP command-line rewriter could then pull these from the
classpath and put them on the aspectpath, different ways:

1) ignore any differences
Extract all .zip or .jar files paths from the classpath and
put them on the aspectpath.
- Hope ajc always seeks types from the aspectpath.
- Assume all binary aspects are to be woven into all classes

2) tag aspectpath .zip or .jar files for extraction
a) via naming convention, e.g., {prefix}-aspectsToWeave.[jar|zip].
b) via manifest entry {...}

To avoid doing (2), Ron would like to know if (1) would work.

(We presume deploying binary aspects on the classpath will break
javac-based compiles, so the deployer is responsible for only
deploying aspects when using ajc.)

This technique only supports aspectpath entries.  If others
have ideas about supporting JSP compiles, please let us know.

Wes

_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev