[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] Re: Adding and testing a new batch script
|
I'm ok with providing a script in examples/, and with the
name aj though I prefer ~launch~.
In any case, the approach should be documented in the dev
guide. (imho a script in the dev-guide and/or sample-code would
mean none is needed in examples/, since examples/build.xml
would demonstrate LTW using the <java> task.)
> Let's put [the script] in with the examples, and also add an entry to
the
> build.xml file there that exercises it
I'm not sure we want to put in doc/examples/build.xml code to *exec*
a script for test purposes, since we're not really recommending
that people use Ant to exec these scripts. examples/build.xml is
a great place to use the <java> taskdef to directly fork with LTW.
For testing scripts, there's the unused tests/product/makeTestBat.sh
and tests/product/product-test.xml targets like test.script.telecom
or build.source.call, in case someone wants to revive this approach.
Wes
Adrian Colyer wrote:
Seems like there are a number of decisions to separate out here:
1) Should we provide some form of script for simple load-time aspect
binding? (choose your preferred phrase)
2) Where should we put it and what should we say about it?
3) What should we call it?
We need to reach consensus on this soon, here's my current thoughts:
1) Should we provide some form of script for simple load-time aspect
binding? (choose your preferred phrase)
Yes, I think this is a very practical and easy way to demonstrate the
load-time aspect binding capabilities we're building into the class loader
adapter. The script that Matthew has proposed is very simple and ought to
impose minimum burden.
2) Where should we put it and what should we say about it?
Not in the bin directory. This will be the first time we've made the
feature so easily available, and we know the script won't be perfect first
time out. Let's put it in with the examples, and also add an entry to the
build.xml file there that exercises it (with the by-product that this will
get run in our release testing too - thanks to Matthew for pointing that
out). We can tell users that there is a sample script they should feel
free to use, alter, and experiment with, and that we would like feedback
on its evolution. If the script matures and stabilises, we can consider
promoting it to the bin directory in a future release.
3) What should we call it?
I initially started in the camp that said it should be called "aj" (since
"aj" is to "ajc" as "java" is to "javac"). I can also see that a
2-character script name can be easily entered by mistake (though should be
harmless). Since it will be in the examples directory, not in bin, I think
"aj" would be perfectly acceptable - but names tend to stick, and if folks
prefer say "ajlaunch" (my second favourite name) you won't find any
complaints from me.
-- Adrian
Adrian_Colyer@xxxxxxxxxx
Wes Isberg <wes@xxxxxxxxxxxxxx>
Sent by: aspectj-dev-admin@xxxxxxxxxxx
08/03/2004 17:36
Please respond to aspectj-dev
To: aspectj-dev@xxxxxxxxxxx
cc:
Subject: Re: [aspectj-dev] Re: Adding and testing a new
batch script
If you can provide scripts that will work for everyone and
tests to prove that (and promise to support it), then cool.
Otherwise, putting command-line scripts for LTW in the bin dir
is not a good idea. If we can't provide something that works
for everyone, it will be a headache to maintain and support,
since this promises to be a high-traffic feature.
We can provide an easy "out of the box" experience with
a testable Ant build script and a sample scripts in the
documentation. Most everyone who uses it will have to
modify the script for their usage anyway.
For most users, the script will be different depending on
whether they are running pre-1.4, 1.4, and (Sun's?) 1.5 or
later and their own host of options (including multiply-
quoted property definitions and more parameters than DOS
supports?). So an example that works under controlled
conditions is supportable and useful, but a general-purpose
script is probably not.
Aspectwerkz (and java-assist and JMangler and...) were cited as
examples of weaving classloaders, and AW was cited for usability.
But that doesn't mean we should deliver scripts as AW does,
if our OOB experience is just as good. As you noted, theirs works
in pre-1.4 VM's using bootclasspath and/or hotswap to replace
the system class loader, which we're not going to propose to
users. So AW has a strong reason to use a script that we
don't, and if we provide a script we'll have to answer the
question "Why doesn't this work on 1.3?" or "How do I pass
these option?" or "Your script failed to handle this
really long command line" lots of times.
Wes
Matthew Webster wrote:
It seems like we can just tell people how to do this,...
I think we should take our lead from other AOP projects like AspectWerkz
that offer a command line script "aspectwerkz" to perform binary
weaving.
Also there are quite a few options to be supplied to the JVM so
providing a
script will help people to get it right.
I'd recommend instead updating the examples/build.xml ..
We certainly need to do this especially to show people how to build
aspect
libraries suitable for LTW. The approach is slightly different from
binary
weaving where it is popular to compile a concrete aspect that extends
the
library at the same time as weaving. This must be done ahead of time
for
LTW.
If you keep it in, would you name it something less likely to be
confused
with ajc ...
Agreed but perhaps something a little shorter like "aj-launcher.bat"
Matthew Webster
AOSD Project
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
http://w3.hursley.ibm.com/~websterm/
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev
