Community
Participate
Working Groups
Build ID: 20080617-2000 Steps To Reproduce: Hi. The problem I'm trying to solve is to make some templates that come with plugin's (say "MPI Hello World C Project" and "OpenMP Hello World C Project" when PTP is installed) UNavailable with our tools when our plug-in is installed. For example, I want these two templates to be still available with "Linux GCC" but not with our (Intel) toolchain. Currently, I believe, there's a way to do this especially if the original <template doesn't define templateAssociations. It would be really nice to be able to do this. I don't know how. One thing I can think of is to spply negative form of <toolChain so that we can do something like <excludeToolChain id=blah blah" in templateAssociations Thanks a bunch for consideration. More information:
I guess "excludeToolChain" wouldn't work well by itself because you'd have to know the ids of the templates you want to exclude. Maybe a better way to do is to add a support to an element, say, "filterList" that you can use to list all the templates you want available with your toolchains. I haven't really thought through this but I'm thinking something like this. <extension point="org.eclipse.cdt.core.templateAssociations"> <filterTemplate id="org.eclipse.cdt.build.core.templates.*,com.xxx.yyy.*"> toolChain id="*"> // all toolchains specified in com.xxx.yyy/plugin.xml </filterTemplate> <template id="org.eclipse.cdt.build.core.templates.A"> <toolChain id="com.xxx.yyy.A"> // plugin.xml specifies com.xxx.yyy.[A-D] <toolChain id="com.xxx.yyy.B"> </template> In this case, only the templates that have id "org.eclipse.cdt.build.core.templates*" would be made available with toolchains specified in the current plugin.xml (com.xxx.yyy/plugin.xml). For "org.eclipse.cdt.build.core.templates.A", templateAssociation->template exists, so the template will be available for only toolChains A and B. For, say, "org.eclipse.cdt.build.core.templates.B", templateAssociation->template doesn't exists, so the template will be available for all toolchains specified in the current plugin.xml. Any templates that have ids that don't match the pattern would be made unavailable with any toolChains in the current plugin.xml. (if the plugin.xml should specify templateAssociation->template with any of these, the entry would be ignored) Instead of <template id="org.eclipse.cdt.build.core.templates.A"> <toolChain id="com.xxx.yyy.A"> // plugin.xml specifies com.xxx.yyy.[A-D] <toolChain id="com.xxx.yyy.B"> </template> Maybe we can support a new attribute <excludeToolChin and use it like <template id="org.eclipse.cdt.build.core.templates.A"> <excludeToolChain id="com.xxx.yyy.C"> // plugin.xml specifies com.xxx.yyy.[A-D] <excludeToolChain id="com.xxx.yyy.D"> </template> To make things more intuitive.
I looked more into this and feel the cleanest way to do this would be to create a new extension that is used to specify the id of templates that can be made available with a toolchain. We can make it override associations created via templates and templateAssociation extensions if there is a conflict. For example, <extension point="org.eclipse.cdt.core.templateList"> <toolchain id="xxx.toolchain.yyy" exclusiveList="org.eclipse.cdt.build.core.templates.HelloWorldCAnsiProject"> </toolchain> <toolchain id="xxx.toolchain.zzz" exclusiveList="org.eclipse.cdt.build.core.templates.HelloWorldCAnsiProject,org.eclipse.cdt.build.core.templates.HelloWorldCppAnsiProject"> </toolchain> </extension> This says the only template that should be available with xxx.toolchain.yyy is org.eclipse.cdt.build.core.templates.HelloWorldCAnsiProject. and only org.eclipse.cdt.build.core.templates.HelloWorldCAnsiProject and org.eclipse.cdt.build.core.templates.HelloWorldCppAnsiProject should be available with xxx.toolchain.zzz. I think we can have Templateengine process this extension before initializeTemplateInfoMap and filter the addition of toolchain with the info. I'm attaching a simple modification that demonstrates my idea. (It's not been tested well and it's not a patch). With the patch, you could add the following to gnu.ui plugin.xml, for example, to see how it works. <extension point="org.eclipse.cdt.core.templateList"> <toolChain id="cdt.managedbuild.toolchain.gnu.base" exclusiveList="org.eclipse.cdt.build.core.templates.EmptyProject"> </toolChain> </extension> Any feedback, especially on whether I should pursue this idea or not (so that I can potentially contribute a patch) is appreciated. Thanks.
Created attachment 156186 [details] prototype code change
This request certainly makes sense. I think that to specify a list of templates for a toolchain is more natural than the other way around (list of toolchains per template). Here is another possible example of the extension point. Let me play with the tag names so we could develop better wording. Also, for kicks, I put extension point to managedbuilder plugin. I am confused why notion of a toolchain appears in cdt.core. IToolChain is a managedbuilder class to where cdt.core has no dependencies. <extension point="org.eclipse.cdt.managedbuilder.ui.toolChainTemplates"> <toolChain id="cdt.managedbuild.toolchain.gnu.base" strict="true"> <template id="org.eclipse.cdt.build.core.templates.EmptyProject"/> <template id="org.eclipse.cdt.build.core.templates.HelloWorldCAnsiProject"/> </toolChain> </extension> Similar to yours but I added tag "strict". If it is "false" then templates add to the existing ones. Feel free to disagree with any of that, it is just brainstorming. I see a logical problem here though - what if several extensions try to assign strict/exclusive list for the same toolchain? How can your plugin override exclusive settings that another overconfident plugin set, are you at square one then? I tried your patch and did not see any difference in New Project Wizard. Also, the provided schema does not match.
Hi, Andrew. Thank you very much for taking a look at this. > Similar to yours but I added tag "strict". If it is "false" then templates add > to the existing ones. > I see a logical problem here though - what if several extensions try to assign > strict/exclusive list for the same toolchain? How can your plugin override > exclusive settings that another overconfident plugin set, are you at square one > then? Well.. I'm not sure. I guess the only functionality I was hoping to have corresponds to "strict"=false, i.e. I was thinking the templatelist can just accumulate, i.e. if plugin A has <toolChain id="cdt.managedbuild.toolchain.gnu.base" <template id="org.eclipse.cdt.build.core.templates.EmptyProject"/> </toolChain> and plugin B has <toolChain id="cdt.managedbuild.toolchain.gnu.base" <template id="org.eclipse.cdt.build.core.templates.HelloWorldCAnsiProject"/> </toolChain> then both templates can be made available with this toolchain. > I tried your patch and did not see any difference in New Project Wizard. Also, > the provided schema does not match. Mm.. ok. I'll update to HEAD and make sure the patch (or the new one) works, then let you know.
(In reply to comment #6) > Well.. I'm not sure. I guess the only functionality I was hoping to have > corresponds to "strict"=false, i.e. I was thinking the templatelist can just > accumulate, i.e. if plugin A has Isn't the purpose of this bug to not display templates contributed by another extension point? I think it is confusing to get rid of one kind of template list but assume accumulation of another.
> I tried your patch and did not see any difference in New Project Wizard. Also, > the provided schema does not match. Mm. seems to work for me. After applying the patch and making the modification in gnu.ui plugin.xml (sorry my original post has a typo. We need tool"c"hain, not tool"C"hain) <extension point="org.eclipse.cdt.core.templateList"> <toolchain id="cdt.managedbuild.toolchain.gnu.base" exclusiveList="org.eclipse.cdt.build.core.templates.EmptyProject"> </toolchain> </extension> I only see "Empty Project" and not "Hello World ANSI C Project" under "Executable"
Created attachment 157342 [details] screenshot without modification in gnu plugin.xml
Created attachment 157343 [details] screenshot with modification in gnu plugin.xml
> (In reply to comment #6) > Isn't the purpose of this bug to not display templates contributed by another > extension point? We can say that. My original motive was that I didn't want any PTP plug-in templates to show up with our (company) compiler plug-in because they were not compatible, while it was ok for some of the CDT templates to show up. >I think it is confusing to get rid of one kind of template > list but assume accumulation of another. Uh.. would you please elaborate?
(In reply to comment #8) > I only see "Empty Project" and not "Hello World ANSI C Project" under > "Executable" Thanks for the screenshots, that is helpful. I have cygwin and mingw installed so I still see all the set of templates under Executable. I lost "Linux GCC" toolchain under "Hello World Project" though. But it is still there in the list for "TestProjectWithExtraPages" and "TestWidgetsLabel" (that is contributed by Test plugin I believe).
(In reply to comment #11) > >I think it is confusing to get rid of one kind of template > > list but assume accumulation of another. > Uh.. would you please elaborate? I am getting confused. Hmm, maybe I was not clear in comment#5. <extension point="org.eclipse.cdt.managedbuilder.ui.toolChainTemplates"> <toolChain id="cdt.managedbuild.toolchain.gnu.base" strict="true"> <template id="org.eclipse.cdt.build.core.templates.EmptyProject"/> <template id="org.eclipse.cdt.build.core.templates.HelloWorldCAnsiProject"/> </toolChain> </extension> The idea was that strict="true" corresponds to what you are requesting, i.e. exclusiveList. strict="false" would add the template to the existing list, i.e. templates defined via extensions templates and templateAssociations. (In reply to comment #6) > I was thinking the templatelist can just accumulate, i.e. if plugin A has I guess it makes a certain sense. Hmm, what if somebody else desires to disable templates defined this way? Do they come up with a new extension point? I am inclined to think that the author of a new toolchain should be able to define the templates for his toolchain. He should specify if it is exact list (strict="true") or open-ended one (strict="false"). If you look at it that way - it should be sufficient to define one toolChainTemplates extension and not allow multiple for the same toolchain. If you don't like the defined templates - integrators can define their own toolchain subclassing original one.
Hi, Andrew. Thanks, it makes sense. Except this. - integrators can define their own toolchain subclassing original one. Gnu xml has this <toolChain superClass="cdt.managedbuild.toolchain.gnu.base" id="cdt.managedbuild.toolchain.gnu.exe.debug"> // there are others such as .exe.release, .lib.[debug/release] If you're saying the template filter can't be inherited, I wonder if it's a good idea.
(In reply to comment #14) > Thanks, it makes sense. > Except this. > - integrators can define their own toolchain subclassing original one. > Gnu xml has this > <toolChain > superClass="cdt.managedbuild.toolchain.gnu.base" > id="cdt.managedbuild.toolchain.gnu.exe.debug"> > // there are others such as .exe.release, .lib.[debug/release] > If you're saying the template filter can't be inherited, I wonder if it's a good > idea. How about if the template filter is inherited but can be overridden with new toolChainTemplates extension from the same plugin? Then you could add new templates or overwrite the old list.
> How about if the template filter is inherited but can be overridden with new > toolChainTemplates extension from the same plugin? Then you could add new > templates or overwrite the old list. Sounds good to me. Thanks.
Returning to the pool
It seems the design is pretty much set now(?). Would you like to implement this? If not, I can (hopefully by June)
I don't have much use for this feature so far but I would review your patch if you submit one.
OK. It's going onto my ToDo list. Thanks. :-)
Hi, Andrew. I am preparing the patches using your extention idea. I guess we haven't really decided on how to handle conflicts. You mentioned in one of your comment. "the author of a new toolchain should be able to define the templates for his toolchain." and I agree with it. We can for example make it a rule that whatever definition that's in the same plugin.xml as the toolchain takes precedence. Ex. Com.a/plugin.xml has <template id=com.a.template <toolchain id=com.b.toolchain Com.b/Plugin.xml has <configuration <toolchain id=com.b.toolchain <toolchaintemplate <toolchain id=com.b.toolchain strict="true" template id=com.b.template Then toolchaintemplate in com.b/plugin.xml wins. (BTW, I can't seem to find a way to get the id of the plugin certain extension point entry cmes from (ex. "com.a" for the <template extension) any more. Would you happen to know this off your head?) Should an ahthour define conflicing associations, this is what my code does now. - if there is a conflict between association created by <template or <templateassociations and association created with <toolchainTemplate with strict="true, the latter wins (ex. templateA is associated with toolchainA but <template but <toolchainTemplate with strict="true" associates toolchainA only with templateB, then toolchainA is only associated with templateB.) - if there are more than one strict="true" entries, we silently overwrite with the latter entry(ies) - strict=false works exactly like template definition or templateassociations in that the templates and toolchains mentioned in it are associated. We silently ignore (without issuing a warning, etc.) any duplicates. - if there is a strict="true" and strict="false" entries for the same toolchain, strict="true" wins. The rules above are pretty arbitrary. Considering these are unexpected conditions in a sense, maybe it doesn't matter much what we do. But if you disagree with any of the behavior, please let me know. One unresolved issue is that the extension doesn't work if neither <template or <templateAssociations extension associate a toolchain to a template. As I noted in Bugzilla 275729 "If a template doesn't have non-empty toolchain templateAssociation, TemplateEngine (addToolChainsToTemplates) associates an empty toolchain set to it.... And, downstream, managedbuilder ("isToolChainAcceptable" in MBSWizardHandler) assumes the template is available for all toolchains if an empty toolchain set is associated with it (toolChainIDs.length==0)" I don't know why this was designed this way, so I didn't try to fix this issue.
>(BTW, I can't seem to find a way to get the id of the plugin certain extension point entry cmes from (ex. "com.a" for the <template extension) any more. Would you happen to know this off your head?) Never mind this. I found it. Thanks.
Created attachment 167514 [details] patch (not final) I'm attaching what I have. It doesn't include the logic that handles the conflict based on the plugin ID.
(In reply to comment #23) > Created an attachment (id=167514) > patch (not final) > I'm attaching what I have. It doesn't include the logic that handles the > conflict based on the plugin ID. The patch is incomplete. I am getting exception: java.lang.NullPointerException at org.eclipse.cdt.core.templateengine.TemplateEngine.processToolchainTemplates(TemplateEngine.java:283) at org.eclipse.cdt.core.templateengine.TemplateEngine.initializeTemplateInfoMap(TemplateEngine.java:229) at org.eclipse.cdt.core.templateengine.TemplateEngine.<init>(TemplateEngine.java:81) at org.eclipse.cdt.core.templateengine.TemplateEngine.getDefault(TemplateEngine.java:211) at org.eclipse.cdt.ui.templateengine.TemplateEngineUI.getTemplates(TemplateEngineUI.java:68) at org.eclipse.cdt.ui.internal.templateengine.wizard.TemplateCNewWizard.createItems(TemplateCNewWizard.java:34) at org.eclipse.cdt.ui.wizards.CDTMainWizardPage.updateData(CDTMainWizardPage.java:291) at org.eclipse.cdt.ui.wizards.CDTMainWizardPage.createControl(CDTMainWizardPage.java:93) at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:170) at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:734) at org.eclipse.jface.wizard.WizardDialog.setWizard(WizardDialog.java:1162) at org.eclipse.jface.wizard.WizardDialog.updateForPage(WizardDialog.java:1221) at org.eclipse.jface.wizard.WizardDialog.access$4(WizardDialog.java:1218) at org.eclipse.jface.wizard.WizardDialog$6.run(WizardDialog.java:1207) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) Looks like org.eclipse.cdt.managedbuilder.ui.toolChainTemplates extension point is not defined in plugin.xml
Created attachment 171477 [details] patch (corrected, not final) Hi, Andrew. Thank you for taking a look at this again and sorry about a goof. Please try this one. It also includes modified org.eclipse.cdt.managedbuilder.gnu.ui plugin.xml that has some testing conditions at the bottom.
While I am looking at this task I stumble into the issue of current New Project Wizard being inconvenient both from user POV and ISV POV and codewise. Could you comment on bug 197802 comment#1? I think it's relevant. Maybe we need to look at your proposal in conjunction with a new wizard?
Seems that the new wizard proposal has been pretty quiet. Would it be covered in the summit?
I don't think I could work on this in foreseeable future, returning to the pool. I think this needs to be looked at from usability point of view of the New Project Wizard. If there is some progress with bug 368552 this proposal should be reevaluated.
