Community
Participate
Working Groups
We left this too long in 3.7 (bug 348077) so we should look at this at the start of the year. In the plug-in project creation and create from existing archives wizards there is an option to select a target platform version. At a minimum we need to add 3.8 to the list. We should also consider what versions should still be supported. There is no difference between 3.8, 3.7, 3.6 and 3.5. There are constants in ICoreConstants and IBundleProjectDescription that should be updated or removed.
In the future I think you should only change this if there is actually a schema change. The wizard could present ranges rather than a single version: 3.0 3.1-3.3 3.4 or greater Currently you are giving the user a false sense that their plugin is tied to a single target version, when in fact it isn't.
(In reply to comment #1) > In the future I think you should only change this if there is actually a schema > change. The wizard could present ranges rather than a single version: > > 3.0 > 3.1-3.3 > 3.4 or greater > > Currently you are giving the user a false sense that their plugin is tied to a > single target version, when in fact it isn't. Agreed. I think using the ranges will give us a much cleaner look without requiring major changes to the project creation / target version code. We can also reopen discussions about what versions we want to support. (3.0 plug-ins were removed already, we probably don't need to go back so many versions). Chris opened a bug for this a while back but I am unable to find it. This problem is further complicated in that the target version does not persist beyond project creation (bug 214465). If you create a 3.3 project but then work with a 3.6 target platform, your file will be written out in the >=3.4 format.
Here is a list of differences between the versions I found in the PDE code 3.0 No OSGi, still supported by many PDE functions, new templates 3.1 OSGi added, singleton/autostart options, different library paths, jar format options on export, intro page support, launching changes, new templates 3.2 Lazy start attribute, new launcher version 3.2a, period usage in schema ids, new templates 3.3 Splash template support, Bundle activation policy, macosx/info.plist change, launching bundle now named equinox, new templates 3.4 Schemas use AppInfo instead of appInfo 3.5 Product editor supports configuration section, new templates
The templates we provide depend on the target version selected in the new project wizard. Most of the other differences do not depend on the new project setting, rather they are affected by the version of core runtime in the target. Combining the targets into groups seems less practical. I don't know where we stand on backwards compatibility in PDE. Supporting development all the way back to 3.1 and supporting launching/building against 3.0 plug-ins seems excessive.
It looks like 3.3 was the last change that affected manifest format (bundle activation policy). My suggestion is to drop support for anything older than that, and therefore do away with the plugin.xml version number entirely. I suppose a bundle with no plugin.xml is already in that position of not having a version number available. This way you would just have the radio button with no drop down for Eclipse version (just Eclipse vs pure OSGi framework). I vaguely remember in the distant past that "n-2" was the compatibility goal for PDE - you should be able to use Eclipse N to develop plugins for N-2, but no earlier. I think we got away from that because the incremental cost of maintaining compatibility wasn't that high. But once you add up this cost over 8-9 years it becomes difficult to maintain, verify, and test.
My personal opinion as a user of PDE is that "n-2" would be sufficient. In my experience development organizations stay with the version of Eclipse they develop for. I have rarely seen an later Eclipse version used to develop for an older version.
Though n-2 is good enough, however, perception is stronger than reality. I would like to show version ranges instead, so that it doesn't look that we will be breaking the support for old plug-ins (are we?). Also, we do not know what products out there might be using it in what ways.
(In reply to comment #7) I agree with this, i.e. I'm fine with N-2 in general if this is required and saves lots of work now or in the future. Applying the rule now and breaking existing stuff without a strong need is discouraged.
(In reply to comment #7) > Though n-2 is good enough, however, perception is stronger than reality. I > would like to show version ranges instead, so that it doesn't look that we will > be breaking the support for old plug-ins (are we?). Also, we do not know what > products out there might be using it in what ways. FYI we had a discussion on this subject in our PMC call this week (July 27): http://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes We agreed dropping support for older versions is ok if there is a benefit to doing it. Personally I think there is a benefit here to making the story less confusing for plugin developers (they would no longer have to pick a version during plugin project creation that becomes semi-meaningless later on). Importantly, no matter what we do, we need to handle existing plugins that still have older version numbers in plugin.xml. I looked at various platform plugins and many of them today still have "Eclipse 3.0" as the version number. To me this argues the number is essentially meaningless since there has been no reason to upgrade these numbers (org.eclipse.core.runtime, org.eclise.ui, and org.eclipse.jdt.ui, for example, all say "3.0"). I recommend a compiler warning and a quick fix to remove or update that processing instruction.
Since PDE committer time is so limited, here is my proposal for 3.8: 1) PDE still stores a list of constants for each release version (matching up with the version of org.eclipse.osgi in the target). This is necessary because PDE does have different processing of some files between releases (i.e. target files). I will improve the javadoc to explain their use. 2) Introduce a new constant for 'latest eclipse version' that would move to point to the highest version used in PDE. This reduces the number of places that have to update each time we add a new version. 3) Create a single place where we decide what versions to show when creating projects (currently there are three). 4) Reduce the project creation options to: a) Eclipse b) Legacy Eclipse (versions 3.1 - 3.4) c) OSGi framework Not sure of what wording to use here. If we want to drop support for creating new plug-ins for 3.4 or lower, we can just eliminate the legacy choice altogether. All the code to support existing plug-ins would stay.
My personal opinion is that I think the creation of legacy plug-ins (Option b) could be dropped. If someone would still like to target that he could use an older Eclipse version.
(In reply to comment #11) > My personal opinion is that I think the creation of legacy plug-ins (Option b) > could be dropped. If someone would still like to target that he could use an > older Eclipse version. Forcing someone that has to maintain plug-ins for "legacy" software for a couple of years to an old Eclipse version (potentially with old/buggy JDT and PDE) is harsh (IMHO). I agree with John that at least a simple label change is a big improvement already.
@Gunnar: Good point, thanks.
Proposed fix: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?h=bug348099&id=2008aea419984ede0c800498c1c4a6ceec9fa0b0 Introduced new latest version constant and updated ICoreConstants according to comment #10. The new wizards keep their drop-down, but the first combo choice is "3.5 or greater". Deprecated the 3.6 and 3.7 constants from API class IBundleProjectDescription for which we would need PMC approval. This is not a necessary change, but it provides an explanation why there isn't a 3.8 constant. Dani, John, thoughts?
> Deprecated the 3.6 and 3.7 constants from API class IBundleProjectDescription > for which we would need PMC approval. This is not a necessary change, but it > provides an explanation why there isn't a 3.8 constant. Dani, John, > thoughts? I think that adds more confusion than it helps. So far, a cliebt could simply choose what version to pick/target and did not have to care about what's the latest internally. Given we have to add and handle ICoreConstants.TARGET38 I would simply add IBundleProjectDescription.VERSION_3_8 as well. Rest of the patch looks good with some comments: org.eclipse.pde.internal.core.target.TargetDefinitionPersistenceHelper.persistXML(ITargetDefinition, OutputStream) should probably also be adjusted. The implementation of org.eclipse.pde.internal.core.project.ProjectModifyOperation.getTargetVersion(String) got changed. It now matches the Javadoc, but are you 100% sure that the implementation change doesn't have any side effects? Code in org.eclipse.pde.internal.ui.wizards.plugin.NewProjectCreationPage.createFormatGroup(Composite) looks overly complicated.
(In reply to comment #15) > I think that adds more confusion than it helps. So far, a client could simply > choose what version to pick/target and did not have to care about what's the > latest internally. Given we have to add and handle ICoreConstants.TARGET38 I > would simply add IBundleProjectDescription.VERSION_3_8 as well. I can live with that. Optimally I would want the UI and IBundleProjectDescription to have the same behaviour, but it isn't unreasonable to have more flexibility in the API then the wizard. If we did remove the older versions from the UI, I would still want to keep the old version support in the API. http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?h=bug348099&id=009481933291112ad0e4dd90da787655de8e94ca Still requires PMC approval. >org.eclipse.pde.internal.core.target.TargetDefinitionPersistenceHelper.persistXML(ITargetDefinition, > OutputStream) should probably also be adjusted. We only need to update the target code if a new target file structure is created. If we want the file version to increase with each release, we would need to modify TargetDefinitionPersistenceHelper.initFromXML() to use the 3.8 structure for any higher version. > The implementation of > org.eclipse.pde.internal.core.project.ProjectModifyOperation.getTargetVersion(String) > got changed. It now matches the Javadoc, but are you 100% sure that the > implementation change doesn't have any side effects? This would break someone who is. Having implementation match the API makes sense. It is exceedingly unlikely to cause problems for clients as they would have to be: 1) Building plug-in projects programmatically 2) Ignoring the API javadoc by building against an older eclipse without specifying a target version. 3) Building against Eclipse 3.2 or earlier, as the API doesn't involve the template/schema changes that came later. > Code in > org.eclipse.pde.internal.ui.wizards.plugin.NewProjectCreationPage.createFormatGroup(Composite) > looks overly complicated. The logic is a bit excessive, but is there to reduce the odds of the user having the change the setting. It checks dialog settings first, then the target version, then defaults to the newest. This is made a bit more complex because of the use of a range.
Fixed in master.
Verified in I20120503-1800
