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 "Equinox p2 1.0 Features"

(User Interaction)
 
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Tooling ==
+
This page was used as part of the planning process for creating the p2 1.0 release (part of the [[Galileo]] simultaneous release). The specific features listed here may or may not be present in any particular version of p2.  Readers interested in additional ''under the covers''  details should see the [[Equinox p2 1.0 Technical Specs | technical specs]] page.
; '''Generation of p2 sites at build time'''
+
: The build mechanism allows to produce metadata repositories and artifact repositories as part of the build. Priority: 2
+
; '''Generation of p2 enabled products at build time'''
+
: The build mechanism allows the production of all the p2 related "artifacts" (install registry, profile, …) as part of the build when RCP apps are being built. This will allow for the application created to be p2 provisionable.
+
; '''Ant task to produce repositories'''
+
: N/A Priority: 1
+
;'''Ant task to provision products'''
+
: N/A Priority: 1
+
; '''Streamlined p2 selfhosting'''
+
: This is the ability to test the deployment of Installable Units without having to go through a full export cycle. Priority: 2
+
; '''Provision the target'''
+
: This allows to provision Installable Units directly in the target by going through a full provisioning experience. Priority: 3
+
; '''Repository browser'''
+
: Offer the ability to browse the content of a metadata or artifact repository. Priority: 2
+
; '''Repository editor'''
+
: Offer the ability to edit the content of a repository: publish / remove. Priority: 2
+
  
 
== User Interaction ==
 
== User Interaction ==
; '''Automatic download before installation'''
+
; '''Managing other profiles'''
: When an update is being detected, the download happens in the background and the user is only prompted to install once the download is complete.  Priority: 1
+
: p2 inherently supports the management of profiles other than the one currently running the p2 infrastructure.  Priority: 1
; '''Browser integration'''
+
: Clicking on a link in a browser should cause the installation of the IUs in eclipse.  Priority: 2
+
; '''Remembered licenses'''
+
: The dialog presenting licenses gives the ability to the user to accept a license forever. The remembered licenses can be revoked through a preference page. Revoking a license will not cause the uninstallation of the software.  Priority: 1
+
; '''Silent updates'''
+
: The user should have the ability to have all updates happen completely transparently and just be prompted for restart.  Priority: 1
+
; '''Headless installation'''
+
: Complete installation can be performed without a UI. Certain installation will require the usage of a response file. Priority: 2
+
 
; '''Drag and drop installation'''
 
; '''Drag and drop installation'''
: The user could install Installable Units by drag and drop an archive on the window of a running Eclipse.  Priority: 1
+
: Users can install new function by dragging and dropping the related files (JARs, directories, zips, ...) on a running Eclipse.  Priority: 2
 +
; '''Browser-based installation'''
 +
: Installation of new function can be triggered by users clicking on a link in a browser.  Priority: 3
 
; '''Directory monitoring'''
 
; '''Directory monitoring'''
: In order to improve the management of plug-ins, the user could install Installable Units by drag and drop an archive on the window of a running Eclipse. Several mode of installation could be supported: direct call to BundleContext.installBundle(), FwkAdmin.installBundle(), Director.install().  Priority: 1
+
: Users can designate any number of directories to be watched. When installable elements (e.g., bundle JARs and directories) are copied into or remove from watched directories, their contents are installed or uninstalled (respectively).  Priority: 1
 +
; '''Update scheduling and policies'''
 +
: p2 supports a number of update policies allowing users to, for example, set update polling periods, schedule updates and have detected updates automatically downloaded.  Priority: 1
 +
; '''Headless operation'''
 +
: All p2 function is accessible through command-line or programmatic interfaces.  Complete installation operations can be performed without a graphical user interface.  Some operations support the use of response files to silently provide input. Priority: 2
 
; '''Remembered signers'''
 
; '''Remembered signers'''
: The dialog presenting signatures should give the ability to trust this signer forever. The remembered signers can be revoked through a preference page. Revoking a license will not cause the uninstallation of the software. Priority: 1
+
: Users are able to accept signer certificates and not be asked each time such ''remembered'' certificates are encountered. The set of remembered certificates is managed through a preference page that allows for certificates to be added and removed. Priority: 2
 +
; '''Integrated user prompting'''
 +
: Prompts for security information (e.g., login, certificate trust, ...) are consistent and well-integrated into the user workflow. Priority: 2
 +
