Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "PDE/Ideas"

< PDE
(Target Management)
 
(19 intermediate revisions by 8 users not shown)
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
  
This page contains blue sky thinking about the kind of things we would like to see in PDE's future. This is a place to collect ideas - it does not represent a committment to implement the ideas.
+
This page contains blue sky thinking about the kind of things we would like to see in PDE's future. This is a place to collect ideas - it does not represent a commitment to implement the ideas.
  
== Target Management ==
+
== Runtime Use Cases ==
  
* Enhance target platform provisioning. Leverage p2 to create and configure profiles that can be used as target platforms, and leverage p2 to reflect on the contents of a profile. One could compose a target platform by installing features into a profile from p2 repositories.
+
There are multiple sticking points for groups building products rather than tooling. PDE provides many powerful tools, but there are gaps in workflows.
* Simplify and improve the user interface for defining and managing multiple targets in the workspace. Eventually, it would be nice to be able to support more than one target platform in the workspace (i.e. allow different projects to compile against different target platforms). Currently targets can be defined by target files or by the "target platform" user preference. Perhaps a preference page that allowed multiple targets to be defined (like the API Baselines or Installed JREs page) would be more intuitive. Creating/editing a target would open a wizard to modify that specific target, and a check box could be used to specify the "active" workspace target.
+
* Disconnect between PDE UI and PDE Build.  Most noticeable when exporting.  PDE Build provides all the functionality required, but using it requires a different skillset than working with the UI. To improve, PDE Build could use the same files and data structures as PDE UI, such as product files, target definitions, etc. The exporting and launch UI could also be improved to better take advantage of those files.
 +
* A more complete product editor. Products don't cover all features that are wanted and lack features of other editors.  For example, the product editor does not support simple management of features and plug-ins the way the launch config does.
  
== Source Management ==
+
== Target Management ==
  
* Simiplify the installation of source for debugging and developing against the target platform. For example, a user is debugging something and enters a class for which they have no source. There should be a simple way to install source for the associated bundle.
+
* Support a better reload button.  Provide a way to throw away p2 repository information.  Provide a way to clear out the bundle pool.
 +
* Fix issues with p2 UI usage in the target editor.  Currently editing p2 locations in the target can be a hassle as things are not selected correctly and filtering can remove the current selection.
 +
* Provide details/properties for the bundles in the target platform. Provide the location in the target it came from, its location on disk, etc.
 +
* Make the p2/metadata/profile information seamlessly integrate with target definitions, consider having targets where every plug-in has metadata (from repository, from installation, generated for a directory). Provide the metadata to the launcher.
 +
* Use the metadata stored in targets to simplify launching. Target launching should leverage Framework Admin, rather than hand-crafting a command line. This way, launching a target platform would be the same as running the executable in the file system.
 +
* Have the target definition models to interact with the PDE states directly rather than working through preference settings (this a required step to get to per-project target platforms).
  
 
== Building ==
 
== Building ==
  
* Improve the common self-hosting scenario of exporting a plug-in (bundle) and running with it. It would be nice to be able to build, export, and install a bundle (or set of bundles) into running SDK with the click of a button (or at least from within one wizard).
+
* Workspace based building. Currently, the build process is Ant based and does not leverage workspace builders or project specific settings. As the number of builders/settings grows a workspace based build would allow for simpler integration and better report generation with the build process. A challenge here is around bootstrapping a pure source build scenario.
* Workspace based building. Currently, the build process is Ant based and does not leverage workspace builders or project specific settings. As the number of builders/settings grows it is possible that a workspace based build would allow for simpler integration and better report generation with the build process. The challenge here is likely around bootstrapping a pure source build scenario.
+
* Parallel compilation in headless build
 +
* Post Launch Action - Once the Eclipse Application is launched, run a user supplied script (it could be SWTBot script or JRuby or anything that is hooked in using the supplied extension point).
 +
 
 +
== File Manipulation ==
 +
 
 +
* There have been several requests for APIs to manipulate bundle definition files - MANIFEST.MF, plugin.xml, and build.properties.
 +
* Provide ASTs for PDE documents: would make document creation / editing trivial. Would be nice to have something like this backing the PDE editors...
 +
 
 +
[[Category:PDE]]

Latest revision as of 16:05, 20 September 2010

Introduction

This page contains blue sky thinking about the kind of things we would like to see in PDE's future. This is a place to collect ideas - it does not represent a commitment to implement the ideas.

Runtime Use Cases

There are multiple sticking points for groups building products rather than tooling. PDE provides many powerful tools, but there are gaps in workflows.

  • Disconnect between PDE UI and PDE Build. Most noticeable when exporting. PDE Build provides all the functionality required, but using it requires a different skillset than working with the UI. To improve, PDE Build could use the same files and data structures as PDE UI, such as product files, target definitions, etc. The exporting and launch UI could also be improved to better take advantage of those files.
  • A more complete product editor. Products don't cover all features that are wanted and lack features of other editors. For example, the product editor does not support simple management of features and plug-ins the way the launch config does.

Target Management

  • Support a better reload button. Provide a way to throw away p2 repository information. Provide a way to clear out the bundle pool.
  • Fix issues with p2 UI usage in the target editor. Currently editing p2 locations in the target can be a hassle as things are not selected correctly and filtering can remove the current selection.
  • Provide details/properties for the bundles in the target platform. Provide the location in the target it came from, its location on disk, etc.
  • Make the p2/metadata/profile information seamlessly integrate with target definitions, consider having targets where every plug-in has metadata (from repository, from installation, generated for a directory). Provide the metadata to the launcher.
  • Use the metadata stored in targets to simplify launching. Target launching should leverage Framework Admin, rather than hand-crafting a command line. This way, launching a target platform would be the same as running the executable in the file system.
  • Have the target definition models to interact with the PDE states directly rather than working through preference settings (this a required step to get to per-project target platforms).

Building

  • Workspace based building. Currently, the build process is Ant based and does not leverage workspace builders or project specific settings. As the number of builders/settings grows a workspace based build would allow for simpler integration and better report generation with the build process. A challenge here is around bootstrapping a pure source build scenario.
  • Parallel compilation in headless build
  • Post Launch Action - Once the Eclipse Application is launched, run a user supplied script (it could be SWTBot script or JRuby or anything that is hooked in using the supplied extension point).

File Manipulation

  • There have been several requests for APIs to manipulate bundle definition files - MANIFEST.MF, plugin.xml, and build.properties.
  • Provide ASTs for PDE documents: would make document creation / editing trivial. Would be nice to have something like this backing the PDE editors...

Back to the top