Skip to main content
Jump to: navigation, search

Difference between revisions of "Equinox p2 Meeting Week Jan 14-18 2008"

(Metadata)
(Metadata)
Line 135: Line 135:
 
* Metadata structure for an eclipse application
 
* Metadata structure for an eclipse application
 
** product vs extension.
 
** product vs extension.
** Description of a "base" (to support firefox like model and allow the uninstallation of everything) and its UI terminology
+
** Description of a "base" (to support firefox like model and allow the uninstallation of everything)  
 +
** UI issues
 +
*** differentiation of a "base" vs. the rest in installed features?
 +
*** what do we call a root?  (feature is not a good name)
 +
*** deciding what to show to user (is a bundle dropped in to Eclipse marked as a group?)
 
* shape of new items:
 
* shape of new items:
 
** update
 
** update
Line 141: Line 145:
 
** translation
 
** translation
 
** flavor
 
** flavor
* metadata generated for drop-ins
 
** is a bundle dropped in a group?  (it must be seen in available features)
 
  
 
== Wednesday ==
 
== Wednesday ==

Revision as of 15:34, 15 January 2008

A number of meetings will be held the week of Jan 14 - 18, 2008 to make DECISIONS about the content of the release. All times listed are in Eastern Standard Time

Participants and times they cannot attend:

  • Dave Stevenson - Tues 11-12:30 EST; Wed 2-3
  • Pascal Rapicault - Tues 8h - 12h EST
  • John Arthorne Wed 2:30-6
  • Scott Lewis - Wed 11am-2pm PT (2pm-5pm EST)

Schedule of topics and meetings

Monday

Update manager compatibility

When: Monday 1:30-2:30

Who: Simon, DJ, Dave S, John, Pascal

What:

  • where are we?
  • what are we missing?
  • links folder, extensions folder, policy files
  • install handlers

Tooling

When: Tuesday 2:30-4:30

Who: Darin, Susan, John, Pascal

What:

  • UI Workflows
  • Change to pde ui code
  • Relation PDE / update
  • p2 target provisioner
  • Feature selfhosting replacement
  • Do we keep features
  • editor work

Minutes:

  • Authoring tooling
    • Editors
      • Need to maintain editors for old stuff: update sites, features, etc
      • Do we need an editor for authoring IUs directly? No. People will continue to author features, etc, and we will generate the p2 metadata behind the scenes.
      • Not clear what changes are needed in product editor. Perhaps a flag/checkbox to specify whether p2 or UM is being used. Also a way to set the start level of bundles.
    • Repositories
    • Should we have tooling in PDE for browsing/publishing to remote repositories? No.
  • Publishing
    • Nice to have, but probably not for 1.0
  • Target provisioner
    • Currently there can only be one active target platform. Would like to evolve to support multiple active target platforms
    • We will add a p2 target provisioner that can take things from a p2 repository, and fetch the IUs selected by the user.
  • Launch tooling
  • Compatibility
  • Build
    • Need to be able to publish/export in either new format or old format
  • Suppose I deploy an application that is entirely "new school". It contains no features, only IUs. Someone wants to author a feature that depends on a group in this new school application. How can the user specify this dependency in the feature editor? Currently this is broken in a p2-provisioned Eclipse SDK.

Shape of eclipse

When: Monday 4:30-

Who: Jeff, Susan, Simon, DJ, Andrew N, John, Pascal

What:

  • We will keep the old all-in-one zip downloads. No configuration: unzip and run.
  • We will continue to ship the same feature.xmls for the SDK
    • Zip layout is same as Eclipse 3.3, plus p2 stuff:
- eclipse/
 - eclipse.exe
 - plugins/
 - features/
 - p2/
  • Is all the p2 metadata pre-configured or generated on first startup?
    • bundles.txt, profile/install registry, bundle pool
    • Easiest solution is that nothing gets automatically spoofed up on startup. Packagers/builders must invoke the "p2-izer" to prepare their zips
  • installer
  • how many agents
  • p2-ization, when, what for, what from
  • Handling of multiple installation
  • Support for Vista