; '''Internationalization'''
 +
: p2 will provide an internationalized installation experience. Priority 1.
  
== Download technology ==
+
==Download technology==
; '''Automatic detection of proxy / socks from the OS / Browser'''
+
; '''Automatic detection of proxy/socks settings from the OS/Browser'''
: Proxies and socks settings available in the OS should be detected and automatically set in Eclipse. Priority: 2
+
: p2 uses the standard Eclipse proxy and socks settings management system and integrates such settings from the OS and browsers. Priority: 2
; '''Automatic selection of mirrors'''
+
; '''Adaptive downloads and mirror selection'''
: When mirrors are available, the best mirror is always being picked. Priority: 1
+
: p2 dynamically adapts its artifact download strategy based the characteristics of the servers available, the connection speeds and the system being provisioned. Retries are automatically attempted and mirrors re-selected depending on failures.  Priority: 1
; '''Adaptative downloads'''
+
; '''Download integrity through MD5/SHA1 and signature verification'''
: The download will adapt on the characteristic of the connection, servers and other criterias (parallel download, choice of what is being downloaded (delta, pack200, …), etc.).  Priority: 1
+
: The integrity of downloaded artifacts can be verified using MD5/SHA1 hashing algorithms and/or signature verification.  Priority: 1
; '''Download integrity through MD5 / SHA1'''
+
; '''Integrated compression technologies'''
: The integrity of the artifacts downloaded will be verified using either MD5 / SHA1 algorithms.  Priority: 1
+
: p2 allows artifact repositories to maintain artifacts in a variety of formats (e.g.,  compressed using pack200, JAR and binary deltas relative to previous versions, etc.).  This can dramatically reduce the bandwidth requirements for new software installations. Priority: 1
; '''Delta-ing'''
+
; '''Peer-to-peer downloads'''
: Ability to publish deltas of an artifact instead of full artifacts. Priority: 1
+
: Since all downloads in p2 are based on a mirroring metaphor, artifacts and metadata can come from repositories on central servers or peer machines on a local network. Priority 2
 
; '''Transparent restart'''
 
; '''Transparent restart'''
: After the abortion of an installation, artifacts that have been fully downloaded will not be downloaded again (unless a GC happened) and the downloads of partially downloaded artifacts will be picked up where it left.  Priority: 2
+
: Aborted installations and downloads can be restarted without refetching.  Priority: 1
; '''Secure transport (https, …)'''
+
: Support secure connection to http.  Priority: 1
+
; '''Automatic retries'''
+
: When an artifact can not be found in a given repository retries will be done and in case of repeated failures another mirror will be picked if available.  Priority: 1
+
 
; '''Download time estimation'''
 
; '''Download time estimation'''
 
: Estimation of the download time as the download progresses.  Priority: 2
 
: Estimation of the download time as the download progresses.  Priority: 2
; '''Jar signature check'''
+
; '''Repository seeding'''
: Signed jars being downloaded will be verified.  Priority: 1
+
: Repositories are able to reference other repositories and thus inform p2 of additional sources of artifacts and metadata.  Priority: 1
; '''Pack200'''
+
; '''Media support'''
: Support to download pack200'd artifacts to cut the download size.  Priority: 1
+
: p2 supports and properly manages the interaction with repositories stored on removable and ''volume-oriented'' media such as CDs, DVDs.  Priority: 1
; '''Trusted repositories'''
+
: p2 should have the ability to identify trusted repositories against others. The trust could be done through an exchange of keys.  Priority: 2
+
; '''Support for proxy / socks connection'''
+
: p2 transports will honour proxy and socks settings.  Priority: 1
+
; '''Referencing additional repositories (mirror or supplement)'''
+
: Repositories will be able to reference additional repositories, such that the addition of the first one to the system could cause the additional ones.  Priority: 1
+
; '''Support for login into repositories'''
+
: p2 will honour servers requesting authentication.  Priority: 1
+
; '''Media support (CDs)'''
+
: p2 will allow repositories to be stored on medias such as CDs, DVDs.  Priority: 1
+
  
 
==Security ==
 
