Community
Participate
Working Groups
Dynamic dependencies are a way for language tooling to inform the builder about the order in which projects need to be compiled. However, the current approach (data which must be explicitly attached to the project via setters while holding a workspace lock) is prone to deadlocks. See bug 495062 and bug 241751. There is also a design flaw in the current API. Since each language sets this data as a single attribute on the project, projects that support multiple languages will have this attribute overwritten by the tooling for each language. We should replace this system with something that is purely functional. That is, the build system will invoke a function provided by the language tooling to determine the build dependencies rather than having the language tooling attach the dynamic dependencies to the project as metadata.
New Gerrit change created: https://git.eclipse.org/r/85332
New Gerrit change created: https://git.eclipse.org/r/85333
Jay + Sergey, could I trouble you for a code review? Since the change to resources introduces new API, I'd like the perspective of at least one other JDT committer and a reviewer who works on some non-Java tooling. What this new API does: - Permit callers to obtain the java class path and traverse the java model without obtaining the workspace lock. (Necessary for breaking a deadlock in the new indexer) - Allows multiple builders to run on the same project without overwriting one another's dynamic dependencies. - Allows dynamic dependencies to be keyed based on configuration rather than just per-project. My main concerns: - Since I'm reworking how dynamic dependencies work anyway, are there other use-cases I should have taken into account? - My new API is based mainly on IProject. Should I have been using something else ? If I used something like IBuildConfiguration, would it have let people do anything that they can't do with IProject? - How do we like the naming of the API methods/interface? - How do we feel about the way I modified the builders extension point? Is the new configuration element in the right spot? - How do we feel about the way I notify the IProject of changes in the dynamic dependencies (by having the laguage tooling explicitly invoke a clear* method on IProject). Feedback on any of the above would be appreciated.
Gerrit change https://git.eclipse.org/r/85333 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=6fc45bc9c9ccf8c3d1db3213bb423d6e912182df
Please add a N&N section about the new API.
New Gerrit change created: https://git.eclipse.org/r/87504
There are a bunch of tests that call and/or test #setDynamicReferences. They should be changed to use the new API or new tests have to be added for the new API.
Gerrit change https://git.eclipse.org/r/87504 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=5ae9859c90fca4babe9e01de719c7ccaf6a25a0a
Gerrit change https://git.eclipse.org/r/85332 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=f7ed9839ef5f6bfc6dd1db3bdc1a458b7b45c64b
> There are a bunch of tests that call and/or test #setDynamicReferences. > They should be changed to use the new API or new tests have to be added > for the new API. I'll add tests for the new API. As long as the older deprecated API still exists, I'd like to keep the old tests around in their current form.
(In reply to Stefan Xenos from comment #10) > > There are a bunch of tests that call and/or test #setDynamicReferences. > > They should be changed to use the new API or new tests have to be added > > for the new API. > > I'll add tests for the new API. As long as the older deprecated API still > exists, I'd like to keep the old tests around in their current form. k.
New Gerrit change created: https://git.eclipse.org/r/88139
Gerrit change https://git.eclipse.org/r/88139 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=f5b407a29ba53b42d24e0340693b4fbf46835a93
Since this change some tests in Object Teams are failing. These tests create several PDE projects and then invoke a full build. During this build lots of names are not resolvable, because the build order has not been properly computed. From what I saw so far, computing the correct build order depends on this deleted line from ChangeClasspathOperation.classpathChanged(): new ProjectReferenceChange(project, change.oldResolvedClasspath).updateProjectReferencesIfNecessary(); As a result I observe the relevant ProjectDescription having no references in #dynamicRefs nor #dynamicConfigRefs. Unless you can explain that the test needing this line must be bogus, I hold that this change is not good.
I found some more: the build order was broken only for the OT builder, not for the JavaBuilder. Adding one line to the extension definition of the builder fixes the immediate issue: <dynamicReference class="org.eclipse.jdt.internal.core.DynamicProjectReferences"/> I still have some regressions in the same tests, not sure if causally related. Strictly speaking, I was working at my own risk, because JavaBuilder is internal, and reusing this for a new builder is of course not supported. OTOH, I could imagine that other Java-like languages would use a similar approach (for me it was working very smoothly for over a decade :) ). So an announcement of this change should definitely alert of the necessity to augment the extension definition. I'll report back when I have analyzed the remaining regressions.
I could track down the other regressions as glitches in the Object Teams tests. => re-closing. Still the new extension point should be widely announced, IMHO.
Verified for Eclipse Oxygen 4.7 M5 with Build id: I20170123-0830
