Community
Participate
Working Groups
I converted a fairly large pure Java project to be an AspectJ project and find that when I get syntax errors the AspectJ compile stops short without producing an outjar but no problems are listed for it in the problems view. This is with no aspects involved: this is actually a defect in AJDT acting as a pure Java builder. This is with a recent dev build (20060512123514).
Before converting, please can you open the AJDT event trace view and enable all Compiler categories in the trace. Then convert the project, and paste in the output here. There is still a known situation in which this problem can occur, so it would be good to know if this is the same. Also, that dev build is nearly a month old, and there have been some fixes since then, so please could you try with the latest?
It looks like one error (probably an unrelated bug) is happening because two other AspectJ projects depended on this one being in their classpath but they aren't correctly reading output from an outjar. I could file that as a separate bug. Anyhow I've attached the full trace for when I convert the project and then when I change a single nethod name to create a missing method error (which AJDT isn't reporting).
Created attachment 43710 [details] trace when converting from Java to AspectJ (with outjar)
Created attachment 43711 [details] trace after editing code to create syntax error. both traces were from the latest AJDT 20060605111535
Thanks for the traces. The compiler is issuing errors against resources which it hasn't indicated it has processed. Passing over for further investigation.
suspected dup of bug 126118 which also deals with errors that occur very early in the process not getting through.
does the java project have many dependencies, can it be sent to me as a standalone entity? without recreating this, it will be damn tough to fix.
I am not quite sure which messages we think are vanishing since there are so many in that trace, is it all of them? Anyway, I'm looking through the trace attached in comment #4. I'm looking at the final compile in that which starts at timestamp "6:51:48 AM". I can see a lot of errors reported like this: ============= 6:51:51 AM addSourcelineTask message=com.dcx.NGST.gui.screens.HomeScreenControllerMore cannot be resolved to a type file=C:\ngst\app\java\macro\src\com\dcx\NGST\macro\gui\screens\HomeScreenControllerMore.java line=25 6:51:51 AM addSourcelineTask message=The method buildPanel() is undefined for the type Object file=C:\ngst\app\java\macro\src\com\dcx\NGST\macro\gui\screens\HomeScreenControllerMore.java line=43 6:51:51 AM addSourcelineTask message=buttonFactory cannot be resolved file=C:\ngst\app\java\macro\src\com\dcx\NGST\macro\gui\screens\HomeScreenControllerMore.java line=45 6:51:51 AM addSourcelineTask message=emptyButton11 cannot be resolved file=C:\ngst\app\java\macro\src\com\dcx\NGST\macro\gui\screens\HomeScreenControllerMore.java line=55 ================ A little further up I can see the line: ================= 6:51:49 AM AJC: compiled: C:\ngst\app\java\macro\src\com\dcx\NGST\macro\gui\screens\HomeScreenControllerMore.java ================= It is a similar story for the others that I look at. The errors come out and there has already been a 'compiled:' line fed back to indicate the resource has been processed. Does AJDT not like the fact that the error has been reported against a resource earlier than the most recent one it has been told about? Or have I missed the point... i'll carry on playing to recreate this.
interestingly when the error message comes out about not adding the marker, it says: 6:51:51 AM Not adding marker for problem because it's against a resource which is not in the list of affected resources provided by the compiler. Resource=L/macro/src/com/dcx/NGST/macro/gui/screens/HomeScreenControllerMore.java Problem message=com.dcx.NGST.gui.screens.HomeScreenControllerMore cannot be resolved to a type line=25 Does the 'L' on the front of the resource indicate a linked source folder or some such?
Ron, what kind of configuration are you using? Do you have an external location defined for your projects? linked source folders?
This configuration is not using linked source folders... ngst project: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="src" path="testsrc"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="src" path="/API"/> ... <classpathentry combineaccessrules="false" kind="src" path="/lib"/> <classpathentry kind="lib" path="/lib/concurrent-1.3.4.jar"/> ... <classpathentry combineaccessrules="false" kind="src" path="/StepLangSupportObjects"/> <classpathentry combineaccessrules="false" kind="src" path="/RoutineViews"/> <classpathentry kind="var" path="ASPECTJRT_LIB"/> <classpathentry kind="output" path="eclipse-target"/> </classpath> macro: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="src" path="testsrc"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="src" path="/API"/> ... <classpathentry combineaccessrules="false" kind="src" path="/lib"/> <classpathentry kind="lib" path="/lib/concurrent-1.3.4.jar"/> ... <classpathentry combineaccessrules="false" kind="src" path="/StepLangSupportObjects"/> <classpathentry combineaccessrules="false" kind="src" path="/RoutineViews"/> <classpathentry kind="var" path="ASPECTJRT_LIB"/> <classpathentry kind="output" path="eclipse-target"/> </classpath> <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="src" path="/API"/> ... <classpathentry combineaccessrules="false" kind="src" path="/lib"/> <classpathentry kind="lib" path="/lib/cglib-2.0-rc2.jar"/> ... <classpathentry kind="var" path="ASPECTJRT_LIB"/> <classpathentry kind="output" path="eclipse-target"/> </classpath>
Ron, could you send us a zip of the projects? I think we'll be able to figure out what's going wrong here if we can step through it ourselves.
Let me see what I can do. The code is confidential customer code so I can't provide it without permission, but maybe I can recreate the problem in a simpler environment without confidential code. I've also seen problems like this in open source code, so I'll try to reproduce a similar problem with the Glassbox code. Stay tuned...
I recreated the problem in the Glassbox project and sent a project to Matt Chapman and Andy in an email. Please let me know if you need any more help to track this down.
I've reproduced this with glassbox: 19:36:01 Build kind = FULLBUILD 19:36:01 Project=glassboxMonitor, kind of build requested=Full AspectJ compilation 19:36:01 Builder: Tidied output folder(s), deleted 0 .class files 19:36:01 Preparing for build: not going to be incremental because no successful previous full build 19:36:02 addSourcelineTask message=The type javax.servlet.http.HttpServletRequest cannot be resolved. It is indirectly referenced from required .class files file=E:\AJDTversions\eclipse-SDK-3.2RC7-win32\eclipse\runtime-EclipseApplication\glassboxMonitor\testsrc\glassbox\util\logging\LoggingTest.java line=0 19:36:02 AJDE Callback: finish() 19:36:02 Timer event: 1012ms: Total time spent in AJDE 19:36:02 Timer event: 30ms: Create element map (0 rels in project: glassboxMonitor) 19:36:02 Types affected during build = 0 19:36:02 Not adding marker for problem because it's against a resource which is not in the list of affected resources provided by the compiler. Resource=L/glassboxMonitor/testsrc/glassbox/util/logging/LoggingTest.java Problem message=The type javax.servlet.http.HttpServletRequest cannot be resolved. It is indirectly referenced from required .class files line=0 19:36:02 Timer event: 0ms: Add markers (0 markers) 19:36:02 Timer event: 1152ms: Total time spent in AJBuilder.build()
I have also recreated this now. With the new projects we've been sent, it is a definetly a different bug than what is described in comment #4, comment #8 and comment #9 but it exhibits the similar symptom of the error message not reaching the users problems view. So i can work on fixing this case but it wont fix the original case. The reason the compiler has not reported that it has compiled the file is because it hasn't. Post diet parse of the units we attempt to complete the type system holding everything together, before continuing with full compilation. If a jar is removed from the required list that contains a type required to make the type system consistent then an error (like this one) is created post diet parse and before compilation. At the moment I'm trying to think back as to why we made AJDT only record problems against resources it had heard about through "compiled:" "woven:" messages. My recollection is that it is what enabled us to tidy up the right bunch of messages just prior to the subsequent incremental compile - if all messages of unknown origin just got dumped at the project level, we'd never know it was safe to remove them until you did a full build. I really don't want to add a bunch of new messages coming from the compiler 'diet parsed: XXX' - so I wonder what harm it would be to allow AJDT to put it on the resource, we clearly have a resource in mind that it relates to "L/glassboxMonitor/testsrc/glassbox/util/logging/LoggingTest.java" (whatever the L is doing there... who knows). hmmm.
So the 'L' is because AJDT has done the hard work and discovered which file it is. It just decided (CompilerTaskListManager:236) that it wasnt on the affected resources list.
I wonder if we should consider everything an affected resource *if* we are doing a full build (more correctly, if the compiler determined it needed to do a full build) - because removing a jar causes this bug to appear and removing a jar is considered a path change and a path change means a full build. If I look at the comment against the affectedResources check it mentions bug 128803 - and that talks about doing checks so duplicate warnings aren't reported, but if we are full building we will know to clear up *everything* (because everything can be considered an affected resource) and so duplicates cant happen.
Yes, AJDT knows the resource and could add an error marker for it. That does sound reasonable, disregarding the affected list when the compiler reports a full build. I'll look into it. Note that the problem also occurs with AJDT 1.3.1.
The above logic seems to work, initially at least. We just need a way for the compiler to tell AJDT whether the previous build was full or incremental (currently this is only possible in debug mode, when we register a state listener).
Modified BuildProgressMonitor so that the finish method takes a boolean indicating if the build just completed was a full build or not. Changes are in AspectJ HEAD.
fix delivered in AJ and AJDT now...
