Community
Participate
Working Groups
There have been multiple proposals of how to enable automatic inclusion sources bundles. However they all have in common that they rely on mechanism currently not available in p2: bug 220254 on a reverse dependency from the source bundle to the binary bundle, and bug 328929 on id matching magic. The drawback of these approaches is that they need dedicated support in each (consumer) tool based on p2. Therefore I would like to propose an alternative solution: binary bundles should have a filtered, optional (but greedy) dependency to their source bundle. Since filters can be easily be enabled from most existing tools, this would cover the use case "include all available sources", which is IMHO a very valid use case e.g. for director calls, mirroring (cf. bug 345512), or when building a p2 repository with Tycho (cf. bug 345234). The proposal would not cover the use case of installing sources of individual bundles or individual projects. However it does not harm these use cases either: the proposal from bug 220254 could still be implemented, and projects are still free to offer source features. I imagine the implementation to be pretty easy: Add a new new advice type in the publisher (e.g. ISourceAdvice), and react on that advice in the BundlesAction. Build tools that build binary and source bundles at the same time, e.g. Tycho, then could easily add this advice and hence enable the "include all available sources" use case.
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.
