Community
Participate
Working Groups
I have auto-compilation on. After a big import from a non-CVS source, I recompile and all is fine. Now I want to push the stuff to the CVS repository. I "synchronize with repository" and get only outgoing changes, as was to be expected. When I commit those, suddenly the Java compiler starts an extensive recompile. Why would it do that? Nothing has changed locally. Annoying.
Which repository adapter are you using ? ClearCase ? Do you know if it is changing the resource files on the way out (read-only status for instance?). This could be a change which we do not filter out... You may want to turn on the Java builder activity trace, to monitor the files being recompiled and let us know. With console open (-consoleLog), add the following lines into the .options file (which should be next to eclipse.exe). # Turn on debug tracing for org.eclipse.jdt.core plugin org.eclipse.jdt.core/debug=true # Reports incremental builder activity : nature of build, built state reading, indictment process org.eclipse.jdt.core/debug/builder=true
> Which repository adapter are you using ? ClearCase ? Not that I know of. I use plain Eclipse 2.0.1 as it drops out of the box, i.e., eclipse-SDK-2.0.1-win32.zip. Unless ClearCase is contained in that, I don't use ClearCase. For what it's worth: The CVS server is a straightforward Linux box running CVS pserver (out of inetd). I will do another of these imports soon, but I cannot find any file ".options" in the directory where eclipse.exe sits. I do see an "install.ini" file, does that help? I also checked .metadata in the workspace, no ".options" there, either.
Copy the .options file from your eclipse install directory \eclipse\plugins\org.eclipse.jdt.core_2.0.0 to the root eclipse directory where eclipse.exe is... change it to include the 2 options Philippe mentioned. Then add the -consolelog option to your command line when you start eclipse. Is Autobuild on/off when you do the import? Do any other projects depend on the 'new' project?
Make sure to run java.exe not javaw.exe with -debug and -consolelog. This is my command line: d:\R2.0\eclipse\eclipse.exe -debug -consolelog -data d:\R2.0\workspace\plugins - vm d:\jdk1.3\bin\java.exe -vmargs -Xmx150mb
Thank you for the instructions, I hope to get around to trying this one more time later this week. I'm not sure autobuild was "on" during the import, but it was certainly on at the time when I did the CVS operation. Also, this project both depends on some project and has other projects that depend on it. (Could this be related to bug 24070?)
If autobuild was not on when you did the import, that would explain it. The next 'chance' for a build would have been the CVS commit. Why are you turning autobuild on/off? What operations are you doing where you do not want it on?
> Why are you turning autobuild on/off? What operations are you doing where you > do not want it on? When importing several (huge) projects from external sources at once, I do not want to have to wait for an intermediate autobuild of a project that I'm going to replace with different content in a minute. > If autobuild was not on when you did the import, that would explain it. O, good. So this does save me from doing all this debugging and logging. > The next 'chance' for a build would have been the CVS commit. I think that's a bug. The next chance should be the moment I switch autobuild back on. If you agree that that's the real bug, please mark this bug as a duplicate of bug 24301. If I have overlooked something or you disagree, we can continue to work on this here in this bug. (Which is why I don't resolve this as a duplicate myself.)
I hate to say this, but the problem is NOT connected with autobuild after all. I had autobuild switched on the whole time, but still am presently suffering from a CVS-checkin-induced rebuild. So I'll have to bite the bullet and do some more in-depth debugging on this. ("Stay tuned".)
I'm happy to report that I can now reproduce the problem. My setup: I have a project which isn't a Java project, but just a plain Eclipse core project, and contains an ant script and a jar J build by the ant script. I have two Java projects A and C that both have that jar J in their build path. I have a third Java project B that has both A and C in its build path, but does not have J in its build path. Eclipse doesn't know this, and strictly speaking, you needn't, either. But as background information for you, I tell you the dark secret of B and J: I should have a cyclic dependency between both B and A and B and C. I have not set up Eclipse that way, both A and C don't depend on B, they depend on J. But, the dark secret shared only by me and my ant script, J contains all the class files from B. This entire setup is my present way of coping with Eclipse bug 10262. Here is what I do to reproduce the problem: I use a cygwin command line to "touch" all source files in B. For the amusement of people knowing Cygwin: find . -type d -name CVS -prune -o -type f -print | xargs touch Translated: I change all time stamp, without changing any content, of all source files in B. From Eclipse's view, this project now needs a complete rebuild. I use "refresh" on B to make Eclipse realize I've messed with B's sources. The complete rebuild, of B only, takes place. I now run my ant script, using Eclipse's "Run ant", and the ant script builds J. Incidently, that ant script calls another build of B, prior to building J, using the Eclipse ant task <eclipse.incrementalBuild project="B" />, but no build activity seems to take place at this point. After J has been build, the same ant script calls Eclipse's task <eclipse.refreshLocal /> on the entire project containing J. I think what happens next is broken (incomplete). As a result of that, I do see some build activity. Watching the stuff flashing across the screen carefully, I saw some activity in C first, then in A, then in B, and then again in C. Weird. As B's build path has C's binary output in it, all the activity on C should take place before B is build. Next thing, I commit my "changes" to B to the CVS repository. The CVS server will soon realize that nothing has really changed, but Eclipse doesn't know this and goes through all the motions and sends all the files to the CVS server. Fine. During the commit, I see some build activity of C first (I missed that part when writing the original report), then an extensive build activity of B. Stay tuned, I'll now switch logging on.
> to the root eclipse directory where eclipse.exe is. Apperantly, that .options file needs to be in the current working directory of eclipse.exe, not in the directory where the executable itself sits.
Ok, now I have a total of 13652 lines of log file on my hand. I'm only an external consultant here and I'm afraid my customer may not want me to see either the project nor the class file names publicised, so I cannot simply give those files as they are. In the days of C and C++, I written and debugged quite a few makefile-s, so I did find some things that I consider bugs. So here's what I found: I touched and refreshed and Eclipse reported an incremental build on project B: > Starting build of B @ Wed Oct 02 12:53:16 CEST 2002 > Found source delta for: B > Clearing last state : State for B (#71 @ Wed Oct 02 10:59:10 CEST 2002) > INCREMENTAL build As it turns out, nothing has changed, so I get a lot of lines of this sort: > Skipped over unchanged class file Something.class Actually, ALL class files have not changed. So the entire project is identical, as far as its binary output is concerned. I'm not sure Eclipse treats this fact correctly, stay tuned. Anyway, what I get is: > Recording new state : State for B (#72 @ Wed Oct 02 10:59:10 CEST 2002) > Finished build of B @ Wed Oct 02 12:56:31 CEST 2002 I don't like the fact that the time stamp isn't upgraded from the previous "10:59:10". From my experience with make, you really need two different timestamps. One is the time stamp of the youngest source file that went into the build, and one is the time stamp of the youngest binary file that came out of the build. I have a feeling that you generate this timestamp as if it were the "outgoing" time stamp, but you use it as if it were the "incoming". In other words: Can Eclipse tell that a source file that's younger than 12:53:16 has already been incorporated into #72? On the next build, I indeed get a bogus "Found source delta for: B", (see below), so I think you have one bug there. As a side remark, you may think what I've done is not how sane people ever treat source files. I have personally written scripts that went through an entire source tree to bring javadoc comments up to CI standards, also with no single resulting class file change. Another use case is software import from a source where they don't have a decent version management system, and will happily mail you the very same sources three different occasions, as you only find out *after* import into your own CVS repository. This is one bug I found. I also did find a second one: In the ant log, after I had changed the JAR and project A got rebuild, I get another incremental build of B, which ends with: > Recording new state : State for B (#73 @ Wed Oct 02 10:59:10 CEST 2002) > Finished build of B @ Wed Oct 02 13:02:22 CEST 2002 *After* the build for B, I also get a build of C: > Starting build of C @ Wed Oct 02 13:02:22 CEST 2002 > Found binary delta for: (Project of J) > Clearing last state : State for C (#0 @ Wed Oct 02 11:30:08 CEST 2002) > INCREMENTAL build > ABORTING incremental build... found delta to jar/zip file > Clearing last state : State for C (#0 @ Wed Oct 02 11:30:08 CEST 2002) > FULL build I think this is the wrong sequence of events. As B depends on C, C should have been build first, then B. The projects should neither be build in alphabetical order, nor in the order they are displayed (which is alphabetical, too, as far as I know), but independend projects first, their dependencies second. In my opinion, this is a second bug. Now to the CVS commit. You may hold your breath, those two bugs are now finally about to surface. This is the build of B I've been complaining about initially. It starts with > Starting build of B @ Wed Oct 02 13:06:53 CEST 2002 > Found source delta for: B > Found binary delta for: C > Clearing last state : State for B (#73 @ Wed Oct 02 10:59:10 CEST 2002) > > INCREMENTAL build Both of these "found ... delta"-assesments are invalid. In both cases, Eclipse should have known or done better than that. For one thing, there is no source change in B that had not been present when state #73 was generated. The other "found delta" is only due to the fact that Eclipse didn't get the build order right when refreshing things previously. Of course, B must rebuild as C changed. But it was Eclipse that has changed C, and, as autobuild has been switched on throughout the entire operation, B should have been rebuild right away *after* C has been build. I hope this helps. You may want to split this bug report in two, as two different bugs have surfaced, and also invent a new "summary", as all of this has little to do with CVS. If you have additional questions, feel free to ask them, I will save the original log files.
Andreas: I appreciate your effort but you're getting off-track. For example, the build timestamp is not used to determine which source files to compile. Eclipse's build process is not a simple makefile based system... it is based on a delta tree which records different levels of changes to resources. Why are you touching every source file in B? Why not just invoke the ant script... if there are any changes, the incremental build of B will take care of them. How are A & C connected to the jar J? Do they export it to their dependent projects (ie. B)? Can you please paste in the .classpath files for the 3 projects (change the names to A, B and C)? What is the build order in the workspace? Paste in the contents of Window- >Preferences->Build Order. Are there any cycle errors on any of the projects? I think all of your problems can be traced to an incorrect build order but we need this information to confirm this.
> Why are you touching every source file in B? The original problem had occured when I had first deleted everything in B and then imported everything back from a foreign source. In touching the source files and then telling Eclipse to refresh B, I'm trying to simulate such an import. Do you think this is a valid and useful way to simulate this? Anyway, I think Eclipse should be able to handle a "touch". > How are A & C connected to the jar J? > Do they export it to their dependent projects (ie. B)? No, they only have J in their own build path, but don't export it. > Paste in the contents of Window->Preferences->Build Order. This is interesting! I had never seen or opened this one before. There are some 13 projects first, and then some 6 projects, including A, B, C, and J's project, that are all marked with a "*", i.e., involved in a build cycle. Ok, let's give this thing a name, let's call J's project P. The interesting thing is that P isn't a Java project, so there is no build activity involved with P. Still, Eclipse seems to think P it is part of a build cycle. The fact is that P has a "Project Reference" to all three of A, B, and C. I did this to make sure the ant script finds what it needs. On the other hand, Eclipse agrees with me that there is no way to perform any build activity on P: "Rebuild project" is not available. Thus far, I had been convinced that no build cycle is involved, as neither A nor B nor C nor P show any build path problems in their task lists. Ok, I do a little experiment. I remove the project reference to A, B, C from P. Ok, this does remove the cycle in the build order. So I do the global touch on B, simulating an import from a foreign source. I refresh B - the usual build activity starts, as I have autobuild on (and I'm not going to switch it off for this experiment, either). I use P's ant script to bring up J to the status of the "newly imported" sources. I see build activity in A, then C, then B. Fine! I synchronize B with the CVS repository. On commit - I STILL SEE BUILD ACTIVITY IN B! Back to the "build order" in "preferences". Of course, there is still no cycle present, I removed this when I changed P's references to "references no project". It has now 19 projects, with relative sequence of the four projects in question a sane P, A, C, B. I can see nothing wrong here. Would it be useful to do another session with log switched on, after the change to P? Anyway, I'll give you the .classpath files. Stay tuned.
Created attachment 2102 [details] All classpath files in my workspace (generated, and project names changed, by a script)
The build order wasn't so easy, as copy and paste did not work. I typed the project names and run them through the same script filter that produced the attachement. This is the (default) build order of all projects in my workspace: Java_Transaction_API E K D JAVA_API_for_XML_processing P M JUnit Jakarta-Ant L N I A J H C B G F
As you may have guessed, what I used to call "J" is "/P/jars/B.jar" in the classpath-attachement.
I suspected there was a cycle... cycles are detected in 2 ways: by the build manager (which builds all types of projects) and by the Java builder by examining the dependencies in the .classpath files. Only cycles in .classpath files show up as build errors. Generic project dependencies are reported in the build order dialog. Now that we know the build order is 'correct', it would usefull to see what is being built when B is committed to CVS. Please paste in as much info as you can from the builder trace.
Before I spend the effort catching logs and obfuscating class names and such, please allow one more question: Have you at least tried to reproduce the problem yourself? (I'm not convinced there's anything all that specific about my setup.)
Yes and I've talked to the Team team and they do not understand how this could be happening. They do not perform a build during/before a commit operation. We do not need the complete trace so delete the repetitive messages. Or better yet try it with a smaller testcase of 1-2 fake classes. As for your setup and scripts, its very unique... so I won't rule it out yet.
> They do not perform a build during/before a commit operation. Seems to be *after* the commit proper.
One more thing... how many jar files does your ant script make? Is it only making 1 jar file for the project B or is it making jar files for A and C also? Is there one script or several? Do you have to manually run it or does it run after B is built?
> how many jar files does your ant script make? Is it only > making 1 jar file for the project B or is it making jar files for A and C also? Either way you like it. There are jar files for all three projects in P. > Is there one script or several? Just one. I run it manually using "run ant" from the file's context menu. In the experiments described, I sumulated an upgrade of B, and only ran it to upgrade the Jar-Archive containing B's class files, B.jar. I didn't update the Jar-Archives for A or C, A.jar and C.jar.
> they do not understand how this could > be happening. They do not perform a build during/before a commit operation. Last night, I created a new class. This morning, I fired up eclipse, did "Synchronize with Repository", added the new .java file to version control, as the first thing I did. I saw that, during the CVS operation, I think it was already during the CVS "add", Eclipse checked the build state of various projects. Are you saying this is unusual? Or can you reproduce at least that much? (Maybe both.) I plan to try to find a small example of this whole mess and send you an archive of the workspace. This will take a bit of time.
Its normal... if you follow Workspace.run(...) to Workspace.endOperation(...), a build is performed if the resource tree is modified (which a commit operation does in 'hidden' CVS folders to record the sync info... they do not modify Java resources). So an incremental build is invoked, but this should be no time (ie. less than a second per project), since no Java resources were modified. The builder trace should show us what resources have been modified & then we can try to figure out when they were changed (without a build detecting them earlier).
Andreas: Can you provide us with a sample of the builder trace?
I am experiencing a similar symptom (where after committing outgoing changes to CVS, a build occurs). The type of build is IncrementalProjectBuilder.AUTO_BUILD and the resource deltas that I receive are of kind IResourceDelta.CHANGED with flags of IResourceDelta.CONTENT. Unfortunately, this is a custom builder, so it won't be possible for you to replicate the exact condition on your machine. As another note, this is the only project in my workspace. com.ibm.sample.builder.SampleBuilder.build(SampleBuilder.java:71) org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:392) org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:839) org.eclipse.core.runtime.Platform.run(Platform.java:416) org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:120) org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:176) org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:186) org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:146) org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:839) org.eclipse.core.runtime.Platform.run(Platform.java:416) org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:160) org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:211) org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:745) org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1383) org.eclipse.ui.actions.WorkspaceModifyOperation.run (WorkspaceModifyOperation.java:78) org.eclipse.jface.operation.ModalContext$ModalContextThread.run (ModalContext.java:98)
Sorry, this is the stack trace as reported by the debugger. Please replace the last 3 lines of comment 26 with these lines. org.eclipse.core.internal.resources.Workspace.run (org.eclipse.core.resources.IWorkspaceRunnable, org.eclipse.core.runtime.IProgressMonitor) line: 1383 org.eclipse.team.internal.ccvs.ui.sync.MergeAction$1 (org.eclipse.ui.actions.WorkspaceModifyOperation).run (org.eclipse.core.runtime.IProgressMonitor) line: 78 org.eclipse.jface.operation.ModalContext$ModalContextThread.run() line: 98
Closing until we have repeatable steps or a builder trace showing that resources are being changed during the CVS commit.
Ok. With some grief, but it may be the best thing we can do for the moment. I would like to spend more time on this bug, as I continue to regularily see build update activity connected with CVS update activity, but on the other hand, I'm hard pressed timewise these days and feel I should not continue to burn time on this bug. If what I have provided you with doesn't help, it's probably best to wait for some other person, who's seeing the same things I do, but has more options and abilities to work things out for you. Including the ability to post trace files to the internet, which I cannot do for the reasons I have explained.
