Bugzilla – Full Text Bug Listing
| Summary: | [publisher] Option to include sources with all Slicer-based tools | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Tobias Oberlies <t-oberlies> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | hmalphettes, pascal |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 345234 | ||
|
Description
Tobias Oberlies
I looked at this solution and the encoding of the relationship between the binary and the source seems backward to me. It forces the author of a plugin to make the decision on whether it makes the source available right away when he may not want to decide, and it also encodes in the metadata of my binary artifact something that I may not want to reveal to everybody (For example, if I'm a commercial product and want to give my source to select customers, my metadata is still polluted with this information which I may not want to disclose to most individuals). In the end, I do not see the advantage over the solution proposed in bug #220254 since both will require change to the publisher and changes to the other tools, which in the end would likely amount to the same amount of work. I agree with what Pascal says: - the metadata for the sources must be attached to the source artifacts; the runtime bundle must not contain anything related to its sources. - the ability to publish the sources or not is quite crucial: when I worked on bug 345512, I added the ability to filter the artifacts that are mirrored. Based on simple expressions applied on the artifact ID. For example: "-exclude *.source" would exclude the sources of your commercial bundles from being mirrored. (In reply to comment #1) > I looked at this solution and the encoding of the relationship between the > binary and the source seems backward to me. It forces the author of a plugin to > make the decision on whether it makes the source available right away when he > may not want to decide, If sources are not published with the binaries, there is still the option to deliver them later via an additional source feature. > and it also encodes in the metadata of my binary > artifact something that I may not want to reveal to everybody (For example, if > I'm a commercial product and want to give my source to select customers, my > metadata is still polluted with this information which I may not want to > disclose to most individuals). In most cases the names of source bundles will be <binary bundle>.source so the information disclosed is not really private. Pollution of metadata with potentially unneeded information is a valid point, but from my experience, only very few people ever look into the metadata (even if they have developed against p2). Therefore I think we can accept this. > In the end, I do not see the advantage over the solution proposed in bug #220254 > since both will require change to the publisher and changes to the other tools, > which in the end would likely amount to the same amount of work. I agree that we will always need to change the publishers. Other tools don't need to change, as long as they allow setting filters (e.g. -profileProperties for the director). This is (implementation-wise) the advantage over bug 220254: on the consumer side, it only uses existing concepts. I have found a slicer-based tool which will not be able to work with the optional filtered dependency from bundle to source: target definition files (*.target) with includeMode="slicer". These definitions contain all strict version requirements of a set of seed units, and the resolution fails if any of the requirements (regardless of the "optional" flag) is not satisfied. This is intentional, because it guarantees that the target definition is immutable even if the referenced repositories aren’t. Therefore, with the proposed optional filtered dependency, these target definitions could either have all sources (which is unrealistic if it concept should become wide-spread), or no sources (well, then there is no benefit), but getting "all available sources" is not possible under the premise of deterministic resolution results. So for target platforms with includeMode="slicer" it is probably best, if the authors of a feature also offer source or SDK features. But if source/SDK features exist anyway, I neither see a major benefit in optional filtered dependencies from binary to source (proposed here) nor for a "source of" attribute (proposed in bug 220254). 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. If the bug is still relevant, please remove the "stalebug" whiteboard tag. |