Bugzilla – Full Text Bug Listing
| Summary: | org.eclipse.core.runtime should re-export latest version of dependencies | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> |
| Component: | Runtime | Assignee: | platform-runtime-inbox <platform-runtime-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | daniel_megert, jeffmcaffer, john.arthorne, tjwatson |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Markus Keller
I naturally am going to resist this because I think re-export is quite evil. ;-) I think if you have a specific requirement on new API in some org.osgi packages then you should use Import-Package to import the version you need. Depending on the org.eclipse.core.runtime bundle to do this is not a good idea in my opinion. Including John and Jeff on the conversation. I don't think the versioning guidelines give guidance for cases like this. >I naturally am going to resist this because I think re-export is quite evil.
>;-)
Right, but we have several cases in the SDK and normally this happened when restructuring stuff and usually when that was done in the past, there was no recommendation to clients to actually replace the required list accordingly. From that standpoint they could still assume that if they require the latest org.eclipse.core.runtime they really get the latest of all as they did before the split. If we say that's not the case then the migration guide should advice clients accordingly.
(In reply to comment #2) > From that standpoint they could still assume that if they require the latest > org.eclipse.core.runtime they really get the latest of all as they did before > the split. If we say that's not the case then the migration guide should advice > clients accordingly. If I understand this correctly this will require the version of org.eclipse.core.runtime to increase to 3.7 as a result of requiring (and re-exporting) org.eclipse.osgi with a new range of [3.7, 4.0). If we are going to do that then we should evaluate all the other bundle-version ranges that core.runtime re-exports to be the latest versions available. Otherwise downstream bundles may inadvertently depend on some newer API from one of the re-exported bundles. Also if any other bundle re-exports core.runtime they should also tighten their range requirements on core.runtime, which must result in them increasing their minor version. Do we need a migration guide entry that spells this out? All bundles that have a minor version increase (added API) that are re-exported must result in all the bundles doing the re-export to have a minor version increase. I don't think org.eclipse.osgi and org.eclipse.core.runtime are a special case, any other bundle doing a re-export needs to increase their minor version if what they re-export has had a minor version increase. I wouldn't expect a migration guide entry for clients of org.eclipse.core.runtime. When a bundle updates its requirements, it just needs to play the version rules as outlined here: http://wiki.eclipse.org/Version_Numbering#How_to_specify_versions_when_plug-ins_re-export_other_plug-ins I agree with Dani that a bundle with re-exports should either keep the exported versions current, or it should add a migration guide entry that advises clients to add their own dependencies on the re-exported bundles. In that case, the re-exports would be considered deprecated (I don't know if we have tooling to mark this). Naturally, I would favor the former solution, because the re-exports are convenient ;-) org.eclipse.core.runtime really should be deprecated IMHO. There are a few things in there that are useful but for the most part people should not be depending on runtime nor should they be using it as a crutch to get all the other bits they need. >org.eclipse.core.runtime really should be deprecated IMHO.
Agree. But as long as we ship it as it is now, the user should get what he expects i.e. we should updated the versions unless of course someone steps up to split off the rest of the useful parts and deprecate org.eclipse.core.runtime.
This bug isn't really about whether core.runtime should be deprecated or whether re-exporting is good or evil. org.eclipse.core.runtime has always re-exported org.eclipse.osgi and I don't think we can change that. I don't think we should be automatically updating the lower bound on our version ranges to be the latest version with no reason. The clause in core.runtime today currently says "I re-export some version of org.eclipse.osgi in the range between 3.5 and 4.0". This is still true today since 3.7 is within that range, so no change is required. If another plugin has a more specific dependency and that range is not appropriate for them, then it is best for them to add the dependency to org.eclipse.org themselves. Of course, it's hard to be sure that org.eclipse.core.runtime will actually work with org.eclipse.osgi version 3.5. There's a good chance we have started using some new API and we need to update our range anyway. If we do update that range, then the minor segment of the org.eclipse.core.runtime bundle should be incremented as well. (In reply to comment #7) > This bug isn't really about whether core.runtime should be deprecated or > whether re-exporting is good or evil. org.eclipse.core.runtime has always > re-exported org.eclipse.osgi and I don't think we can change that. > My point was not about changing core.runtime to stop re-exporting org.eclipse.osgi that is a breaking change that we cannot do without great disruption. > I don't think we should be automatically updating the lower bound on our > version ranges to be the latest version with no reason. The clause in > core.runtime today currently says "I re-export some version of org.eclipse.osgi > in the range between 3.5 and 4.0". This is still true today since 3.7 is within > that range, so no change is required. If another plugin has a more specific > dependency and that range is not appropriate for them, then it is best for them > to add the dependency to org.eclipse.org themselves. I agree with this and that is the point I was trying to make in comment 1. Declare your own dependencies. Depending on some other bundle to provide them transitively for you (through re-export) is not a good idea. > > Of course, it's hard to be sure that org.eclipse.core.runtime will actually > work with org.eclipse.osgi version 3.5. There's a good chance we have started > using some new API and we need to update our range anyway. If we do update that > range, then the minor segment of the org.eclipse.core.runtime bundle should be > incremented as well. True, it would be interesting if API tooling could provide this kind of analysis for you. Similar to how it detects that you are using methods/classes that are not available in your lowest specified BREE. > True, it would be interesting if API tooling could provide this kind of > analysis for you. Similar to how it detects that you are using methods/classes > that are not available in your lowest specified BREE. See bug 213020. Not planning to automatically increment lower bounds on dependencies. |