Bugzilla – Full Text Bug Listing
| Summary: | Provide a way to version native libraries | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Pawel Pogorzelski <pawel.pogorzelski1> |
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | john.arthorne, mober.at+eclipse, Szymon.Brandys |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
Pawel Pogorzelski
Let's try to address it during 3.6. I'm not sure if I understand this... shouldn't the native lib be versioned through the version of the Fragment it lives in? I see an issue with the current versioning. Consider the following example. You have two unix fragments in Eclipse 3.6: core.filesystem.linux.x86 and core.filesytem.aix.ppc. core.filesystem.linux.x86 version is 1.2.0 and we made some significant changes during 3.6 so its version will be incremented to 1.3.0 core.filesytem.aix.ppc is a brand new fragment, so its version will be 1.0.0, however it works exactly the same as the linux.x86 fragment. One could think that there are changes in behavior between aix and linux fragments, what is not true. This is a general problem of the way we manage versions at Eclipse, isn't it? - As of today, any plugin or feature version only conveys meaning when compared to another version. There is no such thing as an "absolute meaning" of a version.
In your concrete case,
(a) I'm not sure what keeps you from naming the initial version of the PPC
fragment 1.3.0 if it provides exactly the same semantics as other
1.3.0 fragments; and,
(b) Who cares? - The PPC fragment provides some functionality, and in fact
there is a native method call (#nativeAttributes()) to query at runtime
what functionality is provided. You could also consider the
#nativeAttributes() call as returning the API level of the implementation.
The absolute version number is totally irrelevant, except for comparing
against other versions of the same fragment (i.e. what is newer).
Either I really don't understand what's the problem, or this bug is talking about a non-issue, or the bug is really carving on the surface of a much larger problem that goes beyond native libs but affects plugins in general.
PS I should mention that in Orbit, there has been some discussion about the meaning of an "API Version" versus an "Implementation Version", how to keep those two apart and how to version them separately. I don't recall what the outcome of this discussion was, but in some sense it seems similar to what you mention ... in that the "API Version" of the native libs for ppc and x86 are the same although the "implementation version" is different. (In reply to comment #4) > In your concrete case, > (a) I'm not sure what keeps you from naming the initial version of the PPC > fragment 1.3.0 This would solve this particular case, however I don't like starting new plug-ins or fragments from 1.3.0. There are existing fragments though and their versions can't be just set to the same value because they provide the same API and behavior. > (b) Who cares? - The PPC fragment provides some functionality, and in fact I care :-) > there is a native method call (#nativeAttributes()) to query at runtime > what functionality is provided. You could also consider the > #nativeAttributes() call as returning the API level of the > implementation. Right. However it returns only supported attributes. It will not tell us whether a lib respects umask or not. We could add an attribute for umask support, of course. > Either I really don't understand what's the problem, or this bug is talking > about a non-issue, or the bug is really carving on the surface of a much larger > problem that goes beyond native libs but affects plugins in general. I don't know. I'm not trying to solve any general problem. Some of us just see a problem with filesystem fragments, especially now when the number of those fragments is growing. I just want to know what a native lib provides without running it, but just looking at some version. I thought that maybe make files can incorporate appropriate version to the lib name. I'm not suggesting any solution right now, we just raised this bug to have a place for this discussion. Ok. In my understanding, this is not a question of "version" but more a question of "capabilities". One of the natives may not provide a particular capability (such as umask), because it is simply not supported on that Platform (such as Windows). The nativeAttributes() method is a first poor man's approach to querying the capabilities of a particular native. If that is not sufficient, then it may be in order to add more methods. If you want to know the capabilities of a specific fragment without running / introspecting it, then adding a simple README to the bundle seems the easiest solution. Note that for some of the native fragments which I had built, I have checked in a README along with the fragment that holds information how I built that particular lib. Since the compiler version and OS version on which it was built may be very relevant. If you build SPARC-solaris with GCC for instance and don't care having a gcc that was configured with -no-static you end up with a lib that won't run on most systems. Similarly, if you compile on RHEL5 the lib likely won't run on RHEL3 any more. In addition to such a README with capabilities / build info, you may want to expose the API-version of the native libs. IMO the only interesting bit about API-version is whether it supports the nativeAttributes() call or not. Many Apache OSGi bundles (e.g. commons net) add a bundle-manifest header like this: Bundle-Version: 2.0.0.v200905272248 Specification-Version: 2.0 That way, you could have a fragment's implementation version be 1.0 (since it's the first time the PPC fragment is released), but have it conform to the API specification 1.3 (since it supports the umask and nativeAttributes). In my personal opinion, having the fragment start at 1.3 version if it implements the 1.3 API spec is easier to understand, but well, you have the option. No plans to do it for 3.6. 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. 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. |