Bugzilla – Full Text Bug Listing
| Summary: | Increment version available for plug-in creation | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Curtis Windatt <curtis.windatt.public> | ||||||||||
| Component: | UI | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | ankur_sharma, daniel_megert, john.arthorne, markus.kell.r, Michael_Rennie, tjwatson | ||||||||||
| Version: | 3.7 | Flags: | daniel_megert:
pmc_approved+
curtis.windatt.public: review+ ankur_sharma: review+ daniel_megert: review+ Michael_Rennie: review+ |
||||||||||
| Target Milestone: | 3.7 RC4 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Curtis Windatt
Anyone have strong feelings about this? If we don't change this now I suspect we will need to fix it for 3.7.1. Created attachment 197243 [details]
Fix
I believe this change is worth making for RC4. While there are no differences in the PDE file structure between 3.7 and 3.4, users will definitely question why there is no 3.7 option available. Furthermore, there are target APIs that return the version of the target platform that need to be updated to be accurate. I added an entry to the 3.7 plan for this so that it should be included in the 3.8 plan (and ongoing). I also created bug 348099 to increment at the start of 3.8 and consider eliminating the option altogether (as nothing will have changed for 4 versions). Ankur, Dani, Michael, please review and consider for RC4 inclusion. I would want to include this in RC4. Reviewing the patch. The fix involves adding a new constant for 3.7 (matching the existing version constants). There are two wizards that are updated to have the new entry in their combos. An internal helper class TargetPlatformHelper is updated to return 3.7 as the default target version (it will return whatever the osgi version is from the target if available). This is a low risk fix with no performance impact. PDE has slightly different file structure for different Eclipse versions but the structure hasn't changed since moving from 3.3 to 3.4. Looks good, and it makes sense that you would want to be able to create 3.7 bundles from the new project wizard. Created attachment 197246 [details]
Full fix
Previous patch was missing part of the fix.
Created attachment 197250 [details]
Final patch
Made a small addition in NewProjectCreationPage.createFormatGroup to make the default 3.7 when the target is bad.
I will look at this tomorrow. +1 for Ankur's change. The other wizard page does not have that extra combo initialization. I agree that this is a must fix for 3.7. Otherwise it will be quite confusing for people when they want to create a new Plug-in Project. I've reviewed and tested the fix and it looks good with one exception: the version was made API based on some request. If we decide to add "3.7." then we must also add org.eclipse.pde.core.project.IBundleProjectDescription.VERSION_3_7. ==> you need to 1. ask for API addition on the PMC list - I will approve this 2. announce the bug on the releng list 3. ask for an RC4 rebuild once the bug is in Created attachment 197298 [details]
Patch for PMC approval
+1 for the API addition. (In reply to comment #11) > ==> you need to > 1. ask for API addition on the PMC list - I will approve this done > 2. announce the bug on the releng list done > 3. ask for an RC4 rebuild once the bug is in done If API is required, it implies to me that someone outside of PDE core relies on these values and might need to react to the new constant. Who uses this API and can they adjust in time for this change? For example imagine there is a client with code:
if (version.equals(IBundleProjectDescription.VERSION_3.0)) {
//do something for 3.0
else if (version.equals(IBundleProjectDescription.VERSION_3.1)) {
//do something for 3.1
... etc
They would need to add a new branch to handle the 3.7 version. If the answer is that we don't believe anyone relies on these values then I don't see why we are adding API at this point in the release...
> If API is required, it implies to me that someone outside of PDE core relies on
> these values and might need to react to the new constant.
Not necessarily: org.eclipse.pde.core.project.IBundleProjectDescription.getTargetVersion() (and also the setter) specify that the latest release is targeted if the value is null/unspecified, hence their fallback code should already handle this.
If you think this is not good enough we could map the UI value '3.7' to IBundleProjectDescription.VERSION_3_6 so that nothing changes for clients but the user can choose '3.7' in the UI.
(In reply to comment #15) > If API is required, it implies to me that someone outside of PDE core relies on > these values and might need to react to the new constant. Who uses this API and > can they adjust in time for this change? For example imagine there is a client > with code: The expected users of this API are shipping on 3.6 and will not be shipping on 3.7. This API is intended for project creation, so while the code block you suggested is possible, it is less likely. The constants likely are only used to set the target version of a bundle project description before it is 'made real'. By default the API actually sets the target version to 3.4 because there have been no changes to the file structure since that time (and the project's target version is thrown away after the project is made real). If a client is setting the target version to 3.6 and is unable to use the new constant, there will be no change to the resulting project. Verified in I20110603-0909 |