==Security ==
; '''IU signature'''
+
; '''Metadata signing'''
: IUs carry a signature to ensure their content has not been tempered with.  Priority: 3
+
: Metadata is signed to ensure content integrity.  Priority: 3
; '''Support for login into repositories'''
+
; '''Secure transports (https, ...)'''
: p2 will honour servers requesting authentication.  Priority: 1
+
: Secure transports such as https are supported.  Priority: 1
; '''Trusted repositories'''
+
; '''Repository trust'''
: p2 should have the ability to identify trusted repositories against others. The trust could be done through an exchange of keys.  Priority: 1
+
: p2 has the ability to identify repositories as trusted or untrusted as well as white and black lists of domains housing repositories.  Priority: 2
; '''Secure transport (https, …)'''
+
; '''Repository authentication'''
: Support secure connection to http.  Priority: 1
+
: p2 supports a variety of mechanisms for authenticating to servers.  Priority: 2
; '''Jar signature check'''
+
; '''JAR signature verification'''
: Signed jars being downloaded will be verified.  Priority: 1
+
: Signed JARs downloaded from untrusted repositories are verified to establish trust.  Priority: 1
; '''Trusted repositories'''
+
: p2 should have the ability to identify trusted repositories against others. The trust could be done through an exchange of keys.  Priority: 2
+
  
== Core technologies ==
+
== Core facilities ==
 
+
; '''Generic Metadata'''
; '''Permission based control of provisioning operation'''
+
: Underlying p2 is a generic metadata model of ''Installable Units''.  p2 metadata captures dependencies on non-Eclipse/OSGi based elements (e.g., JREs, native code, other applications, ...) as well as on physical elements of the machine (e.g., number of CPUs, amount of memory or drive space).  Priority: 1
: When a provisioning operation is performed, permissions will be checked to ensure that it is acceptable to do it in the given context.  Priority: 1
+
; '''Shared (multi-user) installs'''
; '''General model of dependencies'''
+
: Scenarios where Eclipse installs are shared across multiple users is streamlined.  Priority: 1
: Installable Units will be able to express dependencies on things other than other Installable Units (e.g. memory available on the machine, etc.).  Priority: 1
+
; '''Bundle pooling'''
; '''Shared installs'''
+
: p2 ''pools'' the set of bundles installed across the profiles it manages such that any given bundle appears only once on disk. This saves disk space as well as dramatically speeding subsequent installation operations.  Priority: 1
: Scenarios where the installation of eclipse is shared across multiple users is streamlined.  Priority: 1
+
; '''Sharing of bundles across systems'''
+
: Multiple eclipse instances share the bundle jars in one common location (aka bundle pool), thus making the installation faster and the required disk footprint smaller.  Priority: 1
+
 
; '''Garbage collection of unused bundles'''
 
; '''Garbage collection of unused bundles'''
: Bundles being shared across multiple instances of eclipse will be garbage collected when they are no longer in use. A retention policy will be applied.  Priority: 1
+
: Bundles no longer used in any managed profiles are garbage collected according to a flexible policy.  Priority: 1
; '''Create new installs without re-downloading all the artifacts'''
+
: p2 is able to create a brand new install of a product already installed with minimal or no download depending on the retention policy of the garbage collector.  Priority: 1
+
 
; '''Resilience to install problems'''
 
; '''Resilience to install problems'''
: p2 provides a best effort approach to ensure that failed installations do not leave the system in an inconsistent state.  Priority: 1
+
: p2 provides a best effort approach to ensure that failed installations do not leave the system in an inconsistent state.  This includes a ''safe mode'' for the provisioning infrastructure itself.  Priority: 1
; '''OS integration'''
+
; '''Fix delivery'''
: p2 provides support for a tighter desktop integration.  Priority: 2
+
: Fixes to existing installed function can be installed and uninstalled without ''updating'' the base function.  Priority: 1
; '''Support to deliver fixes'''
+
; '''Sequenced provisioning'''
: Support to deliver fixes.  Priority: 1
+
: Users and developers can mandate that various update and install operations must be executed prior to attempting subsequent operations.  Priority: 2
; '''Sequenced udpate'''
+
; '''Staged provisioning'''
: Allows to express that one particular update has to applied on the path to another one.  Priority: 2
+
: Provisioning operations can be staged such that all required artifacts are downloaded and then, at some later time, the actual installation and configuration executed.  Priority: 2
; '''Fine grain installation of IUs'''
+
; '''Fine grain installation'''
: Allow for the installation of Groups as well as single IUs.  Priority: 2
+
: p2 supports the installation of individual Installable Units as well as groups of Installable UnitsSince typically one IU represents one bundle, p2 allows for the installation of individual bundles.  Priority: 1
; '''Install in a non running system'''
+
; '''Dynamic dependency discovery'''
: Allow to install IUs into an Eclipse that is not running.  Priority: 1
+
: When p2 is asked to install an IU it can optionally attempt to satisfy all prerequisites by discovering and installing other IUs that supply the required capabilities. Priority: 2
; '''Installability of another state'''
+
; '''Managing non-running systems'''
: Previous states of the system are being kept to allow for recreation of a setup used in the past. It could allow for installing somebody else state. Priority: 1
+
: p2 is able to manage Eclipse profiles even when the profile is not active/running.  Priority: 1
 +