Tuesday

User interaction scenarios

When: Tuesday 9:30-12:00

Who: Susan, Tim M, John, Jeff, DJ, Simon

What:

  • Support for drag & drop install <Susan>
  • Do we keep the dropins folder concept <Susan>
  • Do we keep the UI to add extension locations? <Susan>
  • UI for drop-ins folder? <Susan>
    • These are all related. Compelling use case: user got a jar from somewhere and wants to add to system
    • Drag a zip/jar/URL/dir to available features list
    • if drag source is a bundle, it goes to drop-ins folder, otherwise we are either:
      • adding a repo (make metadata for this zip file and consider it a repo)
      • adding content to the default drop-ins folder
    • Drag a zip/jar/URL to installed features list - does above + install
    • Repo properties control how often repo content is refreshed, are things automatically installed
    • There is a default drop-in location but user can add more via these add repo scenarios
    • Need to think about whether removing a repo ever automatically uninstalls everything that was in it if "install

automatically" was on. (Equivalent to remove extension location.)

  • Prompting for trusted signers, relationship to licenses <Tim>
    • Licenses is done and always happens as part of the install UI (because licenses known up front)
    • Trust is verified during/after collect phase. Prompting happens in different places
      • If user pre-downloaded due to autoupdates, then trust should be shown along with licenses in update wizard
      • If user has already been in an install/update wizard and then does the download, the UI happens after
      • John and Tim will work out details
  • Do we keep the old ui? <Susan>
    • We need to because we can't handle all of the old update sites
    • We need to run in an either/or/both mode, default is p2 UI is on
    • How to handle both of them making UI contributions. Update UI would still contribute to menu and probably hide its menu contributions in code somewhere if it finds that p2 is installed.
  • Verify that all the update manager functionalities are covered in p2 <Susan>
    • The various history and activity logs will be presented as needed in revert UI
    • We think we are covered
  • Do we want to keep the disable functionality, how do we implement it?
    • We will not do it for 3.4/1.0

Metadata

When: Tuesday 2-4

Who: Dave, John, Pascal, Jeff, Susan

What:

  • Metadata structure for an eclipse application
    • product vs extension.
    • Description of a "base" (to support firefox like model and allow the uninstallation of everything)
    • UI issues
      • differentiation of a "base" vs. the rest in installed features?
      • what do we call a root? (feature is not a good name)
      • deciding what to show to user (is a bundle dropped in to Eclipse marked as a group?)
  • shape of new items:
    • update
    • fix pack
    • translation
    • flavor

Wednesday

Shared installs

When: Wednesday 9:30-10:30

Who: Andrew O, Pascal

What:


Ganymede, EPP

When: 10:30-12

Who: Jeff, Thomas H, John, Pascal, Andrew O

What:

  • Installer
  • gany-matic

Download technology

When: Wednesday 1-2

Who: Tim W, Scott, Tim M, Thomas H, John, Pascal, Stefan

What:

  • download manger
  • download manager UI
  • proxy support
  • authentication (basic login/pwd prompting)
  • timestamps
  • mirroring

Build

When: Wednesday 3-4

Who: Andrew N, Andrew O, Pascal

What:

  • What do we build from?
  • What is being produced?
  • Product build
  • Packager

Thursday

API

When: Thursday 9-11

Who: Jeff, Susan, John, Pascal

What:

  • how many bundles
  • do we have an API

Plan for SDK integration

When: Thursday 1-3

Who: Jeff, John, Pascal

What:

  • function
  • robustness level


No meeting assigned:

  • Robustness
    • recovery
  • Resolver
  • Fwk admin
    • What do we do with it?
    • Will PDE need to use it?
  • mirroring
  • Repository support
  • Testing

Back to the top