[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspectj-dev] Adding and testing a new batch script
- From: Wes Isberg <wes@xxxxxxxxxxxxxx>
- Date: Wed, 03 Mar 2004 11:20:39 -0800
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
Hi Matthew -
To support LTW at the command line I am adding "aj.bat" and its UNIX
equivalent to "/aspectj/bin".
> 1. Should I add methods to "$installer$.org.aspectj.Main"?
It seems like we can just tell people how to do this, since
they probably already have a way to run their programs. If
you wanted to leave the script out, I'd support that. The
scripts can be hard to test and support. (Note that the
aspectjtools.jar now makes the ajc and ajbrowser scripts
redundant, since you can get either by just running the jar.
We don't remove them, though, because people rely on them.)
I'd recommend instead updating the examples/build.xml with
a load-time weaving scenario using the examples (e.g., we
added a scenario for binary weaving by way of demonstration).
(I assume someone is adding to the dev guide docs.)
If you keep it in, would you name it something less likely
to be confused with ajc and more likely to be recognized?
e.g., "java-loading-aspects.bat"? (This sort of brings
up that we prefer "weaving" not to be a part of the
And yes, the scripts are generated by the installer.
2. Are these batch scripts tested directly? If so how?
There's a part of release/product testing that works on the
installed product; they should be tested in that. There used
to be such tests in tests/product.
One benefit of augmenting examples/build.xml is that it's easy
to update the release script to try out the load-time weaving
scenario when it runs the examples/build.xml.
> I don't think I can use the test
harness as is does not support JVM options. I have of course written JUnit
tests to test the new class loader and adaptor directly.
You're right that the harness only supports run forking weakly with
system properties applied to all tests, and this does not support
JVM arguments. While we could upgrade that approach, it's not
likely to make sense in the long run for writing these tests. See
You might think about what you'd want from the harness in this regard
by saying what you'd want the test specification to look like.
It would be nice to make it so tests could be run under different
scenarios (compile, run; compile, compile-weave-binary, run;
Java Technology Centre, MP146
IBM Hursley Park, Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
aspectj-dev mailing list