; '''Managing running systems'''
 +
: p2 is able to manage and properly interact with running Eclipse profiles.  For example, triggering restarts of the remove system as needed.  Priority: 2
 +
; '''Rollback'''
 +
: Users can restore previous states of a profile. Priority: 1
 +
; '''Profile interchange'''
 +
: Profiles can be manipulated and exchanged between users.  This allows previous setups to be stored and recreated and for users to exchange profiles. Priority: 3
 
; '''Revert to the previous install'''
 
; '''Revert to the previous install'''
: When an installation has succeeded but the result is not satisfactory it should be possible to revert the system to the "exact" same state as it was before.
+
: When an installation succeeds but is not satisfactory, users can revert the system to the ''exact'' same state as it was before.  Priority: 3
 +
; '''OS integration'''
 +
: Applications installed using p2 can be tightly integrated with the underlying operating system.  For example, desktop shortcuts, registry entries, etc. can be deployed as part of the installation.  Priority: 2
 +
; '''Governor'''
 +
: The governor represents an authority allowing or vetoing provisioning operations. Priority 2.
  
 
== UM Compatibility ==
 
== UM Compatibility ==
  
; '''Content of 3.3 styles update site will be installable without change'''
+
; '''Update site integration'''
: Update site created with former versions of eclipse will be installable
+
: p2 is able to read existing update sites created for use with Update Manager.  Indexing and conversion tools are provided for optimizing the use of such sites. Priority: 1
 +
; '''Feature compatibility'''
 +
: The feature data structure is not part of the p2 infrastructure but p2 allows Update Manager Features to be published to metadata and artifact repositories.  Priority: 1
 +
; '''Feature Install Handlers'''
 +
: Feature install handlers continue to work in p2 with some restrictions.  A migration/porting guide helps developers in moving to the new infrastructure.  Priority: 1
 +
; '''Links directory'''
 +
: p2 includes tooling to publish existing Eclipse installs into metadata and artifact repositories.  This includes the correct traversal of ''links'' directories.  Priority: 1
 +
 
 +
== Tooling ==
 +
; '''Generation of p2 repositories at build time'''
 +
: The PDE build mechanism produces metadata and artifact repositories as part of the normal build. Priority: 2
 +
; '''Generation of p2 enabled products at build time'''
 +
: The PDE build mechanism produces all of the p2 related artifacts and metadata (e.g., install registry, profile, ...) when RCP apps are being built. This allows applications deployed as zips to be p2 enabled out of the box.
 +
 
 +
; '''Streamlined p2 self-hosting'''
 +
: PDE incrementally and continuously produces p2 metadata and artifact information based on the contents of the workspace and target platform.  This simplifies the development of p2-enabled applications by eliminating the need for time-consuming ''deployment'' and export cycles while testing and allowing developers to install bundles directly from their workspace without exporting or deploying.  Priority: 2
 +
; '''Provisioning the target'''
 +
: PDE's Target Provisioner mechanism has been extended to allow the use of p2 when adding bundles to the target platform.  This allows bundle developers to benefit from all facilities in p2 when managing their targets.  Priority: 2
 +
; '''Repository browsers and editors'''
 +
: p2 tooling includes browsers and editors for the artifact and metadata repositories.  Users can view, add and remove elements from local and remote p2 repositories.  Priority: 1
 +
; '''Migration tools'''
 +
: Developers can deploy existing features and Eclipse product configurations into p2 repositories using p2 Publisher tools that automatically transform runtime and Update Manager markup into p2 data structures and add this data and artifacts to the relevant repositories.  Priority: 1
 +
; '''Repository Optimizers'''
 +
: p2 includes tools that analyze, transform and optimize the artifacts in an artifact repository to improve download time, enhance security, etc.  Priority: 1
 +
