Community
Participate
Working Groups
Build Identifier: 20100218-1602 In the feature.xml editor, on top of Dependencies tab there is one check box labeled: Recompute when feature plug-ins change You can tick it, but if you close an reopen feature.xml it's not ticked any more. Reproducible: Always Steps to Reproduce: 1. Open feature.xml 2. Click Dependencies tab 3. Tick "Recompute when feature plug-ins change" 4. Save and close feature.xml 5. Reopen feature.xml and go to Dependencies tab, the check is off
Seeing the same issue. Please fix this.
I'm seeing this issue with Eclipse 3.6 and 3.7RC4.
The feature editor is not a priority item for us. Please consider contributing a patch.
(In reply to comment #3) > The feature editor is not a priority item for us. Please consider contributing > a patch. I don't understand. What is the preferred way of managing a feature? How can this not be a priority? However, I will look into the source and see what I can do.
The Problem is still there in 4.3.1.v20130911. Eclipse e4 Tools (Incubation) 0.14.0.v20140112-2002 org.eclipse.e4.core.tools.feature.feature.group Eclipse.org Please write here, how the feature.xml should be edited in a Text-Editor to enable "Recompute when feature plug-ins change" feature. You could either write here where the sources for this feature are located, so that someone (maybe it will be me) can contribute a patch.
The checkbox is handled in org.eclipse.pde.internal.ui.editor.feature.RequiresSection See fSyncButton. It's value is not stored anywhere. The recompute will only happen if the editor is open so storing the value in the feature metadata isn't correct. This would be better stored as a global preference, so when opening any feature editor the button may already be checked.
Created attachment 247061 [details] Feature.xml saves the previous state of the Recompute check box. Recompute check box value is saved in the IPreferenceServices and now the check box remains checked on reopening the feature.xml
Hi Pragya, 1) Can you please sign the CLA agreement? 2) Can you please give the patch with respect to latest code? I had a quick look. With this patch, if I check fSyncButton in feature project 1, the next time I open feature project2, even that project has this button checked. Is this intended? When working with multiple feature projects, this may be confusing. I am not sure this is the right behavior. May be the preference should be specific to the feature project.
Hi Vikas, I have signed CLA agreement. It was intended that if fSyncButton in one feature project is checked the same will be for all projects. But as suggested by you, I have made the changes so that the preference is specific to the feature project and therefore attaching the new patch.
Created attachment 247661 [details] feature.xml saves the previous state of the recompute check box specific to the feature project.
This looks good . However I have this concern when I re-looked at this. When the checkbox is checked, the editor should be dirty. That would probably mean adding an attribute to <requires> <import plugin="a.b.plugin"/> </requires> With the current fix, even storing as project specific preference means that once the feature project is exported and then imported, you would in all likelihood lose the extra information. ( of Recompute check-box being checked). What are your views?
>then imported imported at different workspace location.
yeah if imported at different location, feature project will lose the extra information. I will make the necessary changes and update the patch.
What is the new approach you are planning to take? Are you also planning on dirtying the editor and storing the information in feature.xml?
yes...but if there is some other better way please let me know..
(In reply to Vikas Chandra from comment #14) > What is the new approach you are planning to take? Are you also planning on > dirtying the editor and storing the information in feature.xml? I do not recommend this. The feature.xml is intended to store information relevant to building and delivering the feature, not the UI settings. Either the setting should be for the whole workspace or it should be for the project (as most of the time there is only one feature.xml per project). Yes, if the file is opened elsewhere, the checkbox will be turned off. The user can then check it in the new project. The deluxe solution would be to add a property page to feature projects, similar to the 'Plug-in Development' page on bundle projects. The user could have an option 'Always recompute '. That setting would be stored in the .settings folder of the project, so when it is in SCM, others would get the setting for free. The option in the feature editor would be associated with that preference. Note that you can open a feature.xml outside of a project (File > Open) so we should check that we handle that case.
With regards to Curtis' suggestion Either the setting should be for the whole workspace or it should be for the project (as most of the time there is only one feature.xml per project). Yes, if the file is opened elsewhere, the checkbox will be turned off. The user can then check it in the new project. In the second patch submitted by me, the setting is specific for the feature project but if the file is opened elsewhere, the checkbox will be turned off. However the user can then check it in the new project. Kindly review the patch so that the current issue can be resolved and as for the deluxe implementation we can take it up as a seperate task by logging an issue for the same.
If it is either this or the current bug, I will prefer patch 2 ( with license information and consistent code pattern for preference putting and retrieving - please see any other example in any pde plugins). Curtis, your views?
(In reply to Vikas Chandra from comment #18) > If it is either this or the current bug, I will prefer patch 2 ( with > license information and consistent code pattern for preference putting and > retrieving - please see any other example in any pde plugins). > > Curtis, your views? I think my opinions are already stated. I'm ok with the preference being per feature project. Yes the fix should use the same code pattern for setting preferences as elsewhere. Please check whether the preference is stored in the project .settings folder, allowing it to be stored in SCM.
Hi pragya, 1) license year information, if any 2) preference putting and retrieving using code pattern already there, search for putBoolean( if case of doubt.) After that we are good to go.
Can you please ellaborate abot license year information as I am not aware of it and regarding code pattern i have made changes, please check the new patch submitted and confirm if this is as per requirement.
Created attachment 247956 [details] Code pattern changed
Fixed via Pragya's patch http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=bb93a65f77f30a13ff6f0eed89c79bcc6af8e66e license year issue is changing Copyright (c) 2000, 2013 to Copyright (c) 2000, 2014 of the file modified. Between the options available, this solution is better than the current situation of feature editor. Pragya, can you please open a defect based on Curtis's implementation ( para 3 comment#16) suggestion for this issue? I think that is the ideal solution and we should be tracking it via a bug.
(In reply to Vikas Chandra from comment #23) > Fixed via Pragya's patch > > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/ > ?id=bb93a65f77f30a13ff6f0eed89c79bcc6af8e66e > > > license year issue is changing > Copyright (c) 2000, 2013 > to > Copyright (c) 2000, 2014 > > of the file modified. > > Between the options available, this solution is better than the current > situation of feature editor. > > Pragya, can you please open a defect based on Curtis's implementation ( para > 3 comment#16) suggestion for this issue? I think that is the ideal solution > and we should be tracking it via a bug. Hi Vikas, I have opened the bug for the Curtis's implementation suggestion.
Verified in Version: Mars (4.5) Build id: N20141026-1500
