Community
Participate
Working Groups
This entry stems from bug 474782, there a fix in API Tooling was not being reflected in results. The reason observed to be that the reports are generated in a "post build" task ... which uses the "base builder" (by design). For bug 474782, we made a "quick fix" by changing the base builder to 4.6 M1. But, by design, we typically want the base builder to be a very stable, constant version of Eclipse. We do, how ever, do things like "install the latest build tools" into that base build. Perhaps we should consider installing the API Tools from "latest repo" (where the "latest repo" could most likely be the same as we use for the "eclipserun-repo"). The advantage then, is that most of "the base builder" does stay constant, and stable, and only "tools" change. The disadvantage is that some changes/fixes for API Tools *might* not be compatible with "previous build" ... such as if it's pre-reqs increased?
One issue is if the API Tools are available in their own feature? If so, that'd be simpler to install into previous version. (But, is not strictly required.)
I could not easily get this to work, since API-tools bundle is a singleton. I have opened bug 475211 to perhaps improve packaging, but might be able to solve the immediate issues at hand, by simply installing the Eclipse platform only, and then installing all the "build-time" tools into that. (But, would think things could be improved, via bug 475221.)
It appears, from my local test builds, that using the binary platform as a base (like we used to), and then installing "build related tools" into it works fine. Besides the tools we were using, I added the "eclipserun-repo" repository (which is currently M1) and explicitly coded to install IU org.eclipse.pde.api.tools/1.0.800.v20150722-0934 That seemed to pull in quite a bit above the "binary platform" but from a quick glance didn't appear to replace anything (with something more current). Ended up with 210 bundle in "platform + tools" installation. The Binary platform alone normally has about 190 bundles. Roughly 6 to 10 of those 20 "extra" bundles are the actual tools requested to be installed .. the rest come from the "require bundle" list of the installed plugins. While not without its potential pitfalls, in the future, I think this the better solution, than moving entirely up to have the "base stable build" be Neon M1, since that could pose some (small) risk of breaking or changing the build in hard to find ways). Though, ideally all the "post build" stuff would move into some maven task/step, somewhere, even if used "ant-run" for it, as we do other build task, such as producing the descriptors, documentation, etc.
Just to cross reference, I opened Bug 475224 - Use pom properties in post-build tasks to track further simplifications and improvements as to how these post build tasks can be handled and coordinated with the main build.
