Community
Participate
Working Groups
Add project templates. Eclipse should provide a streamlined way to create projects using templates contributed by plug-ins. These project templates would be able to populate the projects with stock content so that projects don't start off completely empty. PDE's current mechanism should be generalized, pushed down into the Platform, and put to good use by JDT. [Platform UI, JDT UI, PDE UI] [Theme: User experience]
Copy of post by me to platform-ui-dev on April 28: Further to the post from Aleksey at Exigen on the eclipse-dev mailing list, we would like to start the discussion on support for templates in Eclipse R3.0. Aleksey, we welcome any thoughts, comments, and code that you wish to contribute. I'd also like to encourage others in the community to list their requirements too, and get involved in other ways if interested. The item from the draft 2.2 plan is as follows: <see above> The support for templates in PDE was never meant to be a general purpose solution. It was designed specifically for PDE's needs and the use cases they needed to address. If we're going to look at pushing this down to Platform UI, we need to understand: - what are the essential aspects of the current support as far as PDE's needs are concerned? - what are the limitations of the current support, that need to be improved to support important use cases for other products? - what is the current level of support in Exigen? Aleksey already mentioned a few points where Exigen's support is more general than the current PDE support: 1. resource templates and non-resource templates 2. template support for meta-projects ("solutions") By (1) I assume that the template engine can generate templates for arbitrary files, not just workspace resources. If not, please clarify. This would be a key requirement for template support in Platform UI since, as part of the refactoring for the Rich Client Platform, we want the central "Workbench proper" to avoid any dependencies on org.eclipse.core.resources. The template engine should do the same, to allow applications other than those centered around the workspace to use templates. By (2) I assume that the template engine can generate multiple pre-populated projects from a template, and/or generate individual folders/files across projects. If not, please clarify. Although the Workspace does not have the concept of a "solution", this seems like a reasonable feature to support. It would be good to list some of the concrete use cases that justify this.
Alexsey responded with: I have placed template plugin and all documentation on site: http://mbx.mobilae.ru/~alekseys/eclipse/ Plugin can be downloaded from eclipse update site: http://mbx.mobilae.ru/~alekseys/eclipse/updates (Eclipse 2.1 required) for public review. Ideas and comments are welcome and: Nick Edgar wrote: >By (1) I assume that the template engine can generate templates for >arbitrary files, not just workspace resources. If not, please clarify. >This would be a key requirement for template support in Platform UI since, >as part of the refactoring for the Rich Client Platform, we want the >central "Workbench proper" to avoid any dependencies on >org.eclipse.core.resources. The template engine should do the same, to >allow applications other than those centered around the workspace to use >templates. When template is installed, it may be used to generate: 1) projects in workspace - using standard Eclipse wizards and New>Project menu 2) project resources (file, folder) in workspace - using standard Eclipse wizards and New>Other menu 3) everything else if using proprietary UI. actually, template internally implements a factory. This factory can be arbitrary nature. For example, it can be a template for some database. Also the case is the template for less-than-file thing, for example, template for some portion of a file, e.g. template for Java function. >By (2) I assume that the template engine can generate multiple >pre-populated projects from a template, and/or generate individual >folders/files across projects. If not, please clarify. Although the >Workspace does not have the concept of a "solution", this seems like a >reasonable feature to support. It would be good to list some of the >concrete use cases that justify this. Template for solution generates multiple projects. Each project is generated from own template. A solution is a collection of projects associated by common use. For example, a solution may contain Java project, project for database and project for Web UI. Togerther these projects consitutes complete business application. Solution template creates all these projects and associations between them. If it is interesting as spearate feature, worth sharing idea on supporting "solutions" in eclipse 3.0. We have a feature supporting them. >Nick >Eclipse Platform UI Team Lead
Bob Foster added: > I'd also like to encourage others in the community to list their > requirements too, and get involved in other ways if interested. Here's a use case: A feature several of my plugin users have requested is the ability to use one of their own documents as a template when creating new documents. They want to be able to set up such documents as defaults on a per-extension basis and to be able to specify one in the New dialog. I have an experimental implementation of this in the next version of my editor. While implementing it, several requirements suggested themselves: - First, a terminology problem. We must distinguish between file templates and what JDT currently calls templates. I will call the latter macro templates. - Users will not want to rewrite their exemplar documents in order for them to serve as templates. Zero learning should be required. This implies that file templates should not be (required to be) in the form of XML documents or other unnatural formats, but that the default file template expansion is a simple copy. - Users will not want these exemplar documents required to be located in a single project or workspace. I deal with that by allowing relative (with full ../.. support) and absolute paths and even URLs (but of course I have a caching mechanism that takes the pain out of routine use of internet resources). - Conversely, some users will want to take advantage of standard macro templates used by the wizard, like the JDT filecomment. It may also be true that the project or file creation wizard will define values of additional macro templates that may be expanded in the course of expanding the file template(s). My wizards do this using my internal macro templates. This implies that a) there must be a textual way of requesting the expansion of a macro template, e.g., ${filecomment} and b) the standard/wizard macro templates must be documented and become API. - This consideration strongly suggests that the macro template mechanism be factored out of JDT and into a generic package that is applicable to all editors and can be used for file template expansion. I wrote my own for code assist and later for wizard expansion. I think that's enough use case right there. - A minor point, but if users are to be able to define their own macro templates and if these templates are to be used as ${filecomment} above, this implies that macro expansions are re-scanned (which is standard enough in the macro world, but may be a novelty to JDT templates). - "Expansion" for file or project wizards requires a) the ability to create directories, if they do not already exist, b) the ability to copy zero or more existing files or resources (in the Java sense) into each such directory, c) with optional macro template expansion within each file. - And, of course, the requirement that started it all, that users, not just plug-in developers, be able to supply file templates used by standard and plug-in supplied wizards.
Source zipped project can be found at http://mbx.mobilae.ru/~alekseys/eclipse/com.exigen.studio.templates.zip
1 question, 1 suggestion: ? How would a project wizard be extended under this design? FWIW, a feasible/nice example: WebSphere Studio's web project wizards have contributable features, which can be hierarchical. Plugins can contribute features, which are user-selectable via a checkbox tree. Selected features can contribute UI pages or to code generation (or both). ! For the file templates, consider using JET, a part of EMF. It has the advantages of being already part of Eclipse, and of having a relatively simple, JSP-like syntax. It also Really Works: at least 2 groups in WebSphere Studio use it for code generation. It has the disadvantage of being relatively unsupported, and virtually undocumented, since the EMF folks obviously have other priorities. (But perhaps adoption for this would improve its priority :-) Notably, end-user extensibility is not currently supported, though IMHO this is a great shame, and should be rectified soonest, since it should be relatively easy/cheap to provide.
Contributable features is a good use case and this is an example that one template may include a set of other teplates forming a hierarchy. I mean that those "contributable features" can be regarded as templates as well. (If you consider template as a generic factory, not a form of a document).
Has anyone looked at Velocity (http://jakarta.apache.org/velocity/) for template support?
nick_edgar@ca.ibm.com 2003-05-09 11:24 > Has anyone looked at Velocity (http://jakarta.apache.org/velocity/) > for template support? Yes. It's a nice technology, esp for the view space. However, IIRC, the Studio folks decided to go with JET because * its JSP-like-ness is very nice for code generation. Velocity does not allow code in its templates, which IMHO ironically makes it better suited for the view space than JSPs, but I suspect would get annoying for codegen. (I suspect one can workaround this with one's VelocityContext, though.) * we knew the guys who originally wrote JET, and they're just a few cubes away :-) * ... therefore we have the documentation they wrote, which is AFAIK still virtually completely applicable * we never expected that EMF's support would be <possibly unfairness/> be as limited as it has been. AFAICS they're after MDD, and _mere_ templating is not high on their agenda. Note also that, if it makes a difference, * Velocity has a template editor plugin @ http://veloedit.sourceforge.net/ * there is also some nice JET-editing tooling, but, again, IIRC, it is unsupported :-( If you wanna know more, I can forward to its author.
*** Bug 28229 has been marked as a duplicate of this bug. ***
Due to higher priority items, this item is currently marked as deferred on the R3.0 plan: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0.html Unfortunately, the Eclipse team will not be able to address this item until our committed and proposed items have been addressed. This item does have a high level of community interest though. If somebody in the community would like to take the lead on this item, the Eclipse team will support you as much as we are able to. My preference would be to base it on the Velocity engine, for the following reasons: 1. it is a separate open source project, with all the benefits that entails: - not having to reinvent the wheel - support - documentation - community involvement - not having to take significant cycles from the Eclipse team - higher chance of having useful contributed templates - better synergies all around 2. it's powerful enough to be used for applications beyond project templates 3. one of our main competitors uses Velocity, to apparently good advantage http://www.intellij.com/docs/help/managingFiles/fileTemplates.html http://jakarta.apache.org/velocity/devtools.html
deferring
I like to add the requirement of dynamic templates. I currently maintain a site with hundreds of projects which, unfortunately, requires many boilerplate files for build.xml, build.properties, manifest.mf, etc. These files are often - exactly- the same. It would be very nice if I could maintain these files in a central location.
The standard support for project templates is very important/useful for any kind of development tool support on top of eclipse. Currently, there seems to be several disconnected efforts to have this available in a number of "official eclipse" extensions/tools, e.g. WTP, Pollinate etc. And they are all implementing this over and over again. If it is in any way possible to get this into the platform and out of these extension projects before the final 3.1, it would be a big service to the plugin development community! Regards Erwin
This item will not be addressed for 3.1 (it was not even a proposed item on the 3.1 plan: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_1.html) We will reassess for 3.2.
FYI, for plug-in developers who want to contribute templates to the New Plug- in Project creation wizard, PDE has exposed API and extension points to allow you to do so as of 3.0. Check out the org.eclipse.pde.ui.* extension points.
This is no longer a plan item.
*** Bug 157690 has been marked as a duplicate of this bug. ***
*** Bug 212503 has been marked as a duplicate of this bug. ***
