Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-dev] 1.1.1 taskdef fix

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.

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, and
prevents new scripts from doing the same.

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

We provide a hook for tools to preprocess the ajc command-line.
The first client/use will likely be to support Tomcat 4.x JSP compiles.

Given an environment variable specifying a class name, the taskdef will
load, instantiate, and call the class to pre-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, but will require
making the hook classes visible to the taskdef.

3) Tomcat JSP command-line rewriting

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 we could, these 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 configureJSP confi

(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.)

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 .zip or .jar files for extraction
a) via naming convention, e.g., {prefix}-aspectsToWeave.[jar|zip].
b) via manifest entry {...}








Back to the top