Community
Participate
Working Groups
Currently it seems impossible to associate additional tool-chains to allready existing template definitions. Suppose I have a "Hellow World" template defined for the gnu tool-chain. Now I add one more a new "foo" tool-chain in my "bar" plug-in. How would I associate my "foo" tool-chain with the "Hellow World" template defined in the other (gnu.ui) plug-in without modifying it? An other thing (I'm not sure this is possible now) is to allow specifying that the template is applicable for all tool-chains, e.g. the "hellow world" or an "empty project" template seem to be quite common to be applicable to any tool-chain Mikhail
I guess we might have an additional extension point that would allow specifying the "template_id" <-> "tool-chain_ID" associations. Mikhail
Hi Bala, Is there any chanse we could fix this for the M7? ..targetting to M7 for now.. Mikhail
.. I was thinking if we could have only two possible variants of associations for the 4.0: 1. Teplate is associated _only_ with the tool-chains specified in the template definition 2. Template is can be used with _all_ tool-chains in case the template definition specifies no tool-chain ids. The problems with this approach is that generally no templates could be applicable for _all_ tool-chains, e.g. the "Hellow World" template that generates a HellowWorld.cpp file will not be appplicable for the non-C++ tool-chains, e.g. those not having the C++ compiler. What do others think? Will the above two variants of template<->tool-chain associations be enough for the 4.0? Mikhail
(In reply to comment #3) > 1. Teplate is associated _only_ with the tool-chains specified in the template > definition Yes. > 2. Template is can be used with _all_ tool-chains in case the template > definition specifies no tool-chain ids. I think you're right. A template that can apply to all toolchains doesn't make sense. I would actually only do #1.
A fix for this is included in the patch attached with bug 184449.
Hi Bala, I have a question regarding the addToolChainsToTemplate extension-point defined with your patch: What if I want to associate my tool-chain with the template defined in another plug-in? Ho would I specify the location of that template in this case? Also the extension point schema definition does not seem to be correct. Thanks, Mikhail
(In reply to comment #6) > Also the extension point schema definition does not seem to be correct. I've fixed this, so no need in a new patch.. So the only question left is with specifying the template location.. Mikhail
(In reply to comment #7) > (In reply to comment #6) > > Also the extension point schema definition does not seem to be correct. > I've fixed this, so no need in a new patch.. > So the only question left is with specifying the template location.. > Mikhail I think instead of working from template location, it would be better to work from 'template id'. I am not very sure whethere we can change the templates extension point definition and add 'id' as an additional mandatory field. If that's ok, then I will change the schema to take the unique id as the attribute, instead of location.
Created attachment 66659 [details] Patch for changing the common identifier from location to id. This patch includes changing the common identifier from 'location' to 'id' for templates. Mikhail, This doesn't include the problem you corrected in the 'addToolChainsToTemplate' schema. Please include that. Thanks, -Bala
(In reply to comment #8) > I think instead of working from template location, it would be better to work > from 'template id'. I think this is the best approach we can do > I am not very sure whethere we can change the templates > extension point definition and add 'id' as an additional mandatory field. If > that's ok, then I will change the schema to take the unique id as the > attribute, instead of location. I guess we could make the "id" attribute as optional and if not specified - use the id specified in the template definition (template.xml). In this case there will be no API breackage. Mikhail
(In reply to comment #9) Hi Bala, How should I merge the changes in this patch with those you sent with the previous one? Should I apply the previous one first? Thanks, Mikhail
(In reply to comment #9) > Created an attachment (id=66659) [details] Thanks Bala, Could we make the id attribute behave as specified in the comment# 10? Mikhail
(In reply to comment #11) > (In reply to comment #9) > Hi Bala, > How should I merge the changes in this patch with those you sent with the > previous one? > Should I apply the previous one first? > Thanks, > Mikhail THe previous patch needs to be applied first. Then apply this patch on top of this. Not sure how the merge will work. Since I can't produce an incremental patch, I just picked the files that are modified as part of this fix, and created the patch. I am posting a full patch for the three defects together including these changes, just in case if you have trouble merging the earlier patches.
Created attachment 66664 [details] full patch This patch also includes implementation as per comment#10.
I'm getting NPE with the latest patch: steps to reproduce: 1. New Workspace 2. New -> "C++ Project" Stack-trace below Thread [main] (Suspended (exception NullPointerException)) TemplateCore.<init>(TemplateInfo) line: 81 TemplateCore.getTemplate(TemplateInfo) line: 234 TemplateEngine.getTemplates() line: 75 TemplateEngine.addToolChainsToTemplates() line: 240 TemplateEngine.initializeTemplateInfoMap() line: 235 TemplateEngine.<init>() line: 61 TemplateEngine.<clinit>() line: 49 TemplateEngineUI.getTemplates() line: 86 TemplateCNewWizard.createItems(boolean, IWizard) line: 33 CDTMainWizardPage.updateData(Tree, Composite, Button, IWizardItemsListListener, IWizard) line: 431 CDTMainWizardPage.createControl(Composite) line: 116 CCProjectWizard(Wizard).createPageControls(Composite) line: 170 WizardDialog.createPageControls() line: 669 WizardDialog.setWizard(IWizard) line: 1083 WizardDialog.updateForPage(IWizardPage) line: 1142 WizardDialog.access$2(WizardDialog, IWizardPage) line: 1139 WizardDialog$4.run() line: 1128 BusyIndicator.showWhile(Display, Runnable) line: 67 WizardDialog.showPage(IWizardPage) line: 1126 NewWizardSelectionPage.advanceToNextPageOrFinish() line: 71 NewWizardNewPage$1.doubleClick(DoubleClickEvent) line: 355 StructuredViewer$1.run() line: 799 SafeRunner.run(ISafeRunnable) line: 37 Platform.run(ISafeRunnable) line: 850 JFaceUtil$1.run(ISafeRunnable) line: 46 SafeRunnable.run(ISafeRunnable) line: 193 TreeViewer(StructuredViewer).fireDoubleClick(DoubleClickEvent) line: 797 TreeViewer(AbstractTreeViewer).handleDoubleSelect(SelectionEvent) line: 1369 StructuredViewer$4.widgetDefaultSelected(SelectionEvent) line: 1168 OpenStrategy.fireDefaultSelectionEvent(SelectionEvent) line: 237 OpenStrategy.access$0(OpenStrategy, SelectionEvent) line: 234 OpenStrategy$1.handleEvent(Event) line: 295 EventTable.sendEvent(Event) line: 66 Tree(Widget).sendEvent(Event) line: 938 Display.runDeferredEvents() line: 3673 Display.readAndDispatch() line: 3284 WizardDialog(Window).runEventLoop(Shell) line: 820 WizardDialog(Window).open() line: 796 NewProjectAction.run() line: 116 NewProjectAction(Action).runWithEvent(Event) line: 498 ActionContributionItem.handleWidgetSelection(Event, boolean) line: 545 ActionContributionItem.access$2(ActionContributionItem, Event, boolean) line: 490 ActionContributionItem$5.handleEvent(Event) line: 402 EventTable.sendEvent(Event) line: 66 MenuItem(Widget).sendEvent(Event) line: 938 Display.runDeferredEvents() line: 3673 Display.readAndDispatch() line: 3284 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2365 Workbench.runUI() line: 2329 Workbench.access$4(Workbench) line: 2204 Workbench$4.run() line: 466 Realm.runWithDefault(Realm, Runnable) line: 289 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 461 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 106 EclipseAppHandle.run(Object) line: 153 EclipseAppLauncher.runApplication(Object) line: 106 EclipseAppLauncher.start(Object) line: 76 EclipseStarter.run(Object) line: 363 EclipseStarter.run(String[], Runnable) line: 176 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object[]) line: 324 Main.invokeFramework(String[], URL[]) line: 497 Main.basicRun(String[]) line: 436 Main.run(String[]) line: 1162 Main.main(String[]) line: 1137
(In reply to comment #15) > I'm getting NPE with the latest patch: I seem to know how to fix this, will postr an update on this soon
(In reply to comment #16) > (In reply to comment #15) > > I'm getting NPE with the latest patch: > I seem to know how to fix this, will postr an update on this soon Thanks Mikhail, The fix could be like this. Make the TemplateEngine.getSharedDefaults()' method as static and at the null pointer exception place, take the 'getDefault()' from the templateengine call. ie. call this static method.
(In reply to comment #17) > Thanks Mikhail, The fix could be like this. > Make the TemplateEngine.getSharedDefaults()' method as static and at the null > pointer exception place, take the 'getDefault()' from the templateengine call. > ie. call this static method. Thanks Bala, I've already got a bit alternative fix that seems to work fine. One additional minor question I have is naming: what about naming the new addToolChainsToTemplate extension point as "templateAssociations"? This would allow, e.g. add template <-> project type associations via the same extension point once we implement multiple project type associations. If you are OK with this change, I could do it myself. Mikhail
(In reply to comment #18) > One additional minor question I have is naming: what about naming the new > addToolChainsToTemplate extension point as "templateAssociations"? > This would allow, e.g. add template <-> project type associations via the same > extension point once we implement multiple project type associations. > If you are OK with this change, I could do it myself. OK, since there are no objections I'm going to procede with this..
(In reply to comment #19) > (In reply to comment #18) > > One additional minor question I have is naming: what about naming the new > > addToolChainsToTemplate extension point as "templateAssociations"? > > This would allow, e.g. add template <-> project type associations via the same > > extension point once we implement multiple project type associations. > > If you are OK with this change, I could do it myself. > OK, since there are no objections I'm going to procede with this.. Sorry.. Was away on a meeting. The change in name is fine for me.
(In reply to comment #20) > Sorry.. Was away on a meeting. The change in name is fine for me. Thanks Bala, and sorry for being hurried ;).. just wanted the functionality to be checked in as soon as possible and thoroughly tested for the M7. The patch is applied now. Closing the bug.. Thanks, Mikhail
