Community
Participate
Working Groups
I200409070800 I don't know the pattern but an almost every second startup of Eclipse a full build kicks in. What I see is the following: - a first build runs marking almost all of my source problems with errors. This doesn't seem to be a full build since it only takes around 30 seconds - a second build kicks in which does the actual full build.
Scan the errors on the projects themselves... I suspect you have major build failures (classpath problems, etc.).
No, my projects don't show any errors when I start nor did they when I shutdown. But the do after the first build that kicks in, but they are gone after the second. CCing Andre. He sees a similar behaviour.
So after the first build, what are the errors on the projects themselves (if there are any)?
Haven't checked. Will do the next time I see the behavior.
Close as this bug seems not to be reproduced for near 6 weeks... Dirk, please reopen if you get it again, thanks
Integration build: I20041130 Since recent integration builds on the 3.1 stream, I encounter FULL rebuilds at startup. Here is part of a trace: Install location: file:/c:/Software/eclipse/ Configuration file: file:/c:/Software/eclipse/configuration/config.ini loaded Configuration location: file:/c:/Software/eclipse/configuration/ Configuration file: file:/c:/Software/eclipse/configuration/config.ini loaded Framework located: file:/c:/Software/eclipse/plugins/org.eclipse.osgi_3.1.0/ Loading framework classpath from: file:/c:/Software/eclipse/plugins/org.eclipse.osgi_3.1.0/eclipse.properties Framework classpath: file:/c:/Software/eclipse/plugins/org.eclipse.osgi_3.1.0/core.jar file:/c:/Software/eclipse/plugins/org.eclipse.osgi_3.1.0/console.jar file:/c:/Software/eclipse/plugins/org.eclipse.osgi_3.1.0/osgi.jar file:/c:/Software/eclipse/plugins/org.eclipse.osgi_3.1.0/resolver.jar file:/c:/Software/eclipse/plugins/org.eclipse.osgi_3.1.0/defaultAdaptor.jar file:/c:/Software/eclipse/plugins/org.eclipse.osgi_3.1.0/eclipseAdaptor.jar Splash location: c:\Software\eclipse\plugins\org.eclipse.platform_3.1.0\splash.bmp Debug options: file:/c:/temp/eclipse.options loaded Time to load bundles: 10 Starting application: 540 Starting build of <project name> @ Fri Dec 03 09:10:27 CET 2004 FULL build About to compile .... Is there anything I can enable to figure out *why* it starts a FULL build? Ringo
Yes, I'm seeing the same problem in recent builds.
I see it as well. Kent, what flags do I have to set in the .options file to get a trace for this ?
The 2 options to toggle in your .options file are: # Turn on debug tracing for org.eclipse.jdt.core plugin org.eclipse.jdt.core/debug=true # Reports incremental builder activity org.eclipse.jdt.core/debug/builder=true It may also be worthwhile to try core's BuildManager debug options: # Turn on debugging for the org.eclipse.core.resources plugin. org.eclipse.core.resources/debug=true # Reports the start and end of all builder invocations org.eclipse.core.resources/build/invoking=true
Kent, I enabled the debug options. However this produces a gigantic log since it contians an enrty for every file that got compiled. Can I somehow suppress this ?
I just exited my workspace (normally), and patched jdt/core. On restart, I got a full build. Could it be our jar comparison which is giving false hits ? Could you make it more verbose (file vs. timestamp) ? Would it be our timestamp recording issuing these fake differences ? This is a good one to investigate for M4 (is it only occurring when patching?) ================================================= java version "1.4.2_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b02) Java HotSpot(TM) Client VM (build 1.4.2_07-b02, mixed mode) Install location: file:/d:/eclipse/sdk/eclipse/ Configuration file: file:/d:/eclipse/sdk/eclipse/configuration/config.ini loaded Configuration location: file:/d:/eclipse/sdk/eclipse/configuration/ Configuration file: file:/d:/eclipse/sdk/eclipse/configuration/config.ini loaded Framework located: file:/d:/eclipse/sdk/eclipse/plugins/org.eclipse.osgi_3.1.0/ Loading framework classpath from: file:/d:/eclipse/sdk/eclipse/plugins/org.eclipse.osgi_3.1.0/eclipse.properties Framework classpath: file:/d:/eclipse/sdk/eclipse/plugins/org.eclipse.osgi_3.1.0/core.jar file:/d:/eclipse/sdk/eclipse/plugins/org.eclipse.osgi_3.1.0/console.jar file:/d:/eclipse/sdk/eclipse/plugins/org.eclipse.osgi_3.1.0/osgi.jar file:/d:/eclipse/sdk/eclipse/plugins/org.eclipse.osgi_3.1.0/resolver.jar file:/d:/eclipse/sdk/eclipse/plugins/org.eclipse.osgi_3.1.0/defaultAdaptor.jar file:/d:/eclipse/sdk/eclipse/plugins/org.eclipse.osgi_3.1.0/eclipseAdaptor.jar Splash location: d:\eclipse\sdk\eclipse\plugins\org.eclipse.platform_3.1.0\splash.bmp Debug options: file:/D:/eclipse/sdk/eclipse/.options loaded osgi> Time to load bundles: 91 Starting application: 9784 Fri Dec 10 13:08:41 CET 2004 - [main] Build requested, needsBuild: true state: NONE delay: 100 Fri Dec 10 13:08:44 CET 2004 - [main] Build requested, needsBuild: false state: SLEEPING delay: 100 Fri Dec 10 13:08:45 CET 2004 - [main] Build requested, needsBuild: false state: SLEEPING delay: 100 Fri Dec 10 13:08:46 CET 2004 - [main] Build requested, needsBuild: false state: SLEEPING delay: 100 Fri Dec 10 13:08:46 CET 2004 - [main] Build requested, needsBuild: false state: SLEEPING delay: 100 Fri Dec 10 13:08:46 CET 2004 - [main] Build requested, needsBuild: false state: SLEEPING delay: 100 ..... Fri Dec 10 13:08:55 CET 2004 - [Worker-4] Build requested, needsBuild: false state: RUNNING delay: 100 Thread[Worker-0,5,main] BUILDING NameLoopkup Thread[Worker-0,5,main] -> pkg roots size: 56 Thread[Worker-0,5,main] -> pkgs size: 648 Thread[Worker-0,5,main] -> working copy size: 4 Thread[Worker-0,5,main] BUILDING NameLoopkup Thread[Worker-0,5,main] -> pkg roots size: 89 Thread[Worker-0,5,main] -> pkgs size: 970 Thread[Worker-0,5,main] -> working copy size: 4 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] BUILDING NameLoopkup Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkg roots size: 56 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkgs size: 648 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> working copy size: 3 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] BUILDING NameLoopkup Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkg roots size: 56 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkgs size: 648 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> working copy size: 3 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] BUILDING NameLoopkup Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkg roots size: 89 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkgs size: 970 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> working copy size: 3 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] TIME SPENT in NameLoopkup#seekTypesInSourcePackage: 0ms Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] BUILDING NameLoopkup Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkg roots size: 89 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkgs size: 970 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> working copy size: 3 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] TIME SPENT in NameLoopkup#seekTypesInSourcePackage: 0ms Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] TIME SPENT in NameLoopkup#seekTypesInSourcePackage: 0ms Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] BUILDING NameLoopkup Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkg roots size: 56 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkgs size: 648 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> working copy size: 3 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] TIME SPENT in NameLoopkup#seekTypesInSourcePackage: 30ms Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] TIME SPENT in NameLoopkup#seekTypesInSourcePackage: 0ms Fri Dec 10 13:09:56 CET 2004 - [Worker-3] Checking if need to build. Starting delta computation between: ElementTree(3) and ElementTree(177) Fri Dec 10 13:09:56 CET 2004 - [Worker-3] End delta computation. (0ms). Fri Dec 10 13:09:56 CET 2004 - [Worker-3] JavaBuilder(org.eclipse.jdt.core) needs building because of changes in: org.eclipse.jdt.core Fri Dec 10 13:09:56 CET 2004 - [Worker-3] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.jdt.core) Starting build of org.eclipse.jdt.core @ Fri Dec 10 13:09:56 CET 2004 About to read state... Successfully read state for org.eclipse.core.resources About to read state... Successfully read state for org.eclipse.core.runtime About to read state... Successfully read state for org.eclipse.osgi About to read state... Successfully read state for org.eclipse.text About to read state... Successfully read state for org.apache.ant About to read state... Successfully read state for org.eclipse.team.core About to read state... Successfully read state for org.eclipse.jdt.core Classpath jar file D:/eclipse/workspaces/dev3.1/plugins/org.eclipse.core.resources/resources.jar != Classpath jar file D:/eclipse/workspaces/dev3.1/plugins/org. eclipse.core.resources/resources.jar Clearing last state : State for org.eclipse.jdt.core (#13 @ Thu Dec 09 23:33:49 CET 2004) FULL build Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] BUILDING NameLoopkup Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkg roots size: 56 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> pkgs size: 648 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] -> working copy size: 3 Thread[org.eclipse.jdt.internal.ui.text.JavaReconciler,1,main] TIME SPENT in NameLoopkup#seekTypesInSourcePackage: 10ms About to compile antadapter/org/eclipse/jdt/internal/antadapter/AntAdapterMessages.java About to compile antadapter/org/eclipse/jdt/core/JDTCompilerAdapter.java About to compile antadapter/org/eclipse/jdt/core/CheckDebugAttributes.java About to compile batch/org/eclipse/jdt/internal/compiler/batch/Main.java About to compile batch/org/eclipse/jdt/internal/compiler/batch/FileSystem.java About to compile batch/org/eclipse/jdt/internal/compiler/batch/FileFinder.java About to compile batch/org/eclipse/jdt/internal/compiler/batch/CompilationUnit.java About to compile batch/org/eclipse/jdt/internal/compiler/batch/ClasspathJar.java About to compile batch/org/eclipse/jdt/internal/compiler/batch/ClasspathDirectory.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionScanner.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionParser.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnSuperReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnSingleTypeReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnSingleNameReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnQualifiedTypeReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnQualifiedSuperReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnQualifiedNameReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnQualifiedAllocationExpression.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnParameterizedSingleTypeReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnParameterizedQualifiedTypeReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnPackageReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnNameOfMemberValuePair.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnMessageSend.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnLocalName.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnImportReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnFieldType.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnFieldReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnExplicitConstructorCall.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionOnArgumentName.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/select/SelectionNodeFound.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/impl/Keywords.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/impl/Engine.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/impl/AssistParser.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/impl/AssistOptions.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/InvalidCursorLocation.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionScanner.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionParser.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnSingleTypeReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnSingleNameReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnQualifiedTypeReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnQualifiedNameReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnQualifiedInterfaceReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnQualifiedExceptionReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnQualifiedClassReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnQualifiedAllocationExpression.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnParameterizedQualifiedTypeReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnPackageReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnMethodTypeParameter.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnMethodReturnType.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnMethodName.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnMessageSend.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnMemberAccess.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnLocalName.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnKeyword3.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnKeyword2.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnKeyword1.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnKeyword.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnInterfaceReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnImportReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnFieldType.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnFieldName.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnExplicitConstructorCall.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnExceptionReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnClassReference.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnClassLiteralAccess.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionOnArgumentName.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionNodeFound.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionNodeDetector.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/SelectionEngine.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/RelevanceConstants.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/InternalCompletionProposal.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/ISelectionRequestor.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/ISearchRequestor.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/IExtendedCompletionRequestor.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/CompletionRequestorWrapper.java About to compile codeassist/org/eclipse/jdt/internal/codeassist/CompletionEngine.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/WeakHashSet.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/Util.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/SuffixConstants.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/SimpleNameVector.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/SimpleLookupTable.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/ObjectVector.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/HashtableOfType.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/HashtableOfPackage.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/HashtableOfObjectToInt.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/HashtableOfObject.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/HashtableOfLong.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/HashtableOfIntValues.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/HashtableOfInt.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/FloatUtil.java About to compile compiler/org/eclipse/jdt/internal/compiler/util/CompoundNameVector.java About to compile compiler/org/eclipse/jdt/internal/compiler/problem/ShouldNotImplement.java About to compile compiler/org/eclipse/jdt/internal/compiler/problem/ProblemSeverities.java About to compile compiler/org/eclipse/jdt/internal/compiler/problem/ProblemReporter.java About to compile compiler/org/eclipse/jdt/internal/compiler/problem/ProblemHandler.java About to compile compiler/org/eclipse/jdt/internal/compiler/problem/DefaultProblemFactory.java About to compile compiler/org/eclipse/jdt/internal/compiler/problem/DefaultProblem.java About to compile compiler/org/eclipse/jdt/internal/compiler/problem/AbortType.java About to compile compiler/org/eclipse/jdt/internal/compiler/problem/AbortMethod.java About to compile compiler/org/eclipse/jdt/internal/compiler/problem/AbortCompilationUnit.java About to compile compiler/org/eclipse/jdt/internal/compiler/problem/AbortCompilation.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/diagnose/RangeUtil.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/diagnose/LexStream.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/diagnose/DiagnoseParser.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/TerminalTokens.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/Scanner.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/RecoveredUnit.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/RecoveredType.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/RecoveredStatement.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/RecoveredMethod.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/RecoveredLocalVariable.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/RecoveredInitializer.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/RecoveredImport.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/RecoveredField.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/RecoveredElement.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/RecoveredBlock.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/ParserBasicInformation.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/Parser.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/NLSLine.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/JavadocParser.java About to compile compiler/org/eclipse/jdt/internal/compiler/parser/AbstractCommentParser.java About to compile compiler/org/eclipse/jdt/internal/compiler/lookup/WildcardBinding.java
I go it again. Here the interesting part of the log (I hope) Starting build of org.eclipse.help @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.help Nothing to build since there are no source folders and no deltas Finished build of org.eclipse.help @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.help) time: 10ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: ManifestConsistencyChecker(org.eclipse.help) Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: ManifestConsistencyChecker(org.eclipse.help) time: 0ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: ExtensionPointSchemaBuilder(org.eclipse.help) Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: ExtensionPointSchemaBuilder(org.eclipse.help) time: 0ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.help.base) Starting build of org.eclipse.help.base @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.apache.lucene About to read state... Successfully read state for org.eclipse.help.appserver About to read state... Successfully read state for org.eclipse.help.base Nothing to build since there are no source folders and no deltas Finished build of org.eclipse.help.base @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.help.base) time: 40ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.osgi.util) Starting build of org.eclipse.osgi.util @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.osgi.util Nothing to build since there are no source folders and no deltas Finished build of org.eclipse.osgi.util @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.osgi.util) time: 20ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: ManifestConsistencyChecker(org.eclipse.osgi.util) Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: ManifestConsistencyChecker(org.eclipse.osgi.util) time: 0ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: ExtensionPointSchemaBuilder(org.eclipse.osgi.util) Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: ExtensionPointSchemaBuilder(org.eclipse.osgi.util) time: 0ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: ManifestConsistencyChecker(org.eclipse.core.resources) Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: ManifestConsistencyChecker(org.eclipse.core.resources) time: 10ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: ExtensionPointSchemaBuilder(org.eclipse.core.resources) Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: ExtensionPointSchemaBuilder(org.eclipse.core.resources) time: 10ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.team.core) Starting build of org.eclipse.team.core @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.team.core Nothing to build since there are no source folders and no deltas Finished build of org.eclipse.team.core @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.team.core) time: 0ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.jdt.core) Starting build of org.eclipse.jdt.core @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.text About to read state... Successfully read state for org.apache.ant About to read state... Successfully read state for org.eclipse.jdt.core Nothing to build since there are no source folders and no deltas Finished build of org.eclipse.jdt.core @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.jdt.core) time: 160ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.pde.core) Starting build of org.eclipse.pde.core @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.pde.core Number of binary folders/jar files has changed Clearing last state : State for org.eclipse.pde.core (#0 @ Fri Dec 10 11:06:19 CET 2004) FULL build Recording new state : State for org.eclipse.pde.core (#0 @ Fri Dec 10 14:38:23 CET 2004) Finished build of org.eclipse.pde.core @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.pde.core) time: 10ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.debug.core) Starting build of org.eclipse.debug.core @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.core.variables About to read state... Successfully read state for org.eclipse.debug.core Nothing to build since there are no source folders and no deltas Finished build of org.eclipse.debug.core @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.debug.core) time: 20ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.core.resources.win32) Starting build of org.eclipse.core.resources.win32 @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.core.resources.win32 Nothing to build since there are no source folders and no deltas Finished build of org.eclipse.core.resources.win32 @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.core.resources.win32) time: 10ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: ManifestConsistencyChecker(org.eclipse.core.resources.win32) Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: ManifestConsistencyChecker(org.eclipse.core.resources.win32) time: 0ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: ExtensionPointSchemaBuilder(org.eclipse.core.resources.win32) Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: ExtensionPointSchemaBuilder(org.eclipse.core.resources.win32) time: 0ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.core.filebuffers) Starting build of org.eclipse.core.filebuffers @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.core.filebuffers Found binary delta for: org.eclipse.core.resources Clearing last state : State for org.eclipse.core.filebuffers (#0 @ Fri Dec 10 11:06:19 CET 2004) INCREMENTAL build Recording new state : State for org.eclipse.core.filebuffers (#1 @ Fri Dec 10 11:06:19 CET 2004) Finished build of org.eclipse.core.filebuffers @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.core.filebuffers) time: 50ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.ui.workbench) Starting build of org.eclipse.ui.workbench @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.jface About to read state... Successfully read state for org.eclipse.swt About to read state... Successfully read state for org.eclipse.core.expressions About to read state... Successfully read state for org.eclipse.ui.workbench Nothing to build since there are no source folders and no deltas Finished build of org.eclipse.ui.workbench @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.ui.workbench) time: 81ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.ui) Starting build of org.eclipse.ui @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.ui Number of binary folders/jar files has changed Clearing last state : State for org.eclipse.ui (#-1 @ Fri Dec 10 11:06:23 CET 2004) FULL build Recording new state : State for org.eclipse.ui (#0 @ Fri Dec 10 14:38:23 CET 2004) Finished build of org.eclipse.ui @ Fri Dec 10 14:38:23 CET 2004 Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: JavaBuilder(org.eclipse.ui) time: 10ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: ManifestConsistencyChecker(org.eclipse.ui) Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: ManifestConsistencyChecker(org.eclipse.ui) time: 0ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: ExtensionPointSchemaBuilder(org.eclipse.ui) Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Builder finished: ExtensionPointSchemaBuilder(org.eclipse.ui) time: 0ms Fri Dec 10 14:38:23 CET 2004 - [Worker-9] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.ui.workbench.texteditor) Starting build of org.eclipse.ui.workbench.texteditor @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.jface.text About to read state... Successfully read state for org.eclipse.ui.workbench.texteditor Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.ui/ui.jar != Binary classpath directory /org.eclipse.text/bin Clearing last state : State for org.eclipse.ui.workbench.texteditor (#3 @ Fri Dec 10 11:06:23 CET 2004) FULL build Thread[Framework Event Dispatcher,5,main] CPContainer INIT - after resolution Thread[Framework Event Dispatcher,5,main] project: org.eclipse.core.resources.win32 Thread[Framework Event Dispatcher,5,main] container path: org.eclipse.jdt.launching.JRE_CONTAINER Thread[Framework Event Dispatcher,5,main] container: JRE System Library [Sun 1.4.2] { Thread[Framework Event Dispatcher,5,main] C:/apps/java/jdk1.4.2/jre/lib/rt.jar[CPE_LIBRARY][K_BINARY][sourcePath:C:/apps/java/jdk1.4.2/src.zip][isExported:false] Thread[Framework Event Dispatcher,5,main] C:/apps/java/jdk1.4.2/jre/lib/ext/dnsns.jar[CPE_LIBRARY][K_BINARY][isExported:false] Thread[Framework Event Dispatcher,5,main] C:/apps/java/jdk1.4.2/jre/lib/ext/ldapsec.jar[CPE_LIBRARY][K_BINARY][isExported:false] Thread[Framework Event Dispatcher,5,main] C:/apps/java/jdk1.4.2/jre/lib/ext/localedata.jar[CPE_LIBRARY][K_BINARY][isExported:false] Thread[Framework Event Dispatcher,5,main] C:/apps/java/jdk1.4.2/jre/lib/ext/sunjce_provider.jar[CPE_LIBRARY][K_BINARY][isExported:false] Thread[Framework Event Dispatcher,5,main] } Thread[Framework Event Dispatcher,5,main] CPContainer INIT - found initializer Thread[Framework Event Dispatcher,5,main] container ID: org.eclipse.pde.core.requiredPlugins Thread[Framework Event Dispatcher,5,main] class: org.eclipse.pde.internal.core.RequiredPluginsInitializer Thread[Framework Event Dispatcher,5,main] CPContainer INIT - triggering initialization Thread[Framework Event Dispatcher,5,main] project: org.eclipse.core.resources.win32 Thread[Framework Event Dispatcher,5,main] container path: org.eclipse.pde.core.requiredPlugins Thread[Framework Event Dispatcher,5,main] initializer: org.eclipse.pde.internal.core.RequiredPluginsInitializer@35cf9c Thread[Framework Event Dispatcher,5,main] invocation stack trace:
Dirk, from the trace: Starting build of org.eclipse.ui @ Fri Dec 10 14:38:23 CET 2004 About to read state... Successfully read state for org.eclipse.ui Number of binary folders/jar files has changed Clearing last state : State for org.eclipse.ui (#-1 @ Fri Dec 10 11:06:23 CET 2004) FULL build We force full builds when binary folders/jar files are added/removed since it can be counter productive to check references to every type.
But I am pretty sure that the content of the org.eclipse.ui didn't change. I shutdown my workspace and started it again and I have org.eclipse.ui imported as binary into the workspace.
And you're surprised that PDE (or someone else?) changed things unexpectedly during the restart? ;)
Kent, any actions planned. This behaviour is really driving me nuts. After every restart I have to wait 10 minutes. Here is my latest debug output. I closed Eclipse after a ful build and opened it again which triggered the next full build. Thu Dec 16 18:07:11 CET 2004 - [Worker-3] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.osgi.services) Starting build of org.eclipse.osgi.services @ Thu Dec 16 18:07:11 CET 2004 About to read state... Successfully read state for org.eclipse.osgi.services Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/osgi.jar Clearing last state : State for org.eclipse.osgi.services (#0 @ Thu Dec 16 17:59:30 CET 2004) FULL build Recording new state : State for org.eclipse.osgi.services (#0 @ Thu Dec 16 18:07:11 CET 2004) Finished build of org.eclipse.osgi.services @ Thu Dec 16 18:07:12 CET 2004 Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Builder finished: JavaBuilder(org.eclipse.osgi.services) time: 470ms Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Invoking (INCREMENTAL_BUILD) on builder: ManifestConsistencyChecker(org.eclipse.osgi.services) Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Builder finished: ManifestConsistencyChecker(org.eclipse.osgi.services) time: 0ms Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Invoking (INCREMENTAL_BUILD) on builder: ExtensionPointSchemaBuilder(org.eclipse.osgi.services) Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Builder finished: ExtensionPointSchemaBuilder(org.eclipse.osgi.services) time: 0ms Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.osgi.util) Starting build of org.eclipse.osgi.util @ Thu Dec 16 18:07:12 CET 2004 About to read state... Successfully read state for org.eclipse.osgi.util Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/osgi.jar Clearing last state : State for org.eclipse.osgi.util (#0 @ Thu Dec 16 17:59:30 CET 2004) FULL build Recording new state : State for org.eclipse.osgi.util (#0 @ Thu Dec 16 18:07:12 CET 2004) Finished build of org.eclipse.osgi.util @ Thu Dec 16 18:07:12 CET 2004 Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Builder finished: JavaBuilder(org.eclipse.osgi.util) time: 10ms Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Invoking (INCREMENTAL_BUILD) on builder: ManifestConsistencyChecker(org.eclipse.osgi.util) Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Builder finished: ManifestConsistencyChecker(org.eclipse.osgi.util) time: 0ms Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Invoking (INCREMENTAL_BUILD) on builder: ExtensionPointSchemaBuilder(org.eclipse.osgi.util) Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Builder finished: ExtensionPointSchemaBuilder(org.eclipse.osgi.util) time: 0ms Thu Dec 16 18:07:12 CET 2004 - [Worker-3] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(org.eclipse.jdt.ui) Starting build of org.eclipse.jdt.ui @ Thu Dec 16 18:07:12 CET 2004 About to read state... Successfully read state for org.eclipse.ui About to read state... Successfully read state for org.eclipse.swt About to read state... Successfully read state for org.eclipse.jface About to read state... Successfully read state for org.eclipse.ui.workbench About to read state... Successfully read state for org.eclipse.ui.console About to read state... Successfully read state for org.eclipse.help About to read state... Successfully read state for org.eclipse.core.expressions About to read state... Successfully read state for org.eclipse.core.resources About to read state... Successfully read state for org.eclipse.jdt.core About to read state... Successfully read state for org.eclipse.search About to read state... Successfully read state for org.eclipse.debug.core About to read state... Successfully read state for org.eclipse.debug.ui About to read state... Successfully read state for org.eclipse.jdt.launching About to read state... Successfully read state for org.eclipse.compare About to read state... Successfully read state for org.eclipse.team.core About to read state... Successfully read state for org.eclipse.jface.text About to read state... Successfully read state for org.eclipse.text About to read state... Successfully read state for org.eclipse.ui.workbench.texteditor About to read state... Successfully read state for org.eclipse.ui.ide About to read state... Successfully read state for org.eclipse.ui.views About to read state... Successfully read state for org.eclipse.ui.editors About to read state... Successfully read state for org.eclipse.core.filebuffers About to read state... Successfully read state for org.eclipse.core.runtime.compatibility About to read state... Successfully read state for org.eclipse.core.runtime About to read state... Successfully read state for org.eclipse.osgi About to read state... Successfully read state for org.eclipse.update.configurator About to read state... Successfully read state for org.eclipse.ltk.core.refactoring About to read state... Successfully read state for org.eclipse.ltk.ui.refactoring About to read state... Successfully read state for org.eclipse.ui.forms About to read state... Successfully read state for org.eclipse.jdt.ui Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.ui/ui.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.ui/ui.jar Clearing last state : State for org.eclipse.jdt.ui (#0 @ Thu Dec 16 18:00:07 CET 2004) FULL build
The next time I got: Starting build of org.eclipse.core.filebuffers @ Thu Dec 16 18:16:53 CET 2004 Performing full build since last saved state was not found FULL build Which basically triggered building the whole workspace again.
Same for Starting build of org.eclipse.jdt.ui @ Thu Dec 16 18:21:35 CET 2004 Performing full build since last saved state was not found FULL build
2 things: 1. from your trace it appears that jar files are being reordered: Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/osgi.jar & Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/osgi.jar 2. but then your project shows what we have seen a few times (but have no explanation for): Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.ui/ui.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.ui/ui.jar Our comparison for jar files is nothing but the path. There is no timestamp or version check, so how are these 2 paths different? So questions: - are you changing any access restrictions? - are you picking up changes to prereq projects that may reorder their classpaths? - is the timestamp of any affected classpath file changed? - is your workspace saving successfully? Any crash could account for the full build on restart. FYI: The builder has not changed in months (except for adding access restriction support). As far as I know the JavaModel nor PDE is playing with classpath files (please check timestamps to verify).
Are you changing any access restrictions: I lately added the following access restriction **/internal/** to ZRH projects (including jdt.ui) Are you picking up changes to prereq projects that may reorder their classpaths? Not that I am aware of. The rebuild logs I atttached are from scenarios where I closed Eclipse and immediatelly restarted it. No new install no sync with repository. Is the timestamp of any affected classpath file changed? Same as above. I simply closed Eclipse and restarted. So no classpath file change Is your workspace saving successfully? Any crash could account for the full build on restart Its svaing correctly. At least that's what I assume since there is nothing in the log file.
Changing access restrictions will cause a full build but not the constant ones you are seeing. What are the dates/times of your .classpath files? Have any changed in the last few weeks that you can not account for... ?
Other than adding the access restrictions the classpath files didn't change. I checked the time stamps of some of my .classpath files. For example the one from jdt.ui has a time stamp 12.12.2004. This is when I added the access restrictions.
I noticed that 3.1M4 is released. Is this one fixed?
Kent, updating Eclipse and restarting again a full build was triggered. Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.ui/ui.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.ui/ui.jar Clearing last state : State for org.eclipse.jdt.ui (#9 @ Wed Dec 22 11:53:34 CET 2004) FULL build Is there anything I can do to get further information why org.eclipse.ui/ui.jar != org.eclipse.ui/ui.jar
I took the jump and installed 3.1M4. I think I will have to revert again. This one is not fixed... Starting build of <project> @ Wed Jan 05 08:45:04 CET 2005 FULL build No further info can be deduced from the debug tracing.
Tagging for M5. Kent - could you make our trace more verbose so as to better narrow down what is going on ? If path comparisons are failing or containers provide no stable ordering we should better point the finger at offending components.
Thanks to Dirk, we have a fix for a build state problem with AccessRestrictions. Its released into HEAD now. Dirk is stilling having another problem which we're still investigating.
The other problem I am having comes from an unstable number of prerequisite jars. I will outline the problem using an example: - project org.eclipse.ui.workbench.texteditor which I have in source - the project uses a PDE Classpath container to get access to prerequisite projects and libraries - when a class path change is detected in the Java builder the state looks as follows: newBinaryLocation: size 6: First entry: Source classpath directory /org.eclipse.ui.workbench.texteditor/src with binary directory /org.eclipse.ui.workbench.texteditor/bin Remaining entries: JDK libraries oldBinaryLocation: size 19: First entry as above Entries 1 - 13: the prerequistie jars and bin directories: for example classpath jar file C:/.../org.eclipse.core.runtime/runtime.jar Binary classpath directory /org.eclipse.jface.text/bin Entries 14 -18: JDK libraries My workspace layout is as follows: - self contained workspace. I don't use libraries from the installation - binary projects are imported, not linked - all source projects use a PDE class path container Let me know if you need further details.
Wassim, what has changed on the PDE front in the last few months? Some change is causing prereq jars to disappear from the classpath. Start at comment 19.
The PDE code has not changed in this area (for better or worse) since 3.0. We have not done anything special -yet- for the new JDT restriction support.
The access restriction support has nothing to do with Dirk's current problem. His setup is likely a good starting point. How is your test suite coming for all the various valid setups?
Why is the product changed from JDT to PDE? I am having this problem constantly with only regular Java projects. I do not develop plugins. Ringo
Wassim, I can constantly reproduce the problem. Is there anything I can do to figure out why the required plug-ins are missing.
I don't think it's a case of missing pre-reqs. If pre-reqs were missing, then your code would have compilation errors. But there are no errors... The two stack sizes in comment 28 would make sense if one (of size 6) corresponded to the classpath before the PDE container was resolved and the other one (of size 19) for the classpath after the container resolution. is it possible that the 'oldBinaryLocation' and 'newBinaryLocation' labels are reversed? I would need to have access to your workspace to figure out what is going on.
Wassim, the workspace is HUGE!. All I can offer is pair debugging if this helps.
One additional note to the compiler errors: what happens after the build kicks is that most of the projects actually do get compile errors. But then another build kicks in which remove the compile errors again.
The latest pde.core code in cvs now has a new flag (org.eclipse.pde.core/classpath) in its .options file. When turned on, it will print the concise list of classpath entries (dependencies) that PDE returns whenever JDT asks us to resolve the container for each plugin. We also print "********Returned an empty container" when returning empty. In Dirk's scenario, when he launches Eclipse on an existing workspace, we must never return empty.
I tested it with the new PDE option and here is the result (I will attach the full log until the build kicked in) - I get a mismatch in org.eclipse.ltk.ui.refactoring - new binary location (size 6): Source classpath directory /org.eclipse.ltk.ui.refactoring/src with binary directory /org.eclipse.ltk.ui.refactoring/bin Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/dnsns.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/ldapsec.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/localedata.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/sunjce_provider.jar - old binary location (size 26): Source classpath directory /org.eclipse.ltk.ui.refactoring/src with binary directory /org.eclipse.ltk.ui.refactoring/bin Classpath jar file C:/.../org.eclipse.core.runtime/runtime.jar Classpath jar file C:/.../org.eclipse.osgi/osgi.jar Classpath jar file C:/.../org.eclipse.osgi/core.jar Classpath jar file C:/.../org.eclipse.osgi/resolver.jar Classpath jar file C:/.../org.eclipse.osgi/defaultAdaptor.jar Classpath jar file C:/.../org.eclipse.osgi/eclipseAdaptor.jar Classpath jar file C:/.../org.eclipse.osgi/console.jar Binary classpath directory /org.eclipse.core.expressions/bin Binary classpath directory /org.eclipse.core.filebuffers/bin Classpath jar file C:/.../org.eclipse.core.resources/resources.jar Binary classpath directory /org.eclipse.text/bin Binary classpath directory /org.eclipse.ltk.core.refactoring/bin Classpath jar file C:/.../org.eclipse.jdt.core/jdtcore.jar Binary classpath directory /org.eclipse.jface.text/bin Classpath jar file C:/.../org.eclipse.ui/ui.jar Classpath jar file C:/.../org.eclipse.swt/ws/win32/swt.jar Classpath jar file C:/.../org.eclipse.jface/jface.jar Binary classpath directory /org.eclipse.ui.workbench/bin Classpath jar file C:/.../org.eclipse.compare/compare.jar Binary classpath directory /org.eclipse.ui.workbench.texteditor/bin Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/dnsns.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/ldapsec.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/localedata.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/sunjce_provider.jar And the relevant protion of the PDE log: Dependencies for plugin 'org.eclipse.ltk.ui.refactoring': /org.eclipse.core.runtime[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.core.expressions[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.core.filebuffers[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.core.resources[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.text[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.ltk.core.refactoring[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.jdt.core[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.jface.text[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.ui[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.compare[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.ui.workbench.texteditor[CPE_PROJECT][K_SOURCE][isExported:false]
Other plug-ins that get compiled basically show the same symptoms. Let me know if you need the full log.
dirk, it's not a mismatch. It's just that the two stacks are printing two equivalent views of the classpath. For example, in the PDE stack, the entry /org.eclipse.ui[CPE_PROJECT][K_SOURCE][isExported:false] is fine because all we need to do in pde is add the org.eclipse.ui project classpath entry to your plugin's classpath and it will indirectly get all the reexported dependencies of org.eclipse.ui (e.g. org.eclipse.swt, org.eclipse.jface..) Meanwhile, the JDT/Core stack digs in deeper and shows just that: Classpath jar file C:/.../org.eclipse.ui/ui.jar Classpath jar file C:/.../org.eclipse.swt/ws/win32/swt.jar Classpath jar file C:/.../org.eclipse.jface/jface.jar So this is all pretty good on the plugin pre-req front. Any ""********Returned an empty container" messages in the log?
How can you see this a match? The 20 expanded entries are not there, but they were when we successfully built the project & wrote out its state.
I meant that going by absolute number of entries between the pde and jdt stacks is misleading, because pde is spitting out the classpath entries as-is and jdt is expanding them to spit out all the jars that are on the classpath. Still not clear to me (a non-jdt guy) at what stage 'old binary location' and 'new binary location' are getting printed and what they mean. Dirk, please attach the full log, as I would like to ensure that the classpath printed by PDE is complete all the time and no "empty container" is returned.
Wassim, to clarify. We are seeing a mismatch in between the fully resolved/expanded classpath. All entries mentionned in old and new state are extracted from classpath containers and classpath variables. It seems that the PDE container is empty, and thus does not contribute any actual entries anymore.
The old entries are those persisted in the build state file, which we read back on startup. The new entries are these obtained when asking the project fully resolved classpath (recursively considering exported entries from prereq projects). If there is a mismatch, we consider the classpath has changed, and trigger a full rebuild, which in this case is doomed as many entries are missing. But then another build kicks in, and this time, it has the right info. Smells like a timing issue ?
thanks Philippe. The tracing coming from PDE is in the RequiredPluginsClasspathContainer.getClasspathEntries() which JDT calls to get the resolved container. In the excerpt from comment 38, this method is not returning an empty array (unless the plugin has no dependencies as in the case of org.eclipse.swt of course). We are still waiting for the full trace from Dirk to verify that every single call to getClasspathEntries() is returning a non-empty result. Not sure how the new state is computed, but do you think it's possible that the "new binary location" is being computed before the pde container returns with a result?
That shouldn't be possible; unless there is some bad reentrance scenario (where we defensively consider containers to be empty if they ask the question again while being resolved). Dirk - did you also enable the classpath initialization trace ? It should show what the container initializer answers when requested its classpath entries.
Turning classpath initialization on produces a huge trace so I will only provide the more interesting parts. This time the diff occurred on org.eclipse.jface.text and the relevant pieces form the trace are: Thread[All Types Caching,4,main] CPContainer INIT - triggering initialization Thread[All Types Caching,4,main] project: org.eclipse.jface.text Thread[All Types Caching,4,main] container path: org.eclipse.pde.core.requiredPlugins Thread[All Types Caching,4,main] initializer: org.eclipse.pde.internal.core.RequiredPluginsInitializer@1bbfd3a Thread[All Types Caching,4,main] invocation stack trace: Thread[Framework Event Dispatcher,5,main] CPContainer SET - updating affected project due to setting container Thread[Framework Event Dispatcher,5,main] project: org.eclipse.text Thread[Framework Event Dispatcher,5,main] container path: org.eclipse.jdt.launching.JRE_CONTAINER java.lang.Exception: <Fake exception> at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1267) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:848) at org.eclipse.jdt.internal.core.ClasspathEntry.validateClasspathEntry(ClasspathEntry.java:1099) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2003) at org.eclipse.jdt.internal.core.DeltaProcessingState$ProjectUpdateInfo.updateProjectReferencesIfNecessary(DeltaProcessingState.java:98) at org.eclipse.jdt.internal.core.DeltaProcessingState.performClasspathResourceChange(DeltaProcessingState.java:223) at org.eclipse.jdt.internal.core.SetClasspathOperation.updateProjectReferencesIfNecessary(SetClasspathOperation.java:784) at org.eclipse.jdt.internal.core.SetClasspathOperation.executeOperation(SetClasspathOperation.java:243) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:700) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1688) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:744) at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:2739) at org.eclipse.jdt.core.JavaCore$3.run(JavaCore.java:3736) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:34) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:700) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1688) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:3549) at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:3719) at org.eclipse.jdt.internal.launching.JREContainerInitializer.initialize(JREContainerInitializer.java:51) at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1274) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:848) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1262) at org.eclipse.jdt.internal.core.search.JavaSearchScope.add(JavaSearchScope.java:134) at org.eclipse.jdt.internal.core.search.JavaWorkspaceScope.initialize(JavaWorkspaceScope.java:80) at org.eclipse.jdt.internal.core.search.JavaSearchScope.<init>(JavaSearchScope.java:56) at org.eclipse.jdt.internal.core.search.JavaWorkspaceScope.<init>(JavaWorkspaceScope.java:31) at org.eclipse.jdt.internal.core.search.SearchBasicEngine.createWorkspaceScope(SearchBasicEngine.java:147) at org.eclipse.jdt.core.search.SearchEngine.createWorkspaceScope(SearchEngine.java:372) at org.eclipse.jdt.internal.corext.util.AllTypesCache.search(AllTypesCache.java:556) at org.eclipse.jdt.internal.corext.util.AllTypesCache$TypeCacher.doSearchTypes(AllTypesCache.java:197) at org.eclipse.jdt.internal.corext.util.AllTypesCache$TypeCacher.run(AllTypesCache.java:159) Dependencies for plugin 'org.eclipse.jface.text': /org.eclipse.core.runtime[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.text[CPE_PROJECT][K_SOURCE][isExported:true] /org.eclipse.swt[CPE_PROJECT][K_SOURCE][isExported:false] /org.eclipse.jface[CPE_PROJECT][K_SOURCE][isExported:false] ============== lots of other output ================================== Starting build of org.eclipse.jface.text @ Fri Jan 07 10:01:53 CET 2005 About to read state... Successfully read state for org.eclipse.jface.text Thread[Framework Event Dispatcher,5,main] CPContainer INIT - after resolution Thread[Framework Event Dispatcher,5,main] project: org.junit Thread[Framework Event Dispatcher,5,main] container path: org.eclipse.jdt.launching.JRE_CONTAINER Thread[Framework Event Dispatcher,5,main] container: JRE System Library [Sun 1.4.2] { Thread[Framework Event Dispatcher,5,main] C:/apps/java/jdk1.4.2/jre/lib/rt.jar[CPE_LIBRARY][K_BINARY][sourcePath:C:/apps/java/jdk1.4.2/src.zip][isExported:false] Thread[Framework Event Dispatcher,5,main] C:/apps/java/jdk1.4.2/jre/lib/ext/dnsns.jar[CPE_LIBRARY][K_BINARY][isExported:false] Thread[Framework Event Dispatcher,5,main] C:/apps/java/jdk1.4.2/jre/lib/ext/ldapsec.jar[CPE_LIBRARY][K_BINARY][isExported:false] Thread[Framework Event Dispatcher,5,main] C:/apps/java/jdk1.4.2/jre/lib/ext/localedata.jar[CPE_LIBRARY][K_BINARY][isExported:false] Thread[Framework Event Dispatcher,5,main] C:/apps/java/jdk1.4.2/jre/lib/ext/sunjce_provider.jar[CPE_LIBRARY][K_BINARY][isExported:false] Thread[Framework Event Dispatcher,5,main] } Thread[Framework Event Dispatcher,5,main] CPContainer INIT - found initializer Thread[Framework Event Dispatcher,5,main] container ID: org.eclipse.pde.core.requiredPlugins Thread[Framework Event Dispatcher,5,main] class: org.eclipse.pde.internal.core.RequiredPluginsInitializer Thread[Framework Event Dispatcher,5,main] CPContainer INIT - triggering initialization Thread[Framework Event Dispatcher,5,main] project: org.junit Thread[Framework Event Dispatcher,5,main] container path: org.eclipse.pde.core.requiredPlugins Thread[Framework Event Dispatcher,5,main] initializer: org.eclipse.pde.internal.core.RequiredPluginsInitializer@1508393 Thread[Framework Event Dispatcher,5,main] invocation stack trace: java.lang.Exception: <Fake exception> at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1267) at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:1239) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:846) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1262) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2033) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1946) at org.eclipse.jdt.internal.core.PackageFragmentRoot.validateOnClasspath(PackageFragmentRoot.java:790) at org.eclipse.jdt.internal.core.PackageFragmentRoot.exists(PackageFragmentRoot.java:351) at org.eclipse.jdt.internal.ui.workingsets.JavaWorkingSetUpdater.checkElementExistence(JavaWorkingSetUpdater.java:202) at org.eclipse.jdt.internal.ui.workingsets.JavaWorkingSetUpdater.add(JavaWorkingSetUpdater.java:77) at org.eclipse.ui.internal.AbstractWorkingSetManager.bundleChanged(AbstractWorkingSetManager.java:472) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:1151) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:186) at org.eclipse.osgi.framework.eventmgr.EventThread.run(EventThread.java:104)
I started it again and this time I found lots of ********Returned an empty container in the trace.
I will attach the full trace of another start where a mismatched occurred for project org.eclipse.jdt.ui.tests.refactoring. Number of old binaries was 32, new is 24.
Created attachment 16987 [details] The trace
Dirk, just to make sure: in the instances when ********Returned an empty container were reported, did you import anything into your workspace or did you merely launch on an existing workspace and watched these statements being printed?
This defect is all about restarting an existing (build) workspace, and suffering a full rebuild during startup sequence.
dirk, please try the latest pde.core from head and report back.
actually, dirk, never mind. still investigating how this race scenario could occur to come up with a proper fix.
*** Bug 82699 has been marked as a duplicate of this bug. ***
I tested it with the I build form I20050112-1200 and I still build on start-up. Here is the beginning of the trace. I will enable PDE tracing to see what is goind on: Install location: file:/c:/apps/eclipse/latest/ Configuration file: file:/c:/apps/eclipse/latest/configuration/config.ini loaded Configuration location: file:/c:/apps/eclipse/latest/configuration/ Configuration file: file:/c:/apps/eclipse/latest/configuration/config.ini loaded Framework located: file:/c:/apps/eclipse/latest/plugins/org.eclipse.osgi_3.1.0/ Loading framework classpath from: file:/c:/apps/eclipse/latest/plugins/org.eclipse.osgi_3.1.0/eclipse.properties Framework classpath: file:/c:/apps/eclipse/latest/plugins/org.eclipse.osgi_3.1.0/core.jar file:/c:/apps/eclipse/latest/plugins/org.eclipse.osgi_3.1.0/console.jar file:/c:/apps/eclipse/latest/plugins/org.eclipse.osgi_3.1.0/osgi.jar file:/c:/apps/eclipse/latest/plugins/org.eclipse.osgi_3.1.0/resolver.jar file:/c:/apps/eclipse/latest/plugins/org.eclipse.osgi_3.1.0/defaultAdaptor.jar file:/c:/apps/eclipse/latest/plugins/org.eclipse.osgi_3.1.0/eclipseAdaptor.jar Splash location: c:\apps\eclipse\latest\plugins\org.eclipse.platform_3.1.0\splash.bmp Debug options: file:/C:/apps/eclipse/latest/.options loaded Time to load bundles: 41 [YourKit Java Profiler 3.2 #451] Listening on port 10000... Starting application: 2058 Starting build of org.eclipse.osgi.services @ Thu Jan 13 11:38:13 CET 2005 About to read state... Successfully read state for org.eclipse.osgi.services Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/osgi.jar Clearing last state : State for org.eclipse.osgi.services (#0 @ Thu Jan 13 11:02:13 CET 2005) FULL build Recording new state : State for org.eclipse.osgi.services (#0 @ Thu Jan 13 11:38:13 CET 2005) Finished build of org.eclipse.osgi.services @ Thu Jan 13 11:38:14 CET 2005 Starting build of org.eclipse.ant.core @ Thu Jan 13 11:38:15 CET 2005 About to read state... Successfully read state for org.eclipse.ant.core Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.core.variables/variables.jar Clearing last state : State for org.eclipse.ant.core (#0 @ Thu Jan 13 11:04:27 CET 2005) FULL build Recording new state : State for org.eclipse.ant.core (#0 @ Thu Jan 13 11:38:15 CET 2005) Finished build of org.eclipse.ant.core @ Thu Jan 13 11:38:15 CET 2005 Starting build of org.eclipse.osgi.util @ Thu Jan 13 11:38:15 CET 2005 About to read state... Successfully read state for org.eclipse.osgi.util Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/osgi.jar Clearing last state : State for org.eclipse.osgi.util (#0 @ Thu Jan 13 11:02:13 CET 2005) FULL build Recording new state : State for org.eclipse.osgi.util (#0 @ Thu Jan 13 11:38:15 CET 2005) Finished build of org.eclipse.osgi.util @ Thu Jan 13 11:38:15 CET 2005 Starting build of org.eclipse.ui.workbench @ Thu Jan 13 11:38:16 CET 2005 About to read state... Successfully read state for org.eclipse.core.runtime About to read state... Successfully read state for org.eclipse.osgi About to read state... Successfully read state for org.eclipse.help About to read state... Successfully read state for org.eclipse.jface About to read state... Successfully read state for org.eclipse.swt About to read state... Successfully read state for org.eclipse.core.expressions About to read state... Successfully read state for org.eclipse.ui.workbench Found source delta for: org.eclipse.ui.workbench Clearing last state : State for org.eclipse.ui.workbench (#0 @ Thu Jan 13 11:02:54 CET 2005) INCREMENTAL build Recording new state : State for org.eclipse.ui.workbench (#1 @ Thu Jan 13 11:02:54 CET 2005) Finished build of org.eclipse.ui.workbench @ Thu Jan 13 11:38:16 CET 2005 Starting build of org.eclipse.help.appserver @ Thu Jan 13 11:38:35 CET 2005 About to read state... Successfully read state for org.eclipse.help.appserver Nothing to build since there are no source folders and no deltas Finished build of org.eclipse.help.appserver @ Thu Jan 13 11:38:35 CET 2005 Starting build of org.eclipse.help.base @ Thu Jan 13 11:38:35 CET 2005 About to read state... Successfully read state for org.eclipse.help.base Number of binary folders/jar files has changed: Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.help.base/helpbase.jar was: Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.help.base/helpbase.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.apache.lucene/parser.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.apache.lucene/lucene-1.3-final.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.help/help.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.help.appserver/appserver.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.core.runtime/runtime.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/osgi.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/core.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/resolver.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/defaultAdaptor.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/eclipseAdaptor.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/console.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/dnsns.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/ldapsec.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/localedata.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/sunjce_provider.jar Clearing last state : State for org.eclipse.help.base (#0 @ Thu Jan 13 11:02:13 CET 2005) FULL build Recording new state : State for org.eclipse.help.base (#0 @ Thu Jan 13 11:38:35 CET 2005) Finished build of org.eclipse.help.base @ Thu Jan 13 11:38:35 CET 2005 Starting build of org.eclipse.jdt.debug @ Thu Jan 13 11:38:36 CET 2005 About to read state... Successfully read state for org.eclipse.jdt.debug Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.core.resources/resources.jar Clearing last state : State for org.eclipse.jdt.debug (#0 @ Thu Jan 13 11:04:27 CET 2005) FULL build Recording new state : State for org.eclipse.jdt.debug (#0 @ Thu Jan 13 11:38:36 CET 2005) Finished build of org.eclipse.jdt.debug @ Thu Jan 13 11:38:36 CET 2005 Starting build of org.eclipse.jface @ Thu Jan 13 11:38:37 CET 2005 Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.swt/ws/win32/swt.jar Clearing last state : State for org.eclipse.jface (#0 @ Thu Jan 13 11:02:13 CET 2005) FULL build Recording new state : State for org.eclipse.jface (#0 @ Thu Jan 13 11:38:37 CET 2005) Finished build of org.eclipse.jface @ Thu Jan 13 11:38:37 CET 2005 Starting build of org.eclipse.help.base @ Thu Jan 13 11:38:38 CET 2005 About to read state... Successfully read state for org.apache.lucene Number of binary folders/jar files has changed: Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.help.base/helpbase.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.apache.lucene/parser.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.apache.lucene/lucene-1.3-final.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.help/help.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.help.appserver/appserver.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.core.runtime/runtime.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/osgi.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/core.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/resolver.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/defaultAdaptor.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/eclipseAdaptor.jar Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.osgi/console.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/dnsns.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/ldapsec.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/localedata.jar Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/ext/sunjce_provider.jar was: Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.help.base/helpbase.jar Clearing last state : State for org.eclipse.help.base (#0 @ Thu Jan 13 11:38:35 CET 2005) FULL build Recording new state : State for org.eclipse.help.base (#0 @ Thu Jan 13 11:38:38 CET 2005) Finished build of org.eclipse.help.base @ Thu Jan 13 11:38:38 CET 2005 Starting build of org.eclipse.core.variables @ Thu Jan 13 11:38:39 CET 2005 About to read state... Successfully read state for org.eclipse.core.variables Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar != Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.core.runtime/runtime.jar Clearing last state : State for org.eclipse.core.variables (#0 @ Thu Jan 13 11:02:13 CET 2005) FULL build Recording new state : State for org.eclipse.core.variables (#0 @ Thu Jan 13 11:38:39 CET 2005) Finished build of org.eclipse.core.variables @ Thu Jan 13 11:38:39 CET 2005 Starting build of org.eclipse.core.variables @ Thu Jan 13 11:38:39 CET 2005 Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.core.runtime/runtime.jar != Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar Clearing last state : State for org.eclipse.core.variables (#0 @ Thu Jan 13 11:38:39 CET 2005) FULL build Recording new state : State for org.eclipse.core.variables (#0 @ Thu Jan 13 11:38:39 CET 2005) Finished build of org.eclipse.core.variables @ Thu Jan 13 11:38:39 CET 2005 Starting build of org.eclipse.jface @ Thu Jan 13 11:38:40 CET 2005 Classpath jar file C:/home/dbaeumer/devel/workspaces/eclipse/Head/org.eclipse.swt/ws/win32/swt.jar != Classpath jar file C:/apps/java/jdk1.4.2/jre/lib/rt.jar Clearing last state : State for org.eclipse.jface (#0 @ Thu Jan 13 11:38:37 CET 2005) FULL build Recording new state : State for org.eclipse.jface (#0 @ Thu Jan 13 11:38:40 CET 2005) Finished build of org.eclipse.jface @ Thu Jan 13 11:38:40 CET 2005 Starting build of MultiElementViewer @ Thu Jan 13 11:38:40 CET 2005 About to read state... Successfully read state for MultiElementViewer Found binary delta for: org.eclipse.jface Clearing last state : State for MultiElementViewer (#0 @ Thu Jan 13 11:02:13 CET 2005) INCREMENTAL build Recording new state : State for MultiElementViewer (#1 @ Thu Jan 13 11:02:13 CET 2005) Finished build of MultiElementViewer @ Thu Jan 13 11:38:40 CET 2005
Created attachment 17129 [details] Another trace Attached a trace witk PDE enabled. Wassim, can you change the tracing so that the container gets only printed when it is resolved first. I tried to enable class path resolution as well but this generates a huge trace which doesn't fit into the console. Kent, could the class path resolution trace be made a little bit more compact.
Dirk - the builder doesn't produce the classpath resolution trace. Philippe can you look at it?
dirk, the portion of the pde trace that shows that an empty container was returned is actually the interesting portion. This transient result is the one that is falsely telling JDT that the container has changed in value (ie. empty vs. the persisted correct one) and causing a rebuild. It would be interesting to see it intermingled with JDT tracing.
Ringo (comment 32), If you have not already done so, I suggest you open a separate bug report against JDT to track your problem, since what is being investigated here is specific to plug-in projects and will not help you.
I spent some time to find out the difference between my workspace and the others since not all users are seeing the build on startup. One thing that might be different is that I have working sets which have packages as top level elements. For M3 Platform/UI and JDT/UI introduced the concept of working set updaters to avoid stale working sets (for example if you reneme a package a reference in a working set will be updated as well). When such an updater gets installed it first checks if the elements of the working set still exists. It does so my calling IJavaElement#exists. Calling exists on a IPackageFragement causes its class path to get initialized. Tracing this reveals that there seems to be situations where the class path gets initialized from two threads (one is triggered through the check done by the updater). Could it be that this results in situations where one thread receives a bogus answer ? Jerome, I discussed this with Philippe and he mentioned to CC you.
I get a full re-build every time I upgrade my dev environment. (first start-up only) Which debug options should I try to get more info?
DJ, a build the first time you launch after you upgrade dev environments is normal as JARs in your target that are referenced by workspace plugins would have changed timestamps.
Even when I have all of Core (OSGi, Runtime, Resources, etc) as projects in the workspace?
In that case, it's self-contained. then no, my (former) friend DJ. Dirk, what tracing flags did you turn on to get something like what is in comment 28? The classpath resolution traces in my case always seem ok and thus are not helping track this problem.
org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/builder=true org.eclipse.pde.core/debug=true org.eclipse.pde.core/classpath=true
You may also want to enable: org.eclipse.jdt.core/debug/cpresolution=true Also be careful than tracing may change concurrency characteristics.
actually, DJ, the core.runtime.compatibility plugin requires org.eclipse.update.configurator, which I presume is not in your workspace. So you workspace may not be as self-contained as you think.
Your assumption is....correct. I will add it to my workspace and then see if I get the same problem next time I upgrade the build. If so, then I will run the tracing code.
I also see this from time to time and there's a similar observation reported on the newsgroup: news://news.eclipse.org:119/PseNxdOCFHA.1960@fairy.ao.nlmk
I still have this happen occasionally, including with today's 3.1 M5 candidate build (I20050218-1200). If my workspace starts up in the Java perspective, and I quickly do a Ctrl+Shift+T to open a type - I get an "operation blocked" dialog, followed by a full build of my workspace.
John's comment seems to provide the test case. Exactly the same happened to me just now (using I20050217-2000). In my scenario the CVS Update job was still running while I presses Ctrl+Shift+SPACE and I was in the Java Browsing perspective.
What's happening with this bug? It's marked with a milestone of M5, but it is still very easily reproducible in the 3.1 M6 test candidate. This bug is a daily pain for me, as I often end up incurring a full rebuild on startup unless I patiently wait for all background activity to finish before doing anything.
I have tried ctrl-shift-T until I was blue in the face, and I was never able to reproduce it even once.
I will again call for someone can provide me with a workspace in which the problem is reproducible.
We can wait until next week to investigate this - I just entered my comments yesterday out of frustration as I waited for a full rebuild <g>. I will try next week to build a workspace from scratch in which it is easily reproduced. At the very least, I can get you my workspace next week in which I can easily reproduce. My steps are described in bug 82699 (the keys are having no editors open, starting in the Java perspective). However, it might be related to a specific attribute of my layout or setup, so we can try to isolate that next week.
Not sure if this is relevant, but bug 91685 could explain the full build problem: sometimes the PDE container returns classpath entries in a different order than it was on shutdown.
Here is a consistently reproducible test case, using I20050413-0910 1) Open a new workspace 2) Import my preferences (separate attachment) 3) Open "Sumatra" perspective 4) Switch to CVS repository exploring perspective 5) Checkout platform-core and platform-ui modules from HEAD using the anon pserver connection. 6) Switch to "Sumatra" perspective 7) Close all other perspectives, and ensure all editors are closed. 8) Make sure Package Explorer is on top of upper-left stack. 9) Wait for checkout and autobuild to complete if they are still running. 10) Shutdown and restart. 11) As soon as the UI comes up, hit Ctrl+Shift+T to open the types dialog. If nothing seems to happen, hit Ctrl+Shift+T a few times. If this doesn't cause a build, dismiss the dialog as soon as it opens by pressing Esc, and then hit Ctrl+Shift+T again. Repeat if necessary.
Created attachment 20016 [details] John's preference export file
Michael Valenta and I have both seen full builds at startup using the I20050509-2010 test candidate build. In neither case was it the first startup after installing the build, and nothing in the configuration or target platform had changed. I don't have a reproducible case. The reproducible steps from comment #78 no longer apply since the new open type dialog was released (should still be reproducible using I20050413-0910). Is there a debug flag I can turn on to print when a full build was triggered due to a classpath change, without getting the verbose Java builder debug output? I could run with that flag on all the time to see if I can confirm if this is the same problem that's been occurring for the past six months.
I am seeing full builds now very frequently too. Very disconcerting. Raising priority.
Glad to see it's not just me :) I seem to get substantial builds on every startup of my development workspace with the I20050512-1200 build. It's possibly completely unrelated to my old intermittent problem.
but the common link among old and new is the visibility of the synchronize view.
I am seeing more frequent fullbuild as well. Seems related to changes near access rules. Could be a consequence of PDE container evolutions lately.
Created attachment 21117 [details] Builder trace output using I20050512-1200 The easiest way to reproduce seems to be to startup in Java perspective with an editor open, immediately shutdown and restart, and then it does a full build. I have attached the complete output from the jdt.core builder tracing, and it has many entries that look roughly like this: Starting build of org.eclipse.ui.console @ Fri May 13 11:04:01 EDT 2005 About to read state... Successfully read state for org.eclipse.ui.console Classpath jar file D:/vm/sidecar/jre/lib/ext/dumpfmt.jar != Binary classpath directory /org.eclipse.ui/bin with AccessRuleSet { pattern=org/eclipse/ui/internal/* (DISCOURAGED) pattern=**/* (NON ACCESSIBLE) } [template:"The type {0} is not accessible due to restriction on required project org.eclipse.ui"] Clearing last state : State for org.eclipse.ui.console (#5 @ Fri May 13 09:44:52 EDT 2005) FULL build I.e., it thinks the classpaths have changed and as a result is deciding to do a full build.
this entry for example: Classpath jar file D:/vm/sidecar/jre/lib/ext/dumpfmt.jar != Binary classpath directory /org.eclipse.core.runtime/bin with AccessRuleSet { suggests that JDT is trying to resolve the JRE container before the PDE container, even though PDE container comes before it in the .classpath file.
No the builder trace shows classpaths that have already been resolved. If you want more information on how they were resolved, you should enable the org.eclipse.jdt.core/debug/cpresolution option.
I tried enabling the cpresolution option, but it produced too much output and I didn't know how to parse it. It quickly filled my 10,000 line console buffer but I don't know where the useful information is. I'll attach a file with some sample output.
Created attachment 21120 [details] Output of cpresolution tracing Here is some output with cpresolution tracing enabled. I saved this trace shortly after it starting doing builds.
John is it the start of the output ? We really need the first traces. Otherwise from the trace it looks like the PDE container is not returning the same classpath entries as on shutdown.
>Otherwise from the trace it looks like the PDE container is not returning the >same classpath entries as on shutdown. could you copy and paste the segment of the log that shows this? thanks.
The following stack trace (extract from John's log) indicates that code at line 3845 of JavaCore.java is running. Howver there is an optimization at line 3775 that forces a return from the method if the classpath entries of the container are the same as the one that were saved. ... at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:3845) at org.eclipse.pde.internal.core.ModelEntry.updateClasspathContainer(ModelEntry.java:110) at org.eclipse.pde.internal.core.RequiredPluginsInitializer.initialize(RequiredPluginsInitializer.java:40) at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1421) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:976) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1320) ...
Comment #32 indicates that this is also a problem in a workspace without plug-in projects. Is that a separate problem or are we going down the wrong path here looking at PDE classpath containers?
Then we should ask Ringo to enter a separate bug report against JDT Core with steps to reproduce. But comment 92 clearly indicates that there is a problem with the PDE container.
>Howver there is an optimization at line 3775 >that forces a return from the method if the classpath entries of the container >are the same as the one that were saved. that's exactly my point. We should not rule out that the method determining if the classpath has changed might have a bug in it, or that there is a bug in persisting the classpath (e.g. order of entries, order of attributes in an entry). These are all rational theories that we should investigate.
Wassim - given you had an issue with concurrency in PDE container until yesterday... don't you think there are still enough potential for the PDE container to be the source of this ? Though I agree, you may simply be exposing an issue in JDT/Core, however this feels less likely.
Created attachment 21126 [details] Another trace output from the very beginning Here is another output with information starting at the very beginning. However, the full build doesn't start for at least 5 seconds after startup finishes. The problem is I can only capture 9999 lines of debug output on Win2k. If anyone knows how I can capture stdout to a file that would help. I've tried the usual >> 1> 2>, etc, but it is not working.
re comment 96 I'm not suggesting that this is certainly not a PDE bug. It may well be pending the investigation. But with group think, it seems that minds are already made up without tangible evidence that it is a PDE bug. All I'm saying that it is prudent to consider and investigate all possibilities on all sides.
Personally, I blame our decision to release on Friday the 13th :)
re: comment#98 Ok we are on the same track there. As usual, PDE is a challenging client for us <g>
Created attachment 21160 [details] Classpaths cached by jdt.core Attached is the classpaths that jdt.core saved after I opened Eclipse on a workspace containing all the sdk plugins and closed it after 2-3 seconds. You will see that all the containers (both pde and jre) are empty, with the exception of that of org.apache.ant (the first project in my workspace). With this kind of cached classpath, the next time you launch Eclipse on this same workspace that has not changed, you get the inexplicable full build. This also explains comment 32 where the gentleman was not a plugin developer, and a false rebuild was reoccurring. The jre container is also empty for all these projects. So if Eclipse is being shut down, and JDT had not resolved classpaths yet, empty values are being written and causing full rebuilds on the next invocation. This would also explain such entries in John's stack: Classpath jar file D:/vm/sidecar/jre/lib/ext/dumpfmt.jar != Binary classpath directory /org.eclipse.core.runtime/bin with AccessRuleSet { For this plugin, it appears as though jdt had resolved the jre container for that project upon shutdown, but not the pde container. So upon restart, the jre entry is being compared with the newly recomputed pde entry.
Moving to jdt/core to address the empty cache.
Note: With the introduction of jre profiles by the runtime and access rules, there is an independent scenario in which pde returns a falsely different classpath to jdt. This issue, which appeared only in the past week or so, is being tracked in bug 95278. A temporary solution for the classpath discrepancy has now been released into head for bug 95278. The bug is still open for other open questions.
Re: comment#101. These are not empty container values, but simply markers to retain the fact the container had no value yet. Thus it will be ignored when recreated. So it is not changing the classpath, simply not caching anything there. Jerome - why wouldn't we leave old persisted value in this case ?
We store a CP_ENTRY_IGNORE when the container has not been yet initialized. Note this would never happen in M6 as all containers were initialized on startup.
it is incomprehensible to me why the defect was moved back to PDE.
if you open an close the workbench very quickly, any good jdt classpath cache that may have existed is replaced by a bogus/incomplete one like the one attached in comment 101. Upon a subsequent startup, the bogus cache results in full builds. If the workbench is being closed before JRE/PDE containers have been initialized, don't just flush them, just resave the old classpaths from the previous session.
(In reply to comment #106) > it is incomprehensible to me why the defect was moved back to PDE. Sorry about that. It looks like when I refreshed and added comment 105, it didn't refresh the product and component fields.
Changed JavaModelManager#saving(...) to use the previous session container value if the container has not been initiliazed yet. Also don't persist CP_ENTRY_IGNORE value any longer. For the record, at the time this bug was opened (build I200409070800), this could not have been a problem with JDT Core since all containers were initialized on startup. So the problem was elsewhere (comment 96 may give some answer). However nothing indicates that this was acknowledged.
> For the record, at the time this bug was opened (build I200409070800), this > could not have been a problem with JDT Core since all containers were > initialized on startup. It's possible there were at least two bugs being tracked by this PR. For several months it was very hard to reproduce a full build on startup, and it seemed to be only me that was getting it. Starting with the M7 test candidates, it began happening on almost every session, and several people were reporting it. It's likely that recent optimizations involving deferral of classpath initialization have made old problems more likely to occur. In any case, if this happens again once I have a build with Jerome's fix, I'll enter a new bug report to avoid confusion.
Indeed, this bug remained open too long, and captures similar symptoms but on different scenarii. Thanks Wassim for isolating the last issue, which indeed was in JDT/Core.
Could not reproduce in I20050526-2000. Marked as verified in I20050526-2000.
