Bugzilla – Full Text Bug Listing
| Summary: | Refactor out templates into a separate plugin(s) | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Chris Aniszczyk <caniszczyk> |
| Component: | UI | Assignee: | Wassim Melhem <wassim.melhem> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | baumanbr, jeffmcaffer, lchan, wassim.melhem |
| Version: | 3.2 | ||
| Target Milestone: | 3.3 M4 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 163175 | ||
| Bug Blocks: | |||
|
Description
Chris Aniszczyk
comments gentleman? Not a bad idea. we will need PMC comments/approval on that. so this will have to wait until the PDE PMC Jeff return from vacation. thinking about this, we should have two plugins, one for eclipse specific content, the other for OSGi specific content sound reasonable? no, that would result in too much fragmentation. One plug-in would be sufficient. thoughts on this one Jeff? Why do we need to break the templates out into another plugin? Will it ever ship separately or will PDE ship without it? Here are my reasons in a random order of importance 1) The common case here is you have products that build on PDE. The products use PDE or even modify it (in our case, we modify it). There are cases when products don't want to ship with PDE's normal templates, they would want to ship with their own. So, instead of modifying PDE, you just drop another plug-in to ship. 2) PDE UI is huge 3) This is a good case of plug-in refactoring. My definition of when to make things a plug-in is when they have no strict dependency on the host. PDE UI can live w/o templates. I somehow managed to convince Wassim this was a good idea, but I forgot what I bribed him with ;) (In reply to comment #7) I don't want to stand in the way but do want to understand. > 1) The common case here is you have products that build on PDE. The products > use PDE or even modify it (in our case, we modify it). There are cases when > products don't want to ship with PDE's normal templates, they would want to > ship with their own. So, instead of modifying PDE, you just drop another > plug-in to ship. Is there a real need to remove the templates from PDE in product scenarios? A product that offers the developer a chance to develop plugins but does not allow them to use the basic templates seems a bit strange. Adding templates sure. I assume that the template set is already extensible no? > 2) PDE UI is huge not particularly compelling > 3) This is a good case of plug-in refactoring. My definition of when to make > things a plug-in is when they have no strict dependency on the host. PDE UI can > live w/o templates. Yes, but the question is whether or not anyone really wants it to live without the templates. What is the scenario under which someone would not ship the template bundle? > I somehow managed to convince Wassim this was a good idea, but I forgot what I > bribed him with ;) yeah but Wassim is easy. Or is it cheap... > (In reply to comment #7)
> Is there a real need to remove the templates from PDE in product scenarios? A
> product that offers the developer a chance to develop plugins but does not
> allow them to use the basic templates seems a bit strange. Adding templates
> sure. I assume that the template set is already extensible no?
Sure, there are products that build on top of PDE that work with special runtimes (for example, the new suite coming out of Lotus that are Eclipse-based). It is useful to reuse the PDE templating system for templates that apply for the specific product in question. There are cases when developers of products would want end-users to only use their templates. Is it easier to drop a bundle from your Eclipse-based product containing all of PDE's templates or to go hand pick out the plugin.xml to remove references to PDE's templates so your's only show up? (Brian, can you chime in here about your experience of building on top of PDE for a product)
Another point is that some of the new work that Kim Horne is doing around product customization could help with this problem. However, I don't think that's the right approach for this particular problem.
Also a point to make is that PDE isn't really considered a platform yet by any means, but in the future, with small steps like these (and exposing the ability for other OSGi Frameworks to use PDE), PDE becomes easier to consume.
This should be a fairly easy refactoring, we're not doing something like refactoring the runtime into several plug-ins ;)
I think comment 9 is spot on. We have seen several examples of people building products on top of Eclipse and wanting to control/modify/replace the list of templates PDE ships. Also, the Austin chapter of the PDE team has threatened to go on a hunger strike until the templates are refactored into a separate plug-in. Their demands are reasonable, and we really don't want to deal with a coup d'etat at this time. Like I said, just looking to understand not to block. you got a name in mind? submit a request in the Community/CVS bucket and CC me. I'll +1 Templates now reside in the new org.eclipse.pde.ui.templates plug-in. |