Bugzilla – Full Text Bug Listing
| Summary: | [publisher] Source bundles should have a capability telling which bundles they are the source of | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | darin.eclipse, hmalphettes, igor, irbull, jeffmcaffer, john.arthorne, marcus.kestler, pquiring, t-oberlies |
| Version: | 3.4 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 345234 | ||
|
Description
Pascal Rapicault
Jeff, any interest in this? Yes this is interesting but don't think it is going to get in for 3.4 Is there an easy way, given a bundle, to determine the ID of the bundle for which it is source of? For eclipse bundles we can remove the .source_, but I don't think this works in general. I agree that there is no rule that we can come up with. Instead we should try to integrate this as part of PDE build when the source bundles are generated. Isn't the bundle the source if for listed in the manifest? Seems like it just needs to be pulled in to a property. The manifest contains a header to identify source bundles. The header defines the bundle it is associated with (name/version), and where the source is located in the source archive: Eclipse-SourceBundle: org.eclipse.debug.core;version="3.5.0.v20090526- 1600";roots:="." So this should just be a matter of generating the appropriate p2 metadata from this header in the publisher (a provided capability). This will let us do cool things like install source on demand when debugging. (In reply to comment #7) > So this should just be a matter of generating the appropriate p2 metadata from > this header in the publisher (a provided capability). This will let us do cool > things like install source on demand when debugging. > Is it a provided capability or a property? Is there a good rule of thumb here? > Is it a provided capability or a property? Is there a good rule of thumb here?
It should be a provided capability. Any metadata that might be used by the resolver/planner should be a capability. This will allow us to express provisioning requests like, "Install the source for bundle org.eclipse.foo version 4.2.0", and the resolver will be able to track it down. Properties are just single values that aren't as rich - useful for queries over the metadata outside of install time.
It's worth mentioning we already have a capability that allows us to determine that an IU is a source bundle:
<provided namespace='org.eclipse.equinox.p2.eclipse.type' name='source' version='1.0.0'/>
What we're talking about here is a capability like this:
<provided namespace='osgi.bundle.source' name='org.eclipse.foo' version='4.2.0'/>
I can see three ways of expressing the information. [1] <provided namespace='osgi.bundle.source' name='org.eclipse.equinox.p2.core' version='1.1.0.v20090911-1356'/> [2] <provided namespace='org.eclipse.equinox.p2.iu.source' name='org.eclipse.equinox.p2.core' version='1.1.0.v20090911-1356'/> [1] Create a very explicit namespace for the source of bundles. This is clear, but limited to bundles. [2] Create a p2 IU namespace for all source things. This allows to identify the source of any IU whatever its kind is. Overall I'm tempted to go for 2 because it offers more flexibility and from the point of the view of someone looking for source avoid him to have to know the type of the element being looked for (e.g. osgi.bundle). However I'm not a big fan of the namespace name. I have a feeling it needs to be more specific (approach 1). Consider the following:
1) I have an OSGi bundle called "com.xyz.mybundle" version "1.0":
<unit id='com.xyz.mybundle' version='4.0.1.v20090822' singleton='false'>
<provides size='1'>
<provided namespace='osgi.bundle' name='com.xyz.mybundle' version='1.0'/>
</provides>
</unit>
2) I have a JavaScript bundle with the same name and version (allowed because the namespace is different):
<unit id='com.xyz.myjsbundle' version='4.0.1.v20090822' singleton='false'>
<provides size='1'>
<provided namespace='javascript.bundle' name='com.xyz.mybundle' version='1.0'/>
</provides>
</unit>
3) Now I have source IU that specifies that name/version:
<unit id='com.xyz.mysourcebundle' version='4.0.1.v20090822' singleton='false'>
<provides size='1'>
<provided namespace='org.eclipse.equinox.p2.iu.source' name='com.xyz.mybundle' version='1.0'/>
</provides>
</unit>
This is ambiguous. Is 3) the source for the osgi bundle or the JavaScript bundle? Since binaries have their own distinct namespaces, I think their corresponding source bundles also need distinct namespaces.
I agree that there is potential for ambiguity if you read the "name" attribute of the capability as the name of the capability of the IU that provides the binary bits. However if you read it as the name of the IU in the iu namespace then I think it is fine. Now let's look at this from the point of view of someone trying to find the source code for a particular jar or package. I think the prime difficulties are with the identification of the code being run, its version and its type (is it a jar, a bundle, javascript...). If we go the type specific route (suggestion [1]) then the mapping between type and namespace has to be know from the tool (e.g javacode corresponds to java.source, osgi.bundle corresponds to osgi.bundle.source, etc.), and there is the issue of finding the ID of the thing you have the binary for. If we go the source namespace route (suggestion [2]), then the mapping does not need to be known by the tooling but it has to somehow relies on some naming convention of id to IU id (which is a non issue if the starting point is an IU). But it also seems to be more extensible if someone wanted to use p2 as the facility to get the source of anything. So I suppose the question now goes to Darin or other potential users of this facility: How would you use this facility to get the source? You're right, there is no ambiguity if you're expressing "I provide source for the following IU". I'm having trouble putting a finger on it, but it seems odd to do this, since the source is really for a Java bundle and it just happens to be contained in a given IU. If in another system the same bundle was in a different IU then the source mapping wouldn't work. I would think the client such as a debugger would want to answer the question "where is the source for bundle X (or maybe even source for package a.b.c)", and if the source is expressed at the IU level they have to map from bundle->IU->Source IU rather than directly from bundle->source IU. There are a couple of uses cases to consider: (A) Debugging something that I don't have source for. (B) Debugging something that I have attached source for, but I want to get the source into my workspace so I can create a patch for it (bug 243582). For (A), when debugging something (especially in the remote debug case), we'll generally only be able to tell what bundle/version is being debugged. I don't think we'll be able to definitively tell what IU it maps to (unless it happens to be part of a local profile), (or, unelss the OSGi runtime has the IU information?). For this reason, I think that we should follow approach [1] - source for bundle X, version Y. For (B), a source bundle IU should also have a capability detailing how to retrieve the source from a repository (so we can create a project for it in the workspace). My initial feeling is that the information should be provided something like a .psf file (project set format). I don't see this being done for 3.6. Resetting milestone. FYI: I proposed a non-conflicting solution for the related use case "install all available sources" in bug 347483. The use case discussed so here so far is more the installation of individual sources on demand. Neverthless, the "source of" information could also be used to provision all available source bundles, e.g. for a director call. However adding the bundles is not enough: How would we prevent that the source bundles are GC'ed? As far as I understand Jeff (bug 328929#c9), the source bundles would always be removed in a GC run. The reason I am asking is trying to estimate the efforts for this issue compared to bug 347483. Tentatively marking this for Juno. Someone will be needed to help drive this effort. Moving out since nobody is driving this forward. 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. |