;'''Mirroring tools'''
 +
: Artifact and metadata repositories can be duplicated in whole or in part using a set of tools included in p2.  Priority: 1
 +
; '''Metadata Authoring'''
 +
: p2 tooling will offer the ability to author installable units. Priority 3.
 +
 
 +
[[Category:Equinox p2|Feature list]]

Latest revision as of 11:34, 5 April 2010

This page was used as part of the planning process for creating the p2 1.0 release (part of the Galileo simultaneous release). The specific features listed here may or may not be present in any particular version of p2. Readers interested in additional under the covers details should see the technical specs page.

User Interaction

Managing other profiles
p2 inherently supports the management of profiles other than the one currently running the p2 infrastructure. Priority: 1
Drag and drop installation
Users can install new function by dragging and dropping the related files (JARs, directories, zips, ...) on a running Eclipse. Priority: 2
Browser-based installation
Installation of new function can be triggered by users clicking on a link in a browser. Priority: 3
Directory monitoring
Users can designate any number of directories to be watched. When installable elements (e.g., bundle JARs and directories) are copied into or remove from watched directories, their contents are installed or uninstalled (respectively). Priority: 1
Update scheduling and policies
p2 supports a number of update policies allowing users to, for example, set update polling periods, schedule updates and have detected updates automatically downloaded. Priority: 1
Headless operation
All p2 function is accessible through command-line or programmatic interfaces. Complete installation operations can be performed without a graphical user interface. Some operations support the use of response files to silently provide input. Priority: 2
Remembered signers
Users are able to accept signer certificates and not be asked each time such remembered certificates are encountered. The set of remembered certificates is managed through a preference page that allows for certificates to be added and removed. Priority: 2
Integrated user prompting
Prompts for security information (e.g., login, certificate trust, ...) are consistent and well-integrated into the user workflow. Priority: 2
Internationalization
p2 will provide an internationalized installation experience. Priority 1.

Download technology

Automatic detection of proxy/socks settings from the OS/Browser
p2 uses the standard Eclipse proxy and socks settings management system and integrates such settings from the OS and browsers. Priority: 2
Adaptive downloads and mirror selection
p2 dynamically adapts its artifact download strategy based the characteristics of the servers available, the connection speeds and the system being provisioned. Retries are automatically attempted and mirrors re-selected depending on failures. Priority: 1
Download integrity through MD5/SHA1 and signature verification
The integrity of downloaded artifacts can be verified using MD5/SHA1 hashing algorithms and/or signature verification. Priority: 1
Integrated compression technologies
p2 allows artifact repositories to maintain artifacts in a variety of formats (e.g., compressed using pack200, JAR and binary deltas relative to previous versions, etc.). This can dramatically reduce the bandwidth requirements for new software installations. Priority: 1
Peer-to-peer downloads
Since all downloads in p2 are based on a mirroring metaphor, artifacts and metadata can come from repositories on central servers or peer machines on a local network. Priority 2
Transparent restart
Aborted installations and downloads can be restarted without refetching. Priority: 1
Download time estimation
Estimation of the download time as the download progresses. Priority: 2
Repository seeding
Repositories are able to reference other repositories and thus inform p2 of additional sources of artifacts and metadata. Priority: 1
Media support
p2 supports and properly manages the interaction with repositories stored on removable and volume-oriented media such as CDs, DVDs. Priority: 1

Security

Metadata signing
Metadata is signed to ensure content integrity. Priority: 3
Secure transports (https, ...)
Secure transports such as https are supported. Priority: 1
Repository trust
p2 has the ability to identify repositories as trusted or untrusted as well as white and black lists of domains housing repositories. Priority: 2
Repository authentication
p2 supports a variety of mechanisms for authenticating to servers. Priority: 2
JAR signature verification
Signed JARs downloaded from untrusted repositories are verified to establish trust. Priority: 1

Core facilities

