Community
Participate
Working Groups
Extension that allowes extendors to provide their own entries in the Target Platform page. Users should be able to provide their own UI ( wizard) to create that Entry, and also to edit the contents of this entry.
Will be considered for 3.8 depending on resources available.
Splitting into smaller tasks: 1) Develop the new API (extension point and interfaces) 2) Rewrite the locations UI to only work through the new API 3) Rewrite existing location types to be provided via new extension point 4) Refactor existing target APIs to ensure support for specialized use cases like p2 5) Make existing target API public (currently provisional) 6) Provide article/tutorial on the Target API For (1) we will need to create a list of all functions the target framework will require. An initial list: Label provider, Content provider, XML (de)serialization, Add/edit wizard, Update function, error handling Debug has the concept of a model presentation and uses adapters to accomplish something similar. However, this may be too heavy handed. On the other hand, we likely need more than an extension point/factory pattern.
Created attachment 200271 [details] Work In progress (do not review) Just shows the direction I am going.
Created attachment 200533 [details] review only design The design is like this pde.core has new ext pt called locations. user can contribute type and an associated IBundleContainer or a factory (IAdapterFactory) which knows how to create the container/location (rename will be done later) exisiting target file pasrsing code moved to a new helper class which creates the factory/container object on demand (might need some improvements) pde.ui has the ext pt called targetLocationProvider ext to it will provide the wizard which will be used when adding the a new container/location it will also provide the bundle containers added by using it I have delegated it to provide the labelProvider for the container as well. But this is WILL CHANGE. I am working on this side of design.
am changing targetLocationProvisioner ext pt to pde.ui. it currently takes name and icon. This is wrong. Moving it in different heirarchy so that user can tell name and icon for its bundlecontainer type. when not found, we will show a default image and type name. updated patch coming soon.
Mike and I discussed the design this morning and have a few suggestions. Reply or ping us with what you think. Existing API: ITargetDefinition should be marked @noimplement We may want to provide an implementation of IResolvedBundle IBundleContainer should be renamed ILocation or ITargetLocation The following methods should be available on ILocation getType() string name for the type of location, not internationalized getLocation() local file location, currently needed for the target preferences support which will hopefully be removed during 3.8 getID() string to identify a specific location, we could use some sort of equals method instead serialize() returns a String of XML or an IMemento Core extension point: Ext Point called "org.eclipse.pde.core.TargetLocations" Extensions define... A string location type (matches getType()) A class implementing ITargetLocationFactory which has a single method that takes a String or IMemento and returns a ILocation It isn't necessary for the existing directory/installation/etc locations to implement this, but we can do so if it simplifies persistence code. Persistence: Increment the file version Existing code to read old versions would be kept in the helper classes Saving targets would write out target info as before. To write out each ILocation, a new attribute would be created <location type="" location=""> (it should look the same as it does currently). Then the result of serialize() on the ILocation would be added as a nested element. With the work on target platform per project, we should be able to eliminate the need to store the location. Loading new versions would read the file loading target info. When reaching the locations section, would read each location element to get type attribute. Based on the type we would delegate to the TargetLocations extensions or some local helper class. Note that older versions of the files will not support new kinds of locations. UI API Might be possible/easier to do this with adapters. The client would contribute an adapter factory. ILocations would have to extend IAdaptable and clients who want children items in the UI would need those children to also be adaptable. This could be done explicitly with an extension point, but if the UI were to change in the future it is harder to evolve the API. I don't think there is much benefit to having the icon/name be available in an extension point vs a factory (adapter or otherwise). If a user has opened the target UI, we likely will need several UI bits from the factory (content/label provider plus add wizard metadata). Mike can probably add more suggestions here.
Created attachment 201555 [details] Patch Known issues 1. Refactoring the API package has touched many files. Need to update the copyright dates 2. Making ITargetLocation API would leak IFeatureModel (currently internal). This is a serious problem. Working on it.
I am moving "public IFeatureModel[] getAllFeatures();" out of ITargetLocation api to deal with it.
(In reply to comment #7) > 2. Making ITargetLocation API would leak IFeatureModel (currently internal). > This is a serious problem. Working on it. This will be frustrating. I suspect that we will have to provide a new object, similar to a resolved bundle (IResolvedFeature). Did you change the IResolvedBundle interface to just a public class? We should also provide a convenience method to collect the features in a directory (this will redirect to the ExternalFeatureModelManager. There are other options, but I think this pattern will allow us the most flexibility in future API.
1. IResolvedBundle is a public api now 2. When I said ITargetLocation, I actually meant ITargetDefinition :) 3. How about a Factory/Helper API that can be used by contributors to instantiate IResolvedFeature and IResolvedBundle?
Created attachment 203632 [details] Git Patch Curtis, please let me know if the patch would apply fine
(In reply to comment #11) > Created attachment 203632 [details] > Git Patch > > Curtis, please let me know if the patch would apply fine The provided patch is incomplete. The new package org.eclipse.pde.core.target and all classes in it are not in the patch. In addition, some of the files don't apply cleanly. core's plugin.xml, TargetContentsGroup, ExportTargetJob, TargetDefinitionExportWizard. Ping me when available so we can sort this out. Probably easier for you to create a branch.
Bug hasn't been kept up to date the code is now in a branch in the git repository http://git.eclipse.org/c/pde/eclipse.pde.ui.git/?h=347695_target_ui_api There is an API but it still requires a lot of work to be complete. A list of some of the things I've done so far: Added proper api tooling tags to restrict API use. Improved naming and documentation throughout the entire API. Rewrote TargetBundle to be usable, moving non-essential methods out of API. Handled error cases with location factory and helper. Removed parent container from target bundles (not used in the UI anymore). Removed optional bundle filter (to remain backwards compatible we treat optional as normal includes). Things I will do in the near future: - Fix the TargetFeature API class (no doc, limit what is API) - Review the UI API and its documentation - Fix tests (only one failure after latest changes) Other items to complete: - Look into removing sourcePath attribute of target bundles, there to support old school source plug-ins - Look into removing getLocation() (depends on target per project changes) - Look into removing description method from ITargetLocationFactory (it's only purpose is to provide some text in the UI when creating a new one) - Add better failure cases for serializing/deserializing - Move our target location implementations to dogfood new API on core side - Improve UI APIs, currently only have a wizard node and label provider adapter and a description from the factory. Need to find better place for description. Clients may also want to provide a content provider (like the p2 one that shows root IUs as children), an edit wizard (vs new wizard). - Write a reference implementation for the new UI API or move a complex location such as the p2 one over to the API. - Create reference implementation to test
> - Fix the TargetFeature API class (no doc, limit what is API) Done, the method are much more limiting now, no need for adapters in it > - Review the UI API and its documentation Since there is no actual API in the UI, this is done. However I think doing a reference implementation will demonstrate the limitations we currently have. > - Fix tests (only one failure after latest changes) Done, the parent container on locations (which I removed was being used to ignore missing bundles when there was a missing feature).
Ankur and I have put a lot of work into the 347695_target_ui_api branch. We will merge the branch back into master at the start of M4. From there I will discuss with Zina whether the API will cover everything required or if there are additional tweaks we want to make in 3.8 before the API is locked in.
The squashed changes have been merged and pushed to master http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=1a8694c09f3f311ed3e9148535be1aff35a12269 Zina, please go over the API to see if it will meet your needs. The next integration build with the new API will be tomorrow morning. If you have any questions feel free to ping me directly and I will follow up with you during this milestone. Everyone, please report any bugs found along with any changes needed to evolve the API during the release (while we still can).
Tested the target platform heavily during today's milestone test pass. Things appear to be working well. I am still looking to get feedback from Zina.
