Community
Participate
Working Groups
The Mylyn Connector Discovery API is designed to be a more generic mechanism for easing the install of user-facing tools and enhancements into Eclipse. Since releasing the Mylyn Connector specific version of Discovery with Galileo, we have had numerous inquiries about generalizing this API.
Here's David Green's nice summary of Discovery, from bug 280726: (In reply to comment #3) > At a high level Mylyn uses the concept of a directory and connector descriptors. > The directory is a declarative (XML) resource that exists at a well-known URL, > and points to connector descriptors. Connector descriptors describe an > installable component, and include branding, description, images, etc. So > Connector Discovery first accesses the directory to discover where the connector > descriptors can be found, then downloads the descriptors to discover what the > installable units are. This design provides a central point of control for > updating what is discoverable, and avoids the need to install any plug-ins to > have contributions to the discovery UI. It also gives vendors the freedom to > update their contributions without involving changes or involvement by > committers, providing that their contribution is already listed in the > directory. Contributions may also be provided by installed plug-ins if desired. > > Interested parties may wish to take a look at the following Mylyn projects: > > * org.eclipse.mylyn.discovery.core > * org.eclipse.mylyn.discovery.ui > * org.eclipse.mylyn.discovery.tests
Here's how I suggested interested parties proceed: * Check out the code for the discovery bundles * Create your own discovery bundle, eg, org.eclipse.mumble.discovery.ui * Start extending the UI, and file bugs whenever there's something that's not generic enough, either provide a description, and then a patch for your needs * Consider creating a bug that's a subtask (blocks) this one for general discussion of your needs Once we have two fully-functioning clients, we can consider moving the reusable parts out of internal packages and into API, which would complete this plan item. Once we have grown an API and have a client outside of Mylyn we can consider the best home/project for this. I want to avoid moving it prematurely, ie, without concrete indication that others will be reusing this functinoality, as there should be nothing stoping reuse at this time. Like several other independently reusable Mylyn components, the Discovery Framework will continue to be decoupled Mylyn components other than the Commons API: http://wiki.eclipse.org/Mylyn/Integrator_Reference#Commons_API I just created a documentation section at: http://wiki.eclipse.org/Mylyn/Integrator_Reference#Discovery_API We'll also make a project set in order to make check-out easier, see provide bug 284503 and can provide tips on how to add these plug-ins to your build/releng proecess.
All subtasks have been completed. The discovery UI is now available in a separate viewer that can be integrated more easily in existing UIs that are not based on a wizard. In addition to categories entries can now reference a certification extension. The discovery listing displays a "Certified" link for certified extensions and provides a tooltip with a logo and details about the certification.
Mik presented this to the Architecture Council: http://wiki.eclipse.org/Architecture_Council/Meetings/November_12_2009 The AC meeting wiki is open for modifications to better clarify. I am monitoring page changes, so don't be afraid of breaking something, I can fix it just in case.
