[mm-dd] Start of logging on this project. Group memebers are myself and Ankit Shah. [02-05] Made directory xaspects in my home directory on my cygwin box. First task is to recover the project task list from my Sun account, which has all of the information. Ultimately it would be good if Ankit and I could maintain the same project space with CVS or SCCS. (Bringovers to and from NEU might be tricky. Maybe NEU has a nice server.) A search on google shows that xaspects isn't a very common name, so it will be good enough as a working name for this project. [02-05] Created directory examples in the xaspects directory. Moved in Karl Lieberherr's FileSystem example (the first complete example of XAspects's syntax) to that directory. [02-06] Still the same entry, but I guess that's what you get for starting a log at 11:55 PM. Recovered task list and put it in the main directory. It's already time to make a global Makefile for the project, as those pesky emacs~ files are being created. Also need rule to tar up this whole directory for transfering and backup purposes. [02-06] Moved the previously obtained DAJ (from daj.sourceforge.net) source to xaspects/daj-5 (A daj.jar file sits in my ~/lib and my CLASSPATH. Should be sure not to use that copy, which doesn't contain the sources anyway.) The build instructions for DAJ are simple, but require demeterj: demeterj && jar cmf manifest.mf ../daj.jar -C classes . Reading the DemeterJ page, it seems I need JavaCC first. And that means I'll need J2SE 1.4.1_01 for javac (I've been getting away with ajc inplace of javac until now). Went to java.sun.com looking for the Windows SDK. Started download of j2sdk-1_4_1_01-windows-i586.exe I first searched for javac specifically for cygwin (before even going to the Sun site), but that just came up with wimps who don't know how to run Windows commands from a cygwin shell... in other words, a wild goose chace because there's no reason javac for Windows wouldn't work perfectly with Cygwin. Changed my PATH to include javac. My philosophy with Makefiles is to have the Makefiles use the tools found in the path instead of specifying which version to use. Downloaded JavaCC2_1.zip. Looks like this is one that you actually do want to unzip, because the JavaCC2_1.class file is the installer. Ran: java -cp . JavaCC2_1 Changed my PATH to include javacc. Created a version rule in the Makefile to record the versions of java, javac, and javacc that I'm using. Downloaded demeterj-0.8.6.jar. Unzipped it. Removed the previous rt.jar file from my ~/lib directory and its entry in my CLASSPATH. Put the bin files in my PATH. Made the demeterj Bourne script executable and edited its DEMETER_HOME value to fit the location at which I installed it. Put the new location of rt.jar and demeterj.jar into my CLASSPATH. Had way too many cygwin related problems with putting it in my "Program Files" directory, so now I'll try it in C:/ instead. Changed my PATH, CLASSPATH, and the demeterj script accordingly. But I still get NoClassDefFoundErrors. (I changed the :s to ;s for the CLASSPATH separators.) Using the .bat file seemed to fail even more. [02-07] Finally back home from work and starting again with getting demeterj working with cygwin. I ended up copying the ajc script and changing it, which worked quite well for me. It ends with a "Signal 127," however. I'm beginning to think my whole CLASSPATH is suspect. I removed all references to the CLASSPATH from the script (so it would force the real one (which I fixed by removing all "cygdrive" references), and that seems to be going along pleasantly). Changed Makefile to record demeterj version too. It appears that "Signal 127," or something unrelated, makes it return a non-zero exit status. So, I put a "-" in front of its run in the Makefile so make would ignore the problem. Ran demeterj new demeterj test to test demeterj. It's taking a while, but it doesn't appear to be generating error codes. I'll put the two rules into my Makefile raw to be sure they aren't returning weird codes anyway. At the end it says "It works!" (see http://www.ccs.neu.edu/home/matthias/ for a different interpretation). [02-07] Time to consult the task list to see what is next. After I get the examples from Ankit it will be good to test them out here. But first, I read up a little more about Ant. Sounds like a platform independent way of doing Make-like files. Ah... even before checking the task list I realize that compiling DAJ is my prime directive. Despite all of this Ant stuff, I think I'll use a rule in the Makefile to get myself started (work with what you know; solve the core requirements first). Changed the daj-5/src/build.sh script to use tcsh instead of csh (don't have csh installed). But since the script is only a one liner, it would be best to just put them in a Makefile. The oneliner also short-curcuited itself because of the Signal 127 problem again, but this time it looks legitimate: Adding Enumeration thingies to Repetition classes Adding Subtraversal class. Generating core aspect code to gen... Generating grammar to gen\Parser.jj... Done. Running the weaver... Running the parser generator... java.io.IOException: CreateProcess: javacc -OUTPUT_DIRECTORY:gen gen\Parser.jj error=2 Signal 127 It's at this point I wished I had a clean rule to get back to where I was with the daj-5 sources. I can always remove and reinstall, though. [02-07] Let's see what is involved with making a clean workspace: > tar tzf /cygdrive/c/Archives/daj-5.tgz | sort > clean-files.txt > ls -d daj-5/src/* > dirty-files.txt > diff clean-files.txt dirty-files.txt 1,3d0 < daj-5/ < daj-5/daj.jar < daj-5/src/ 15a13 > daj-5/src/build.sh~ 17a16 > daj-5/src/gen Excellent, this means just *~ (emacs) files and the gen directory need to be deleted. I added some commands to do so in the clean rule of the Makefile. Let's try again. > cd daj-5/src > ./build.sh It still has the error when trying to do a "CreateProcess" of javacc. And I still have a hunch that it uses the PATH. Perhaps a soft-link to javacc in my own ~/bin directory would work. Or maybe the Windows centric program will choke on that too! So, I should probably start looking at the Windows equivalent of a path instead. (BTW, I guess the Windows centric program to which I refer is java itself.) Searching the web for how to set the Windows path I came upon: http://java.sun.com/j2se/1.4.1/docs/tooldocs/findingclasses.html which might be useful for later reference. Ahh... I need to use the System utility in the Control Panel. For reference, my Windows path was: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem and I changed it to: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\javacc2.1\bin We'll see if that space causes problems. In fact, for the moment I just assume it will (hope that doesn't signal impending irony). I'll change it to: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\PROGRA~1\javacc2.1\bin instead. Removed the soft-link I had in my ~/bin directory (not needed anymore). Hehe, I still get the same error. Maybe I need to log back into the Cygwin session. Shoot, that did no good either. The DemeterJ page says to add the DemeterJ bin directory to the Windows path. Don't see any reason not to. My path is now: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\PROGRA~1\javacc2.1\bin;C:\demeterj-0.8.6\bin It's funny how javcc can be started by demeterj with no problem with "demeterj test". Sent an email to Doug asking about the problem. Perhaps I'll have to build my own demeterj to troubleshoot this afterall. As always, Doug sent a great reply: From: "Doug Orleans" To: "Macneil C. Shonle" Subject: Re: DemeterJ and Cygwin Date: Fri, 7 Feb 2003 15:00:22 -0500 (EST) Macneil C. Shonle writes: > Running the parser generator... > java.io.IOException: CreateProcess: javacc -OUTPUT_DIRECTORY:gen > gen\Parser.jj error=2 > Signal 127 > > The funny part is that > > demeterj new > demeterj test > > works. Huh, it's a bug in DemeterJ. When you generate a new .prj file, it checks the OS to decide whether to put "javacc" or "javacc.bat" for the PARSEGEN option. But when you remove that option altogether from the .prj file (which I did for daj.prj), the default is always "javacc" without checking the platform. I'd fix this, but DemeterJ will be going away soon anyway. In the meantime, you'll just need to add a "PARSEGEN=javacc.bat" line to the .prj file when you're compiling DAJ on Windows. --Doug ******************************************************************************* Took this time to start reading up on John J. Sung's DAJ work: http://www.ccs.neu.edu/research/demeter/DAJ/ These readings inspired me enough to work on the plug-in architecture. Created file AspectPlugin.java to demonstrate the interface I wanted. [02-07] Made a web-page for the project. It was a good exercise in communicating the main idea, and also a place to keep track of the project documents (this will have to be open source because we're leveraging open sourced code). And also good for making links to the related projects. [02-07] A re-run of the DAJ compilation with Doug's fix revealed: Parser generated successfully. Running the compiler... DAJ.java:417: package antlr does not exist exitValue = new antlr.Tool() { ^ DAJ.java:666: package org.aspectj.bridge does not exist org.aspectj.bridge.MessageHandler mh = ^ DAJ.java:667: package org.aspectj.bridge does not exist new org.aspectj.bridge.MessageHandler(true); ^ DAJ.java:668: package org.aspectj.bridge does not exist mh.ignore(org.aspectj.bridge.IMessage.INFO); ^ DAJ.java:669: package org.aspectj.tools.ajc.Main does not exist mh.setInterceptor(org.aspectj.tools.ajc.Main.MessagePrinter.TERSE); ^ DAJ.java:670: package org.aspectj.tools.ajc does not exist new org.aspectj.tools.ajc.Main().run(args, mh); ^ DAJ.java:671: package org.aspectj.bridge does not exist int exitValue = mh.numMessages(org.aspectj.bridge.IMessage.ERROR, false); ^ 7 errors Aborting, compiler exited with error value 1. Signal 127 The file aspectjtools.jar is not in my CLASSPATH, so that's where some of these errors are coming from. Let's try and fix it. [...] OK, put it in my path. Woo woo! Now here's what we get: Parser generated successfully. Running the compiler... DAJ.java:417: package antlr does not exist exitValue = new antlr.Tool() { ^ 1 error Aborting, compiler exited with error value 1. Signal 127 Time to get and install ANTLR! Got antlr-2.7.2.tar.gz from the main page. The installation was just an untarring and a CLASSPATH setting. I'm getting to like installing pure Java programs! Now is a good time to back up and upload what I've spoken of so far. The DAJ build worked! (In so far that it did not generate an error message.) Time to make a daj-examples directory to put DAJ tests in. First, I'll remove the previously installed daj.jar I had put in my ~/lib. And then change the CLASSPATH to use the built copy. [02-08] Starting reviewing this log and discovered that a daj.jar file already exists in the daj-5 tar (and therefore in the unpacked directory). Because I don't know how well jar writes over existing files, I should put in a remove command in the clean rule of the Makefile to get rid of it. Added an "all" rule to build daj. Fixed a spelling mistake in the log (revisionist history, you know). Trying to run DAJ, but get NoClassDefFoundErrors. Ends up I was using the wrong name. The correct way to invoke it is: > java edu.neu.ccs.demeter.tools.daj.DAJ I'm actually curious how the setenv of my CLASSPATH translates to the Windows exectuable's environment. Downloaded daj1.1 again, to grab the basket and basket2 examples. Unjarred them in my daj-examples directory. This gives me the following examples: basket: BasketMain.java BasketMainCount.java BasketTraversal.trv basket.bat basket2: BasketMain.java BasketTraversal.trv BasketVisitor.java ccg: CreateClassGraph.java I'll probably have to redo the compilation files for these, because they use the old path to DAJ (it does not contain "tools," which is what was throwing me off before). The "-gpa" flag was not accepted when trying to compile the basket example. It's for "generate printing advice"-- mayhaps that's the default now. I'll remove it. (Doug was right that the documentation for DAJ was sketchy. Well written, but what I've found is out of date.) Funny, neither is the "-cgg" flag accepted. [...] And neither is "-main". I guess these flags were kind of krufty to start with, so it would make sense for them to go. I wonder what luck Ankit has had with assembling many different, interesting DAJ examples (I'm not sure he knows this yet, but those examples will become test data later on). It's possible too that the syntax of the .trv files has changed enough that they wouldn't work either. Looks like the -o and the -d flags are all that matter. And the defaults seem good enough. Ahh... seems like I'm getting just that problem: %I - generating traversal file stubs BasketTraversal.trv 1 exception: edu.neu.ccs.demeter.tools.daj.ParseException: Encountered "ClassGraph" at line 3 , column 5. Was expecting one of: "}" ... "declare" ... Time to write off these examples and find something newer. The current homework assignment actually uses a DAJ example, so might as well use what's guaranteed to work (is that more or less canonical, I dunno). BTW, I should probably email John J. Sung and let him know about this project. Started to compile hw4, but ran into errors with the generated stubs: C:/cygwin/home/Administrator/xaspects/daj-examples/hw4/gen/statisticsParsing.jav a:17: Unreachable catch block } catch (antlr.ANTLRException e) { throw new RuntimeException(e); } It's ajc that's complaining here. Let's look at this file. Here's the header of the file: // This file was generated by DAJ from statistics.cd. So, looks like maybe antlr changed in the meantime and wouldn't be throwing this kind of exception anymore? Time to grep in the DAJ sources for this error message. Maybe a simple workaround is possible. (Good excercise for getting to know the DAJ sources.) I wish I had my cscope tool here like I do at Sun. But it's a Java-ish program anyway. I'll need to use grepsrc instead: > alias grepsrc 'grep -n \!* `find . \( -name "*.java" -o -name "*.beh" -o -name "*.cd" \) -print -o -name "*gen*" -prune`' (Yet another thing to put in my .cshrc file!) So, now let's use this: > grepsrc "This file was generated by DAJ from" ./daj-5/src/AspectJTraversal.java:162: "// This file was generated by DAJ f rom " + aspectName + ".trv.\n" + ./daj-5/src/DAJ.java:196: out.println("// This file was generated by DAJ from " + name + ".cd."); ./daj-5/src/GenerateClass.java:27: out.println("// This file was generated by DAJ from " + name + ".cd."); ./daj-5/src/GenerateGrammar.java:21: out.println("// This file was generated by DAJ from " + name + ".cd."); ./daj-5/src/GenerateParsingAspect.java:21: out.println("// This file was gene rated by DAJ from " + name + ".cd."); ./daj-5/src/GenerateStubs.beh:57: "// This file was generated by DAJ from " + aspectName + ".trv.\n" + If you can wade through the above, looks like there are four sources for the .cd case: daj-5/src/DAJ.java:196 daj-5/src/GenerateClass.java:27 daj-5/src/GenerateGrammar.java:21 daj-5/src/GenerateParsingAspect.java:21 Time to check them out. Indeed, in GenerateParsingAspect.java (by reading the names--and if you've been paying attention--this should have been the obvious source), we have around lines 48: out.println(" try {"); out.println(" return parse(new java.io.StringReader(in));"); out.println(" } catch (antlr.ANTLRException e) {"); out.println(" throw new RuntimeException(e);"); out.println(" }"); Perhaps the generated code could be changed to this, instead: out.println(" try {"); out.println(" return parse(new java.io.StringReader(in));"); out.println(" } catch (Exception e) {"); out.println(" if (e instanceof antlr.ANTLRException)"); out.println(" throw new RuntimeException(e);"); out.println(" }"); Otherwise, I would said it's time to leave Dodge! Yet, this change brings up another, but different!, error message: C:/cygwin/home/Administrator/xaspects/daj-examples/hw4/gen/statisticsParsing.java:15: This method must return a result of type Container try { return parse(new java.io.StringReader(in)); } catch (Exception e) { if (e instanceof antlr.ANTLRException) throw new RuntimeException(e); } Interesting that GenerateParsingAspect.java is essentially a constant sized program generator (there's a "preamble" part that is probably linear, but it doesn't seem to be used for this case-- perhaps it's for package, et cetera stuff). Ah, no, on second thought, it's linear in the number of classes in the ClassGraph. The return type errors only seem to be for parts of code generated by the very section I just modifed. Let's try and fix that. out.println(" try {"); out.println(" return parse(new java.io.StringReader(in));"); out.println(" } catch (Exception e) {"); out.println(" if (e instanceof antlr.ANTLRException)"); out.println(" throw new RuntimeException(e);"); out.println(" else throw e;"); out.println(" }"); Time to recompile! (I think if antrl.ANTLRExceptions are no longer thrown the "Unreachable catch block" problem could be avoided by getting rid of the try/catch part altogether. Maybe backwards compatibility is desired, though, so it's not really redundant in those other configurations. Perhaps the exception name has changed is all.) That didn't work, so time to do a more agressive fix: out.println(" try {"); out.println(" return parse(new java.io.StringReader(in));"); out.println(" } catch (Exception e) {"); out.println(" throw new RuntimeException(e);"); out.println(" }"); When this works the solution will be emailed to Doug to see if this still has the desirable semantics. ... And it does work (compile, I mean). The executable ran with what I think should be output (not sure, though, because I haven't done the hw yet. Now would be a good time to look at it, but I should get eclipse working first). Message to Doug: To : Doug Orleans Cc : "Macneil C. Shonle" Subject : GenerateParsingAspect.java Hi Doug, I'm working with DAJ from the daj-5 sources and ran into this error while trying to compile a sample DAJ program: C:/cygwin/home/Administrator/xaspects/daj-examples/hw4/gen/statisticsParsing.jav a:17: Unreachable catch block } catch (antlr.ANTLRException e) { throw new RuntimeException(e); } The version of ANTLR I have is antlr-2.7.2. To fix the message I changed line 48 of GenearteParsingAspect.java from out.println(" } catch (antlr.ANTLRException e) {"); to out.println(" } catch (Exception e) {"); That seems to be closest to the desired solution. Is this is a bug? Thanks, Macneil ******************************************************************************* The answer was that it's actually a bug with AspectJ. The newer version doesn't have the problem, but it will be moot to upgrade because I'll be getting all of the sources anyway. [02-08] Started download of eclipse-SDK-M5-win32.zip from http://download.eclipse.org/downloads/drops/S-M5-200302061700/index.php It's not the latest and greatest, but it's the more recent stable build (M5 2.1 Stream, Feb 6, 2003). Might need to download eclipse-Automated-Tests-M5.zip later, too. I'm going to try to avoid downloading the eclipse sources themselves if at all possible (actually, I think the sources are included, but I don't need to compile them). It's nice to know that the test results are posted, and even nicer to know there are zero errors or failures (hehe, unless there are errors in the tests, of course). [02-09] Extracting it using WinZip. Opened eclipse.exe to "install" it. Looks like you can just put it all wherever you want. Too bad I unpacked it on my desktop. Hopefully I can just move it to my root directory. It looks nice and fast. I then opened the "CVS Repository Exploring perspective". Time to find the location to use again to get AspectJ. I right clicked in the CVS Repositories window and selected New->Repository Location and entered :pserver:anonymous@dev.eclipse.org:/home/eclipse (actually, I had to split the four items and enter them into different fields in the dialog box, but, whatever). But the aspectj branch didn't appear anywhere. Maybe I need to specify a different path. So, instead I tried: :pserver:anonymous@dev.eclipse.org:/home/technology which showed me org.aspectj in the list! I right clicked on it and selected Checkout as Project. This started downloading many files. Very cool! Reading up the "welcome" introduction that came up when I loaded the GUI. Hmm... started eclipse from the GUI command line in different directory, and that created a whole other "workspace" directory. It was in my home directory, so I just blew it away (the other eclipse was still running--don't think any harm was caused). Looks like the "Help" menu is actually helpful for eclipse, though. I should remember that. I discarded the previous CVS location I used. Got a little side-tracked looking for AspectJ building FAQs (may need to just look in the modules directory for .html files, which I believe are around). On the FAQ they mention that the parser is handwritten (yay!), so that will make some parts easier with the plug-in. Too bad I assumed it was a grammar (but, it's good to write the grammar out like that anyway). Indeed, the AspectJ FAQ says that dev.eclipse.org:/home/technology is the right CVS Root. It also says: "You can check out the entire modules directory and build using the Ant build script modules/build/build.xml." And some advice on building the test harness: "To build [the test harness] [...] build the build-testing-drivers target: " cd build " ../lib/ant/bin/ant -f build.xml build-testing-drivers "This produces ../aj-build/jars/testing-drivers-all.jar which you can run as described in tests/readme-tests-module.html." Very good to know! In Eclipse I did a "close project" and then an "open project" just to be sure what I was looking at. Then did a "Project->rebuild all." Which doesn't seem to do much of anything. I think I'll look at the Java Browsing feature next, though. Should be a big help in understanding the source code. Had some problems getting it to show me the org.aspectj branch I just downloaded. Strange how it's intuitive and non-intuitive at the same time. [02-09] Having a heck of a time figuring out how to put the project I just checked out into my Java build path. Apparently there's no edit->build cycle. Instead, it's all incremental. Well, either way, I can't view the ajc code because it's not in my path. I managed to see the Java Build Path menu item once, but it was greyed out. Making me wonder if I even have a project or not. I tried some things with the "active working set," but a lot of these guys seem to be NOPs. My interest in Eclipse seems to be fading. Now I just want to use it for the CVS features and to browse the source code (like a Smalltalk browser). Perhaps do builds with it. I'd like to see about editing code using xemacs along with eclipse. Perhaps I should be more patient with such new technology. (And I keep saying that most programming tools are terrible because they haven't even touched what Smalltalk had. Well, maybe they are getting there--I remember the steep curve of learning Smalltalk. Despite how simple the language was.) It keeps talking about opening up a Project and right-clicking on it, but all of the viewers aren't even of project, just Package Explorers and what not, and the "Open Project" menu item is always gray. Eventually I got so frustrated (this does feel a bit like "crippleware," where the key features you want are disabled until you pay) that I created a new Java project. The "Package Explorer" came up list both "org.aspectj" and "StupidTest" (the name of my new package). The StupidTest project had a "J" on the folder icon, while the org.aspect project did not. Strange, not the org.aspect project listing doesn't have any of "build" or "asm" under the modules directory any more. Where did they go? Under "Navigator" they are back. Maybe I just need to build this away from Eclipse's grasp, using Ant: Cd'ed into "modules/build" and tried a: > ../lib/ant/bin/ant -f build.xml Which said: Error: JAVA_HOME is not defined correctly. We cannot execute java So I tried this: > setenv JAVA_HOME "/cygdrive/c/Program Files/Java/j2re1.4.1_01" which at least got me to this error: error building runtime for C:\eclipse\workspace\org.aspectj\modules\build\products\tools: BuildException compiling Module [name=runtime, srcDirs=[C:\eclipse\workspace\org.aspectj\modules\runtime\src], required=[], moduleJar=C:\eclipse\workspace\org.aspectj\modules\aj-build\jars\runtime.jar, libJars=[]][]: Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK Unable to find a javac compiler; So, yeah, well, duh. Why not call the variable JAVA_JDK instead of JAVA_HOME? I should put all of these setting in my .cshrc file, because it looks like I'm going to have to stick with them. I moved the WINNT specific stuff toward the end of my PATH under Cygwin. No need to use that java instead of the j2re one. I'm unsure if I should use c:/j2sdk1.4.1_01 or /cygdrive/c/j2sdk1.4.1_01 for the JAVA_HOME value. The "c:/" syntax doesn't seem to be making it choke, and I think that's probably what it was expecting, so, let's just go with that. Getting lots of "Since fork is true, ignoring compiler setting" messages. Whatever that means. I wonder how well this Ant build will play with the Eclipse side of things (which I have exited for the moment). It ended saying: BUILD SUCCESSFUL Total time: 9 minutes 8 seconds which, honestly, sounds pretty fast. (Which makes me sucpicious.) So, perhaps now *is* the time to run the AspectJ tests. One of the pages says to run the spacewar example first: >cd org.aspectj/modules/aj-build/dist/docs/doc/examples >/cygdrive/c/eclipse/workspace/org.aspectj/modules/lib/ant/bin/ant -f build.xml But that resulted with: aspectjtools.jar.available: BUILD FAILED file:C:/eclipse/workspace/org.aspectj/modules/aj-build/dist/docs/doc/examples/build.xml:114: expecting aspectjtools.jar at C:\eclipse\workspace\org.aspectj\modules\aj-build\dist\docs\lib\aspectjtools.jar I suppose I didn't do a release build, which would affect the docs directory not getting a file. I don't know if the "-f build.xml" only does a subset or not. Might as well try again: > cd $WORKSPACE/build > ../lib/ant/bin/ant (Got some weird errors in cygwin here... the lib/and directory was gone, but then I closed the shell and opened it again, and, poof, there it was again. Maybe that was related to the .jar not being found? I've been mixing and matching the C:/ and /cygdrive/c forms, could that have any effect?) Either way you slice it, it seems that the .jar has not been created/copied over. [02-10] Got email from aspectj-dev list. Ends up I need to check out each module as its own Java project. So, I deleted the previous org.aspectj project I had. [...] And now I'm checking out each module separately. [...] And then I got weird build dependency issues as I brought over each single space (it would build as it was brought over). Maybe I need to bring over all of the projects at once (by slecting multiple projects). I checked out everything but aspectj-attic (which wasn't mentioned on any of the lists). The CVS "Checking out"s are all happening at once (18 projects total), so maybe the build *will* go better. Either way, making sure this gets into the FAQ (a helpful AspectJ dev list member, Wes Isberg, said it would go on the FAQ). I think my "Rebuild all" should have worked, though, so I don't have too many hopes that this will work. But, it sort of does, now there are just 718 items in the Tasks, instead of ~3000, and all of them are warnings or TODOs, not errors! (yay!) [02-11] I changed the "un-needed import" and "deprecated" warnings into ignores, and that forced a rebuild. Obviously the process of the AJC team isn't as strict as it is for Solaris, which forbits any deviatations from lint. Luckily the Java warnings aren't as brain dead as lint. But because the warnings aren't really important, I turned them off. After this build is done I'll see about the regression tests again. This time I'll be sure to read up everything about it first. I upgraded the memory in my machine (to handle Emacs and Eclipse at the same time!-- Hey, these IDEs always start with an E, huh?). Changed the "static reference through non-static object" warning into an ignore. It rebuild, but this time much faster! It appears "ajc" is always a script, generated the installer. However, I think to test the ajc in my workspace, I need only set the ASPECTJ_HOME environment variable and that one would get used instead. I might need to put in a hack in the main that will create a file with the current date, and when I see the results of the hack I'll know the right version is getting used. With just the installed version of AspectJ I got from before (without building the sources), I wanted to run the spacewar example via Ant. Now that I think running my own version won't be much different, this seems like a good place to start! Did a: > cd c:/aspectj1.1/doc/examples/ > $WORKSPACE/lib/ant/bin/ant -f build.xml And then the spacewar game came up! I should remember to look at the Spaceware code. That would be good to test out the aspect browsers with. I "played" spacewar a little bit before quitting (mostly looked and windows and experimented, no real playing except some lame excuse for playing called hitting-the-spacebar-over-and-overandover). Got some weird messages during play: ******************************************************************************* clean: [mkdir] Created dir: C:\aspectj1.1\doc\examples\classes [ajc] Compiling 0 source and 1 arg files to C:\aspectj1.1\doc\examples\cla sses Ajx-run: [echo] ##### Ajx-run list=spacewar/debug.lst class=spacewar.Game [java] java.lang.NullPointerException [java] at spacewar.Display1$SpaceObjectPainting.ajc$interMethodDispatch 1$spacewar_Display1$SpaceObjectPainting$spacewar_SpaceObject$paint(Display1.java ) [java] at spacewar.Display1.paintObjects(Display1.java:69) [java] at spacewar.Display.update(Display.java:98) [java] at sun.awt.RepaintArea.paint(RepaintArea.java:169) [java] at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.jav a:260) [java] at java.awt.Component.dispatchEventImpl(Component.java:3658) [java] at java.awt.Component.dispatchEvent(Component.java:3439) [java] at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) [java] at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDi spatchThread.java:197) [java] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDisp atchThread.java:150) [java] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.j ava:144) [java] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.j ava:136) [java] at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) BUILD SUCCESSFUL Total time: 3 minutes 30 seconds ******************************************************************************* But, as you can see, it ended with "Build Successful". Not sure what they were looking for, but, I guess they're happy. Now the next step is to run all of the regression tests against the installed ajc (Oops, almost said the installed Prism). [02-12] I wonder if the Spacewar game treats periodic boundary conditions as an aspect. Starting reading tests/readme-tests-module.html. I says basically to find org.aspectj.testing.drivers.Harness, in the testing-drivers module, and use the -help command. Not sure what the top-level test is. [02-12] Apparently spacewar really isn't considered a test. [02-13] Got another email from Wes about testing. I've been going about it the wrong way. Here are the steps, and I quote: ******************************************************************************* As an eclipse user, you need neither Ant nor command-line scripts. Just: - check out the modules as projects, which you've done - eclipse builds them - run the JUnit tests or compiler or test harness from eclipse - Run the JUnit tests by selecting any JUnit test source file from the Java perspective and running as a JUnit test - Run the compiler from the org.aspectj.ajdt.core project using the main interface org.aspectj.tools.ajc.Main (i.e, run org.aspectj.tools.ajc.Main as a java application) - use the normal command-line - Run the test harness from the testing-drivers project using the main interface org.aspectj.testing.bridge.Harness (...as a java application) - use -help to see options. My normal command line is like this: ... ../tests/ajcTestsFailing.xml -logFail -verbose If you must run from the command-line, build your target using ../lib/ant/bin/ant and execute the jar files in .../aj-build/jars. Targets of interest are listed in build/build.xml. Try - ajbrowser-all (produces jars/ajbrowser-all.jar) This contains ajbrowser and the compiler. The main class/method will invoke the AspectJ compiler normally or ajbrowser if there are 0 or only .lst file arguments. - build-testing-drivers (produces jars/testing-drivers-all.jar) This contains the test harness and compiler. Let me know if that works. Wes ******************************************************************************* So, now the first step is to find a JUnit test source file. Under weaver/testsrc I selected "fluffy" and selected Run->Run as->Java Unit Test. That didn't do much of anything, but then I ran org.aspectj.weaver and that brought up a JUnit tab and showed the testing progress. It ended with 10 out of 10 tests passing. [03-01] Trying out something different this time. Spent most of my time working on the spec with Ankit. After answering some questions about the interface that Gong Jun had I realized it could be simpler and easier to understand. Had a heck of a time compiling AspectJ, and in particular getting the changes I've made to the source in Eclipse to actually work. I think the only way I'll get this working is if I forget about Eclipse building anything and instead just use a good old makefile as a wrapper around this Ant stuff. No one ever said that things related to XML should be *directly* used by a human. A wrapper executable called, say, xajc, is going to be written to simplify the coding task involved, considering how much time was lost just getting ajc to build correctly. To test my building script I'm going to (again) do a fresh bringover of the modules, this time I'm putting them in xaspects/modules I'll ignore the Eclipse options and just see where this gets me. This build might take a little bit, so now is a good time to practice the guitar. [..] Hmm, wow, my thumb started to hurt before the compilation was even done. Weird. Maybe it's going to finish soon, though. I think Eclipse is pretty cool, but it's just not well documented when it comes to using it for a large Java program that spans multiple projects and creates several jars. I think I need to re-adjust the "Ant settings" somewhere, but don't know where. My test of editing/recompiling the builds is with the ajc main, which is in org.aspectj.ajdt.core`src`org.aspectj`tools.ajc`Main.java All I know is, when this is done, and I really figure out this Ant stuff, I'm going to release wrapper Makefiles for the die hards! Good, now that it's close enough to working I can start changing the grammar! I'm going to only focus on ajc compiling with a single source file for the moment, which, given the current system, wouldn't really affect the power, since everything could be put in a single file (and examples for others are best as a single file anyway). A slimmer version of the FileSys example will do (and by slimmer I mean just the ClassDictionary plug-in, which Ankit has already finished). But I guess even before then it's time for Hello, world! Hmm, looks like one good reason to compile in cygwin and not Eclipse is that you can use Eclipse to browse source code while waiting for the compilation (I believe Eclipse won't let you browse and build at the same time). Did a case insensitive search for all '*parse*' methods. [03-06] Well, the AspectJ development log will have to come to a close. Things are too instable for continued development so a light-weight wrapper aproach will be used instead. After we get more experience with the plug-ins and the interface we'll try to modify AspectJ again. Until then, this can of worms is being closed.