Community
Participate
Working Groups
----- Forwarded by John Wiegand/MIN/OTI on 10/24/01 01:57 PM ----- Project dependency bug Step by Step Recreation: 1. Make sure the "Perform build automatically on resource modification" option is selected from Window->Preferences->Workbench 2. Create Project1 3. Create a package "com.wsad.prj1" 4. Create a interface "MyInterface" 5. Create a method foo() on it. 6. Create a Class that implements "MyInterface" 7. Create a Project2.(make sure you add the dependency of Project 1) 8. Create a package "com.wsad.prj2" 9. Create a class "MyClass" 10. Make it implement "MyInterface" 11. Add a method bar() to "MyInterface" [At this moment an errors is being shown in the first project but not on the second project] 1GLEYT1: ITPJCORE:ALL - Dependent Projects not compiled when project is saved Old Abstract: Cust-Serv - Project dependency bug New Abstract: 1GLEYT1: Cust-Serv - Project dependency bug
This is indeed a known issue with our current builder, it isn't able to indict a class file structural change (standard cross project scenario). I remember talking with Nick about this defect, and the only possible way to fix it at that time was to change the following method on IncrementalImageBuilder so as to add the fragment in red below. The consequence is that it turns into a pretty non-efficient mode, since it would convict all dependents of any touched class file (and we do not optimize cases where we regenerate an identical classfile). /** * The given source element has changed and will be compiled. * Flag the node in the dependency graph, and store all compilation * units that will need compiling as a result of the change. */ protected void changedSourceElement(SourceEntry newEntry) { PackageElement element = fNewState.packageElementFromSourceEntry (newEntry); if (element.isSource()) { fWorkQueue.add(element); } else { markDependentsAsNeedingCompile(element); } /* remove problems for this source entry */ SourceEntry oldEntry = fOldState.getSourceEntry(element); fNewState.getProblemReporter().removeProblems(oldEntry); } The problem in trying to do better is a that there is no obvious mechanism in the builder currently, and this problem came late in the 0.9 release effort. There is no principal structure of the previous class file we were holding onto. My best bet would be to use the same approach as our new builder: 1. diff class files upon writing them, so as to bookkeep the list of structurally changed ones 2. only recompile dependents of ones which have structurally changed (the code in red should check if the element path is in the list of modified files). The next problem is that the list of structurally changed class files would need to be recorded in the build state, and persisted in case one is building only one project at a time. I believe this is fixable, but work. Now Kent is probably the best person in term of expertise and available cycles, and I will try to help if I can better.
Looking more at this problem, I do not quite see how to easily perform the structural comparison as we do it in the new builder. The project binary output which is responsible for editing the output folder does not only discard existing class files upon creating new ones. When a source change happens, it will eagerly discard all types (in case the new unit contains less types I presume), and thus at the point it is about to write the new files, the old ones might be long gone. It would be hard to only delete a subset of them, since innerclasses would need to be remembered as well. The alternative would be to record the bytes of the old ones, so as to be able to compare them later with the new ones, but this would be a memory pig.
From Kent: I think Philippe's fix is acceptable in the short term: - BECAUSE it works, - our compiler is fast enough to compile 5-10 files quickly, - I would hope the depth of the project hierarchy is small, - incremental mode should start with one source file change, - the first dependent project would only see the one class file change & compile all dependents, - the next dependent would see more class file changes but its still better than a full build. The new builder story is currently seeing all class file changes as if they had structural changes. It will use build numbers to ignore class file deltas from a prereq project BUT I wasn't going to keep a list of structurally changed files, since that has problems if people manually build projects.
Releasing the naive fix into 2.0 stream for getting some exercising of its performance ramifications.
Keeping open until we experience enough the naive patch.
*** Bug 5267 has been marked as a duplicate of this bug. ***
*** Bug 5532 has been marked as a duplicate of this bug. ***
Fixed & changed summary.
Fixed in 1.0 Rollup 139
