Skip to main content
Jump to: navigation, search

Difference between revisions of "PDE/Ideas"

< PDE
(→‎Authoring)
Line 5: Line 5:
 
== Target Management ==
 
== Target Management ==
  
−
* 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.
+
* 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.
−
* 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.
+
* 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.
−
** This is one area where I hope that PDE and WTP can collaborate. I would argue that at base level the requirements for PDE target management and WTP "server runtime targeting" features are very similar. It would be nice if both can use the same high-level API and UI. This becomes particularly interesting when you consider OSGi-based servers where the end users would likely need to use both WTP and PDE. There is some code in WTP right now that implements such high-level API and UI. It is already fairly generic, but it can be re-factored and modified to suit our combined requirements and placed somewhere commonly accessible. [konstantin.komissarchik@oracle.com]
+
* 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).
−
* 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.
+
−
* Improve plug-in import.  Determine when plug-in import is useful and whether it can be done better.  Needs better integration with the target platform.  Should source bundles be imported?
+
−
 
+
−
== Source Management ==
+
−
 
+
−
* Simplify 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.
+
−
* Clean up source bundles in the UI.  Source bundles are not installed into the runtime and their role in the target platform is not clearly defined, so they appear in many lists of bundles.  In some cases filtering may be satisfactory.
+
−
* Provide an easy way to generate source bundles when exporting plug-ins/features.
+
  
 
== 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 the running SDK with the click of a button (or at least from within one wizard). It should also be easy to generate and install the latest associated source bundles.
 
 
* 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 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
 
* Parallel compilation in headless build
−
 
−
== Authoring ==
 
−
 
−
* Enhance authoring tools for p2. Traditionally Eclipse has been feature based. Moving forward we need to decide if features still make sense, or if we should encourage the use of installable units. One could imagine tools to author, export/build, and publish installable units. Some incubating stuff is available in the [[Equinox p2 Metadata Authoring]] page.
 
−
* Declarative Services authoring and tools
 
  
 
== File Manipulation ==
 
== File Manipulation ==
Line 32: Line 18:
 
* There have been several requests for APIs to manipulate bundle definition files - MANIFEST.MF, plugin.xml, and build.properties.
 
* 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...
 
* Provide ASTs for PDE documents: would make document creation / editing trivial. Would be nice to have something like this backing the PDE editors...
−
 
−
== API Tooling ==
 
−
 
−
* Enhance API analysis to avoid false positives. Leak detection can be improved to not report problems when an internal superclass does not expose any visible members. Some API use problems should not be reported for bundles that are friends - for example, a bundle that is a friend should be able to implement restricted interfaces from its friend.
 
−
* Allow a public visibile type to be restricted for 'internal/private' use only. This allows classes that need to be visible for implementation purposes to be effectively private.
 
−
* Support API analysis for pure Java projects (not just plug-ins).
 
−
* Seek performance improvements - perhaps by integrating with the Java builder as a compilation participant, and implementing an MRU cache of API descriptions.
 
−
* Support edit time analysis similar to the Java editor. This would flag API problems as the user types without having to save/build.
 
−
* Analyze extension points and extensions for compatibility.
 
−
* Analyze prerequisite bundles for version range compatibility. The analysis would determine if all references to a prerequiste bundle are satisfied by a particular version of that bundle - or which versions of a prerequisite bundle are API compatible. NOTE: this would not guarantee runtime behavior to be correct.
 
−
* Support searching an API baseline (existing product) for references/use of an API or internal code.
 
−
* Support for package versioning.
 
−
* Analyze JRE/system library references for illegal use based on bundle required execution environment. For example, if a bundle claims to run on J2SE-1.4, there should be no references to methods introduced in J2SE-1.5.
 
−
* Create scanning abstraction layer: separate scanning source kind from tooling. I.e. the tooling should not care whether the 'source' to be scanned is binary (class files, etc) or pure source.
 
−
* Test coverage for all aspects of the builder (currently there is only coverage for unsupported tag usage)
 
−
* Better handling of preferences and how they drive the different parts of the tooling. For example, setting the preferences to say 'only find binary compatibility problems for classes', should not scan for any other type of problem.
 
−
* Consider making the delta scanning pluggable, where each section for compatibility scanning is a participant (goes along with the point above about preferences driving the work that is done).
 
−
* More reusable ant tasks for reporting (provide more tangible benefits to the tooling).
 

Revision as of 12:22, 3 June 2009

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.

Target Management

  • 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

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...
Retrieved from "https://wiki.eclipse.org/index.php?title=PDE/Ideas&oldid=156653"

Back to the top