Generic Metadata
Underlying p2 is a generic metadata model of Installable Units. p2 metadata captures dependencies on non-Eclipse/OSGi based elements (e.g., JREs, native code, other applications, ...) as well as on physical elements of the machine (e.g., number of CPUs, amount of memory or drive space). Priority: 1
Shared (multi-user) installs
Scenarios where Eclipse installs are shared across multiple users is streamlined. Priority: 1
Bundle pooling
p2 pools the set of bundles installed across the profiles it manages such that any given bundle appears only once on disk. This saves disk space as well as dramatically speeding subsequent installation operations. Priority: 1
Garbage collection of unused bundles
Bundles no longer used in any managed profiles are garbage collected according to a flexible policy. Priority: 1
Resilience to install problems
p2 provides a best effort approach to ensure that failed installations do not leave the system in an inconsistent state. This includes a safe mode for the provisioning infrastructure itself. Priority: 1
Fix delivery
Fixes to existing installed function can be installed and uninstalled without updating the base function. Priority: 1
Sequenced provisioning
Users and developers can mandate that various update and install operations must be executed prior to attempting subsequent operations. Priority: 2
Staged provisioning
Provisioning operations can be staged such that all required artifacts are downloaded and then, at some later time, the actual installation and configuration executed. Priority: 2
Fine grain installation
p2 supports the installation of individual Installable Units as well as groups of Installable Units. Since typically one IU represents one bundle, p2 allows for the installation of individual bundles. Priority: 1
Dynamic dependency discovery
When p2 is asked to install an IU it can optionally attempt to satisfy all prerequisites by discovering and installing other IUs that supply the required capabilities. Priority: 2
Managing non-running systems
p2 is able to manage Eclipse profiles even when the profile is not active/running. Priority: 1
Managing running systems
p2 is able to manage and properly interact with running Eclipse profiles. For example, triggering restarts of the remove system as needed. Priority: 2
Rollback
Users can restore previous states of a profile. Priority: 1
Profile interchange
Profiles can be manipulated and exchanged between users. This allows previous setups to be stored and recreated and for users to exchange profiles. Priority: 3
Revert to the previous install
When an installation succeeds but is not satisfactory, users can revert the system to the exact same state as it was before. Priority: 3
OS integration
Applications installed using p2 can be tightly integrated with the underlying operating system. For example, desktop shortcuts, registry entries, etc. can be deployed as part of the installation. Priority: 2
Governor
The governor represents an authority allowing or vetoing provisioning operations. Priority 2.

UM Compatibility

Update site integration
p2 is able to read existing update sites created for use with Update Manager. Indexing and conversion tools are provided for optimizing the use of such sites. Priority: 1
Feature compatibility
The feature data structure is not part of the p2 infrastructure but p2 allows Update Manager Features to be published to metadata and artifact repositories. Priority: 1
Feature Install Handlers
Feature install handlers continue to work in p2 with some restrictions. A migration/porting guide helps developers in moving to the new infrastructure. Priority: 1
Links directory
p2 includes tooling to publish existing Eclipse installs into metadata and artifact repositories. This includes the correct traversal of links directories. Priority: 1

Tooling

Generation of p2 repositories at build time
The PDE build mechanism produces metadata and artifact repositories as part of the normal build. Priority: 2
Generation of p2 enabled products at build time
The PDE build mechanism produces all of the p2 related artifacts and metadata (e.g., install registry, profile, ...) when RCP apps are being built. This allows applications deployed as zips to be p2 enabled out of the box.
Streamlined p2 self-hosting
PDE incrementally and continuously produces p2 metadata and artifact information based on the contents of the workspace and target platform. This simplifies the development of p2-enabled applications by eliminating the need for time-consuming deployment and export cycles while testing and allowing developers to install bundles directly from their workspace without exporting or deploying. Priority: 2
Provisioning the target
PDE's Target Provisioner mechanism has been extended to allow the use of p2 when adding bundles to the target platform. This allows bundle developers to benefit from all facilities in p2 when managing their targets. Priority: 2
Repository browsers and editors
p2 tooling includes browsers and editors for the artifact and metadata repositories. Users can view, add and remove elements from local and remote p2 repositories. Priority: 1
Migration tools
Developers can deploy existing features and Eclipse product configurations into p2 repositories using p2 Publisher tools that automatically transform runtime and Update Manager markup into p2 data structures and add this data and artifacts to the relevant repositories. Priority: 1
Repository Optimizers
p2 includes tools that analyze, transform and optimize the artifacts in an artifact repository to improve download time, enhance security, etc. Priority: 1
Mirroring tools
Artifact and metadata repositories can be duplicated in whole or in part using a set of tools included in p2. Priority: 1
Metadata Authoring
p2 tooling will offer the ability to author installable units. Priority 3.

Back to the top