| Summary: | Provide Mylyn User Runtime Feature | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Miles Parker <milesparker> |
| Component: | Mylyn | Assignee: | Mylyn Inbox <mylyn-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | mik.kersten |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Miles Parker
We have iterated over this quite a bit. The challenge is that there is no simple runtime feature that any user could install without a risk of pulling in undesired dependencies. The moment we include the JDT bridge the feature is already useless for CDT and PHP programmers and other non Java developers. We could consider a "Mylyn for Java Programmers" feature which would include the all the features that we ship in the EPP Java package but then I would recommend getting the EPP package instead. I would prefer a solution where users only select one base Mylyn feature and all relevant bridge features are automatically recommended based on the installed integrations, i.e. if a user has CDT, Mylyn should recommend installing the CDT bridge and provision it automatically. The same goes for connectors, if a Trac of Bugzilla server is detected the corresponding connector should be provisioned. (In reply to comment #0) > 4. Egit Mylyn > > BTW, why isn't this last called something like Mylyn EGit Support? The features is provided by EGit and not Mylyn. I assume it follows the EGit conventions for naming features. Closing for reasons stated in comment#1. Due to the number of integration features and the diverse set of dependencies there is no clear answer what to in a runtime feature. I would recommend consuming Mylyn through EPP packages to obtain the recommended set of integration features for a particular domain. |