Bug 196658 - Full build every time ("not going to be incremental because path change detected")
Summary: Full build every time ("not going to be incremental because path change detec...
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 1.6.0   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-16 10:46 EDT by Neale Upstone CLA
Modified: 2008-03-12 01:34 EDT (History)
2 users (show)

See Also:


Attachments
Zip of replacement classes (19.41 KB, application/octet-stream)
2007-08-07 06:06 EDT, Andrew Clement CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Neale Upstone CLA 2007-07-16 10:46:24 EDT
Under Eclipse 3.3, I'm getting full builds every time, supposedly having detected a path change (and nothing has changed).

This problem persists after a restart, and after a clean/rebuild all.

The trace from the AJDT Trace View (nice touch by the way) is as follows:

15:32:59 Startup information: 
   AJDT version: 1.5.0.200706070619 for Eclipse 3.3
   AspectJ Compiler version: DEVELOPMENT
   usingVisualiser=true
   usingXref=true
   usingCUprovider=false
   ajde.version.at.previous.startup = @AJDEVERSION@
15:33:5 ===========================================================================================
15:33:5 Build kind = AUTOBUILD
15:33:5 Project=DbServer2, kind of build requested=Incremental AspectJ compilation
15:33:5 Preparing for build: not going to be incremental because path change detected (one of classpath/aspectpath/inpath/injars)
15:33:5 Falling back to batch compilation
15:33:5 Preparing for build: not going to be incremental because no successful previous full build
15:33:6 Timer event: 281ms: Time to first compiled message
15:33:6 Timer event: 281ms: Time to first woven message
15:33:7 AspectJ reports build successful, build was: FULL
15:33:7 AJDE Callback: finish. Was full build: true
15:33:7 Timer event: 2125ms: Total time spent in AJDE
15:33:8 Timer event: 47ms: Create element map (32 rels in project: DbServer2)
15:33:8 Types affected during build = 115
15:33:8 Timer event: 0ms: Add markers (17 markers)
15:33:8 Timer event: 2266ms: Total time spent in AJBuilder.build()
15:33:8 ===========================================================================================
... and so on for all other AJ projects.
Comment 1 Neale Upstone CLA 2007-07-31 11:21:36 EDT
I'm upping the severity of this, as it is still causing a significant problem, making automated builds in my Eclipse workspace an annoying experience.
Comment 2 Neale Upstone CLA 2007-08-05 11:13:09 EDT
Moved to AJDT (oops)
Comment 3 Matt Chapman CLA 2007-08-05 17:23:59 EDT
Actually, this probably is a compiler bug - AJDT is requesting an incremental build, but is the compiler deciding to do a full build.

Does this only happen with a large project, or can you reproduce the problem with a small test project?
Comment 4 Andrew Clement CLA 2007-08-07 05:51:59 EDT
Do you have it set to its most verbose mode when you look at the event trace view?
Comment 5 Andrew Clement CLA 2007-08-07 06:06:14 EDT
Created attachment 75518 [details]
Zip of replacement classes

This is a replacement for AjState.class (and its inner classes) in AspectJ that will be much more verbose about the decision making process for building.  Please backup your ajde plugin and patch the jar within it with the class from this zip file.

Are all your project aj projects or is even one of them in the dependency chain pure java?
Comment 6 Neale Upstone CLA 2007-08-07 07:32:12 EDT
Hi Andy,

Yes, one of them is pure Java, and it is making a change to the pure Java project that has the AJ project do a full build.

It seems to be the classpath change that is the problem... nothing is changing there.


Here is the output with your patch:

12:17:43 Build kind = AUTOBUILD
12:17:43 Project=DbServer, kind of build requested=Incremental AspectJ compilation
12:17:43 Classpath=C:\dev\workspace\DbServer\bin;C:/apps/jdk6u2/jre/lib/resources.jar;C:/apps/jdk6u2/jre/lib/rt.jar;C:/apps/jdk6u2/jre/lib/jsse.jar;C:/apps/jdk6u2/jre/lib/jce.jar;C:/apps/jdk6u2/jre/lib/charsets.jar;C:/apps/jdk6u2/jre/lib/ext/activation.jar;C:/apps/jdk6u2/jre/lib/ext/dnsns.jar;C:/apps/jdk6u2/jre/lib/ext/localedata.jar;C:/apps/jdk6u2/jre/lib/ext/mail.jar;C:/apps/jdk6u2/jre/lib/ext/sunjce_provider.jar;C:/apps/jdk6u2/jre/lib/ext/sunmscapi.jar;C:/apps/jdk6u2/jre/lib/ext/sunpkcs11.jar;C:\dev\workspace\DbShared\bin;C:\dev\workspace\DbClient\bin;C:\dev\workspace\DbClient2\bin;C:/dev/workspace/lib/trove.jar;C:/apps/eclipse/plugins/org.aspectj.runtime_1.5.4.200705211336/aspectjrt.jar;
12:17:44 ChangeDetected: assuming the worst, we have no state to ask about C:\dev\workspace\DbClient2\bin\likemynds\db\indextree\attributes\bool\BooleanScorerNew.class
12:17:44 ChangeDtected: class file in directory bin has changed
12:17:44 classpath change detected
12:17:44 Preparing for build: not going to be incremental because path change detected (one of classpath/aspectpath/inpath/injars)
12:17:44 Falling back to batch compilation
12:17:44 Preparing for build: not going to be incremental because no successful previous full build


Comment 7 Andrew Clement CLA 2007-08-07 07:57:45 EDT
You are hitting a long standing problem when Java projects and AspectJ projects have inter-dependencies.  The Java project state object in eclipse is a blackbox to us in AspectJ and so we cannot ask it any questions, like "hey, that file you just compiled and put on the disk, were there any changes in it that might affect me?" - so, as from the comment in the log:

"ChangeDetected: assuming the worst, we have no state to ask about
C:\dev\workspace\DbClient2\bin\likemynds\db\indextree\attributes\bool\BooleanScorerNew.class"

We assume it had an impact on us (the AJ project) and required a full build - no other assumption is completely safe.  There is a work item to improve this integration but it is not trivial.  The quickest workarounds is to convert the Java project to an AspectJ project - it will then gain a state object that we can talk to.  Or turn off automatic compilation of the AspectJ projects (less than ideal, I know).
Comment 8 Neale Upstone CLA 2007-08-07 08:26:35 EDT
Thanks Andy.

That's solved it.

I guess that while the architectural difficulty exists, then it may be worth keeping, or modifying your patch to make it very clear why the build was done.
Comment 9 Andrew Clement CLA 2007-08-07 08:28:43 EDT
Yes, I think i will put in a subset of that patch for diagnosing similar situations in the future.
Comment 10 Andrew Clement CLA 2008-03-12 01:34:41 EDT
closing as work completed on this.  bug 221427 talks about some other possible enhancements to address the underlying problem.