Community
Participate
Working Groups
Created attachment 119021 [details] patch As part of 3.5, we are investigating ways to enhance target platform management - make it simpler for the user and eventually support multiple targets in the same workspace. This work requires a solid underlying model for "target definitions". I have started the work for this, and will attach a patch. We define a new "ITargetDefinition" which defines the attributes relevant to a target platform. In this model, a target may have a collection of "bundle containers". Each bundle container may contain executable bundles and/or source bundles. There will be a variety or implementations for "bundle containers" - for example, a directory of bundles, or a p2 installation/profile of bundles (which are provided with the patch). One could also imagine a "feature" bundle container including all bundles in a feature. Initial code and tests are supplied in the patch. I'll also have to attach a zip/binary required for the tests.
Created attachment 119023 [details] classic-plugins.zip This file has to go into a the \tests\targets directory in the pde.ui test plug-in. It is a skeleton of a 3.0.2 build used to validate recognition of 3.0 style plug-ins.
This currently a new model that is not connected with the rest of PDE. The intention is to get the model working properly and then get the rest of PDE to work with this model. The target editor will need to be re-worked to interact with the new model. Existing target files can be migrated to the new format. The "set target operation" would also be re-worked to use the new traget model.
Created attachment 119050 [details] updated patch Updated to recognize classic style source bundles.
Let's talk about this in tomorrow's PDE meeting. I have some new use cases around target management. If we could use the bundle container concept to support something like a remote OBR or IVY repository, we're on the right track. Thanks for doing the initial model work Darin.
Created attachment 119547 [details] updated patch This patch adds an ITargetPlatformService and the notion of an ITargetHandle. The target service replaces the factory class and the handles provide handle style access to the ITargetDefinition models. The handles allow separation of persistence from the models, and access to models (via mementos) accross workspace invocations. For example, the target platform preference will likely just be a target handle. A handle may refer to a local target definition (in workspace metadata), or a target definition in a specific IFile.
*** Bug 124542 has been marked as a duplicate of this bug. ***
Created attachment 120975 [details] catch up with changes in HEAD
Created attachment 120980 [details] update Added implementation of target handles and tests.
Created attachment 121558 [details] update for 2009 fixed up copyrights for 2009 - added some TODO's.
Created attachment 121570 [details] NLS'd messages
Applied the patch to HEAD with minor changes. Next is hooking up this awesome new model to the current target platform/PDE State and create the new UI.
Created attachment 122001 [details] org.eclipse.pde.ui.patch A quick dirty hack of a UI for managing target definitions. The feel of the page should be similar to the Installed JREs page. There's a lot of TODOs and I plan to handle those and coordinate with whoever wants to work on them.
Created attachment 122175 [details] patch This patch adds support for a "feature bundle container" so features can be added to target platform definitions, as well as an operation for setting the target platform based on a target definition (i.e. updates preferences and target platform similar to the current LoadTargetOperation). Also adds support for variables when specifying locations of profiles and features. Addds tests for setting the target platform, feature containers, and variables.
Darin's patch has been reviewed and committed. Work on the editor is coming along relatively smoothly.
Created attachment 122423 [details] Editor Work in Progress Recreates the editor using the new target model. We'll need to get the persistance working before this editor can be committed.
Created attachment 122424 [details] mylyn/context/zip
Created attachment 122437 [details] Adds save/delete & discover targets This patch adds support to find local/workspace target definitions to the target platform service, as well as support to save/delete targets via the service (which delegates to the handle implementations to do the actual work).
Applied Darin's patch for workspace/metadata target searching.
Created attachment 122498 [details] Supports bundle containers with a subset of bundles Thist patch allows a bundle container to be restricted to a subset of bundles within the container based on symbolic name and an optional version. We can use this to allow users to select a subset of bundles from a container.
committed Darin's updated patch
Added basic persistence functionality. Limited support for reading of old version files.
(In reply to comment #21) > Added basic persistence functionality. Limited support for reading of old > version files. Looks like you're using 1.5 methods for get/setTextContent(..) that don't exist in 1.4.
Added some more persistence work including some persistence tests.
Created attachment 122768 [details] support for implicit dependencies Adds support for implicit dependencies. There is a setter/getter and a method to resolve actual implicit dependencies. I centralized the code that resovles the bundles in a target/container against a set of matching criteria (ids, and optional versions). Updated the "set target platform" job to use the new implicit dependency info. NOTE: Curtis needs to add persistence/reading code for implicit dependencies.
Committed Darin's implicit dependency work and added persistence support for it.
Created attachment 122847 [details] Screenshot Target Editor Page 1
Created attachment 122848 [details] Screenshot Target Editor Page 2
Created attachment 122849 [details] Latest Editor Work I have attached two screenshots of the editor to give an idea what the new editor will look like.
Created attachment 122885 [details] Support for setting/getting workspace target platform Adds new preference for tracking the workspace target platform (handle). Operation is updated to set the preference (which can be null when no target is specified). Updated tests. Also added support to copy a target definition.
Created attachment 122887 [details] continued work on preference page Continued Chris's work on preference page. Coded duplicate and remove buttons as well as some of the "perform OK" code.
Applied Darin's patch for setting/getting workspace target platform.
Created attachment 123013 [details] More Editor Work Editor now has proper implicit plug-in support and supports the editing of bundle container restrictions.
Created attachment 123025 [details] support for old target files Fills out support for reading old target file format and adds tests. Updated "load target job" to properly enable all plug-ins in the target state.
Applied patch for old target files.
Created attachment 123285 [details] adds support for resolved/unresolved location in bundle containers Alows bundle containers to be persisted with variable locations (although they were created with variable locations before, they were persisted with resolved locations).
Committed Darin's patch for location variable resolution. The editor will be committed to CVS in the near future, but in a separate package. So the code for both editors will be available in M5.
Committed the majority of the editor work (new packages so the old code/editor is still available). To enable to editor add the following extension to the pde ui plugin.xml. Note that running both editors and switching between them may have dire consequences... <editor default="false" name="Target Editor 2" icon="$nl$/icons/obj16/target_profile_xml_obj.gif" class="org.eclipse.pde.internal.ui.editor.targetdefinition.TargetEditor" contributorClass="org.eclipse.pde.internal.ui.editor.targetdefinition.TargetEditorContributor" id="org.eclipse.pde.ui.targetEditor2"> <contentTypeBinding contentTypeId="org.eclipse.pde.targetFile"/> </editor>
Created attachment 123446 [details] preference page Updates to the new preference page. Needs more testing/NL work, but this gives an idea of where we are.
Put in a number of bug fixes and improvements. Fixed up the preference page and committed it. There are a few more UI issues to take care of before M5, but more important we need to get the PDEState interaction correct (we are finding problems on restarts, target weaving, producing a model from current settings, etc.)
Created attachment 123596 [details] creates initial targets
Fixed the tests and added them to the test suite. Added in support for the target provisioner extension point. Cleaned up some code and fixed some bugs. Added toString()s for common objects. Still have to NL the bundle container label provider and we have to finish the preference initialize on startup for M5.
Created attachment 123639 [details] preference migration/init and polish/fixes This patch: * Adds code to initialize the target platform definition handle - i.e. active target platform (when there are no target platforms in an empty workspace, or when there are existing target platforms in a workspace that has not used this support yet) * Adds brackets to version in bundle labels * Fixes bug in target provisioner to use plugins subdirectory * Properly creates woven target when creating a default target from the preference page wizard - use the target platform service to do this, which takes target weaving into account * Adds support for 'Restore Defaults' in pref page (re-selects or creates the default target platform) * Adds source bundles to the list/view in the content pane and restriction list. We need to do this to be compatible with the old target page (so you can de-select all bundles, etc, including source). Moving forward we can decide if we want to separate these. (But now we can support Dani's typical "disable the target platform scenario) * Sorting of bundles in content viewer
committed Darin's latest patch.
Trying some common workflows, one of the things our current preference page UI is failing to do is push people towards using target definition files. At the start of these changes it was noted that target definition files (in their previous state) were enough to solve the most common problems people had with the target platform. At a minimum, during M6 we will have to provide the ability to create the definition files from the preference page (or moving between workspace/metadata). Nothing came crashing down on me while using it. Was able to build and launch Eclipse apps as normal, even target weaving appeared to be working. Tried 3 different ways of creating Dani's workspace contained developement (de-select all on old preference page, edit the default target platform, and creating a new empty platform then importing from a directory). All three successfully built correctly. There are of course many UI limitations, hopefully we can correct most of them in M6. NL'd the label provider, had to add a fair number of comments to explain how to translate them. In M6 we will have to look at better ways of presenting the information to the user, as in the new target wizard there isn't enough room for a long string. I will test some more tomorrow, but we are looking good for M5.
I think existing function is sufficient for M5. But here are my thoughts on what we need to do moving forward: * isOptional - we don't currently support option bundles in target files. It turns out that the only way to specify them in the past was by generating .target files with the optional flag on bundles/features (since the UI did not provide a way to mark a plugin as optional). Looking at the old code, the only place this was used was to provide an error dialog to users. For example, if option plug-ins were missing when setting the target platform, there would be no error. We can still support this - I could imagine the bundle containers having "optional" bundles as well as "included" bundles (currently, we only have included bundles). However, I'm not sure we really need/want to support this in the UI, so perhaps we just need it in the model for backwards compatibility. * launcher args - i.e. the current preference to add the target's launcher args from the .ini file. We don't have this yet. We could make it a global preference or add it to the target model (it really is target specific... but is also a bit odd to have as part of the model). * source locations - we get source locations from the target the same as before. But our new UI does not have a source locations tab where the user can add extra locations. Moving forward, we need to decide how to present source in the target - should it be a seperate pane/tab, etc. Should the user be able to add additional source locations per target? * Exclude vs. Include. Target definition files have always supported an explicit set of bundles/featres to include. The target platform preference page supports an explicit set of bundles to *exclude*. This is subtle - since new bundles show up automatically in the workspace target platform. Our model supports explicit include... so not sure if this is a problem. It is more deterministic, but I'm not sure if it breaks any existing use cases. Polish/Ideas * Doc/Help (of course) * Should have a way to compare targets for level of equality - i.e. CONTENT_EQUAL (all the same, so saving not required), STATE_EQUIVALENT (i.e. same build state - so changing the target does not require a re-build), and EQUAL_IGNORE_NAME_DESCRIPTION (the same except for name/description)... useful in the pref page to know if anything really changed. * Should block the preference page while target load job is running * Should report when plug-ins are missing from included bundle list when resolving (i.e. failed resolution) - may beed a better API for resolution that includes a status or something * With an open target editor - if you change a target in the pref page - editor does not update (hmmmm....) * Browse dialogs (directory chooses) need to remember previous location * I wonder if *one* wizard page with tabs would better for editing (we have two right now). We could just make the "content" section into a "Plug-ins" tab, and put all the tabs on the first page. This would make it similar to the old pref page, and might reduce clicks. However, there may be other things we can do here as well. In general, when there are large numbers of bundles, the current UI is cumbersome (as was the old :-)
Created attachment 123770 [details] combines two pages into one This patch combines the two target content pages into a one page wizard. It moves the "content" group to a plug-ins tab. I think this will be less clicks/more familiar for users in M5.
Created attachment 123771 [details] fixes tests on Mac Classic == vs. equals(...) bug was causing failing tests on Mac
Added support for revert action.
Fixed implicit dependencies so the selection dialog uses the resolved bundles from the platform not from the running plugin registry. This has the side affect of removing a graphic disposed exception caused by the dialog disposing the pde shared label provider.
That's a whole lot of patches, great work from everyone. We are considering this bug fixed for M5. For future bugs and enhancements please open new reports. Bug 262668 will be used to collect some of the UI improvements that will be made in M6.
Also... Bug 260435 - Documentation for the new target platform story Bug 262910 - Remove the old preference page Bug 169340 - Allowing API access to load target platforms
*** Bug 186618 has been marked as a duplicate of this bug. ***
*** Bug 123532 has been marked as a duplicate of this bug. ***
*** Bug 224295 has been marked as a duplicate of this bug. ***
