Community
Participate
Working Groups
Here's a couple of examples of what happens: // - - - - - - - - - - - D:\work\workspace\declareErrorBugProject>ajc -d bin -cp c:\programs\junit3.8.1\j unit.jar @.generated.lst D:\work\workspace\declareErrorBugProject\test_src\fi\napa\tabletransfer\Transfer TableTestBase.java:3 error The import junit cannot be resolved import junit.framework.TestCase; ^^^^ D:\work\workspace\declareErrorBugProject\test_src\fi\napa\tabletransfer\Transfer TableTestBase.java:5 error TestCase cannot be resolved or is not a valid supercl ass public abstract class TransferTableTestBase extends TestCase { ^^^^^^^ 2 errors D:\work\workspace\declareErrorBugProject>dir c:\programs\junit3.8.1\junit.jar Volume in drive C has no label. Volume Serial Number is B4B5-E891 Directory of c:\programs\junit3.8.1 04.09.2002 23:29 121 070 junit.jar 1 File(s) 121 070 bytes 0 Dir(s) 15 309 500 416 bytes free Note: I use the exact same junit.jar when I compile the project from Eclipse AJDT and it works fine there. // - - - - - - - - - - - The options -cp and -classpath do not seem to act the same (the only change to the above is changing -cp to -classpath): D:\work\workspace\declareErrorBugProject>ajc -d bin -classpath c:\programs\junit 3.8.1\junit.jar -argfile .generated.lst warning couldn't find aspectjrt.jar on classpath, checked: error can't find type org.aspectj.lang.JoinPoint // - - - - - - - - - - - - - - - - - - - - - - - - - - Ok, so I tried including aspectjrt.jar: D:\work\workspace\declareErrorBugProject>ajc -d bin -classpath c:\programs\junit 3.8.1\junit.jar;c:\aspectj1.2\lib\aspectjrt.jar @.generated.lst error directory does not exist: c:\aspectj1.2\lib\aspectjrt.jar error no sources specified D:\work\workspace\declareErrorBugProject>dir c:\aspectj1.2\lib\aspectjrt.jar Volume in drive C has no label. Volume Serial Number is B4B5-E891 Directory of c:\aspectj1.2\lib 01.06.2004 16:54 34 921 aspectjrt.jar 1 File(s) 34 921 bytes 0 Dir(s) 15 309 533 184 bytes free D:\work\workspace\declareErrorBugProject>type .generated.lst D:\work\workspace\declareErrorBugProject\src\fi\napa\tabletransfer\link\Key.java D:\work\workspace\declareErrorBugProject\test_src\fi\napa\tabletransfer\Transfer TableTestBase.java D:\work\workspace\declareErrorBugProject>ajc -version AspectJ Compiler 1.2 built on Friday May 21, 2004 at 15:06:22 GMT
I forgot to mention that the compilations work fine if I include the junit.jar in my CLASSPATH environment variable and omit the -cp/-classpath option totally.
1. The -classpath option will override the CLASSPATH environment so you need to specify all your dependencies. 2. I too have been having trouble using AspectJ 1.2 final on the command line. Try enclosing certain arguments in (") e.g. -classpath "...". Also I have been unable to reproduce the problems with the latest development level so you may want to try that.
1. I know. This is a very small sample project I used on another bug report - it doesn't depend on any other external libraries besides junit and AspectJ (I added the AspectJ jars to the -cp option, although that doesn't help w/ the error of not finding the junit classes). 2. The latest dev build seems to work fine with -classpath option. However, with the -cp option the same problems still appear. I believe the -cp should be just a shorter alias for -classpath, so the behavior should be identical . This might be something to look into.
This bug may be related to bug 73433. Under that bug I fixed the problem where -cp meant something different to -classpath. However, if it is the same issue, I'm confused as to why the latest dev build is still not behaving itself. When you have tried the latest dev version, have you set everything up correctly to ensure you don't exactly run the old version? When the ajc.bat file runs, it sets the field ASPECTJ_HOME to point to your installation of aspectj. If you then later install a dev build and run c:\mydevaspectj1.2\bin\ajc.bat - then it will discover ASPECTJ_HOME is set and use the AspectJ it points to (the old version), rather than your new dev version. To definitively run with the new version you need to unset ASPECTJ_HOME.
Sorry, I had missed unsetting the ASPECTJ_HOME (I had only set PATH and CLASSPATH to point to the dev version). Now that I unset that, the dev version seems to work fine. Case closed, I think.
Fix released as part of AspectJ 1.2.1