Community
Participate
Working Groups
Hi all, AFAIK, there are no official guidelines specifying which standard features and build artifacts should be in a typical Eclipse project and which artifacts it should publish on the downloads page. It would be great if all projects would follow the same policy here. I am particularly interested in specifying the contents of SDK features. 1. Should SDK features contain documentation? 2. Should they contain examples? Should the examples be contained "as is", or should there be some example installer in order not to pollute New project wizards and such. Should it contain only the most important examples or all of them? 3. Should SDK features contain the UI such as editors, etc? Moreover, some projects would consider having several SDK features, e.g. minimal SDK (no docs, no examples), normal SDK (minimal + docs and examples), SDK with UI (normal SDK + editors, etc). There should be a common policy for this. The next topic is the published project artifacts which is much inspired by Nick Boldt. Starting from Eclipse 3.5, the old approach "extract a zip into the platform folder and hope for the best" is not guaranteed to work. As I understand it, the only recommended way to install a component is using its update site. Still many projects continue publishing various zips containing SDKs, runtime, examples, etc. Is there any reason to proceed publishing them? Perhaps, it is better to announce that, e.g. starting from ?Indigo?, all projects will only support all-in-one update sites? Ideas?
(In reply to comment #0) > The next topic is the published project artifacts which is much inspired by > Nick Boldt. Starting from Eclipse 3.5, the old approach "extract a zip into the > platform folder and hope for the best" is not guaranteed to work. As I > understand it, the only recommended way to install a component is using its > update site. Still many projects continue publishing various zips containing > SDKs, runtime, examples, etc. Is there any reason to proceed publishing them? > Perhaps, it is better to announce that, e.g. starting from ?Indigo?, all > projects will only support all-in-one update sites? I think that there is another audience, as exemplified by the Helios EPP buckybuild, which uses one of the intermediate ZIPs to build a composite product. I think IBM's requirements for relevant ZIPs are similar. In order to make progress, I think we need to identify philosophical goals for each ZIP; then it may be clear what goes where. Runtime-ZIP. Comprises the minimum binary functionality to allow third party applications to use the provided functionality. (No examples, No Documentation, No tools, No releng.) Includes Orbit packages not packaged by the platform. Does not normally redistribute mature (>= 1.0.0) projects. May redistribute incubation projects to provide a predictable release. Runtime-SDK-ZIP Comprises the same as the Runtime-ZIP plus its source so that third party applications can be debugged. Includes the corresponding Orbit source. Core-ZIP Comprises the minimum binary functionality to allow users to use every aspect of the provided functionality. As for the Runtime-ZIP: (No examples, No Documentation, No tools.) Includes Orbit packages not packaged by the platform. Does not normally redistribute mature >= 1.0.0 projects. May redistribute incubation projects to provide a predictable release. Core-SDK-ZIP Comprises the full source so that users have full redevelopment capabilities. Therefore all the source for Core-ZIP. Includes documentation. Includes the corresponding Orbit source. Also includes any releng and tooling to support auto-generation of source. Tests-SDK-ZIP An add-on to the Core-SDK-ZIP to provide the tests. Examples-SDK-ZIP An add-on to the Core-SDK-ZIP to provide the examples. All-SDK-ZIP Optionally: Core+Tests+Examples All-In-One-SDK-Update Site Comprises everything provided by the project. Does not normally include anything provided by another project or Orbit. Composite-Update Site May provide references to all the update sites required to activate the project.
At some point, creating umpteen different build artifacts gets silly. Particularly when installation of those non-p2 "runnable" zips often leads to invalid installations and broken IDEs. Going forward, IMNSHO, the only via artifacts that any project should be building are: * All-In-One-SDK-Update Site * Composite-Update Site * Subset Update Site (with some features/plugins removed from the A-I-O or Composite sites) ... and don't get me started on whether doc plugins should include javadoc ... :)
Most projects just build simple features and bundles. In the Equinox and Eclipse projects, we also have product builds - for example for the Eclipse SDK. We publish this product metadata to the repository so that it is available for installation. You can use the director to install these products. But for a regular user, this wouldn't be an intuitive step. So this is why we still provide the Eclipse SDK and a few others as runnable zips. Once you have a p2 enabled product, you can install all the bundles you want but I don't think removing the base product as a download is an option today.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I suspect that specific ZIPs are now governed by legacy project practices. P2 repos (and their All-in-One ZIP equivalents) make everything else redundant. ? WONTFIX ?
Closed as a WONTFIX.
