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 "Kepler Project Plan"

(Headless Eclipse-Plugin and OSGi Builds)
(Build Management)
Line 76: Line 76:
  
 
* Support automating build targeting to specific platform versions (e.g. Eclipse 2.0, 3.0, 3.1, 3.3M3, current release, etc).
 
* Support automating build targeting to specific platform versions (e.g. Eclipse 2.0, 3.0, 3.1, 3.3M3, current release, etc).
* Builder bindings: Ability to execute "main build" for any integrated build tool whenever the Eclipse project is built in the IDE.
+
* Builder bindings: Ability to execute "main build" for any integrated build tool whenever the Eclipse project is built in the IDE (via integration with existing Eclipse builder mechanisms as well as Kepler-defined extension points).
 
** Consolidation of Europa Common Build Infrastructure Ant scripts inside a PDE-specific Kepler-Ant integration point. ''(NOTE: this requires help from those who know PDE/CBI more thoroughly)''
 
** Consolidation of Europa Common Build Infrastructure Ant scripts inside a PDE-specific Kepler-Ant integration point. ''(NOTE: this requires help from those who know PDE/CBI more thoroughly)''
 
*** Using Kepler, allow augmentation of standard PDE builds using these CBI scripts/scriptlets.
 
*** Using Kepler, allow augmentation of standard PDE builds using these CBI scripts/scriptlets.

Revision as of 18:00, 11 December 2006

Proposed by: Jcasey.mergere.com 14:35, 8 December 2006 (EST)

Kepler Proposal Information

Notes and Conventions

  • This project should be divided into a series of relatively short milestones, each of which will trigger a new release of the Kepler project once completed. Milestones should be achievable in six weeks, plus or minus one week.
  • Files formatted using the (new) native Kepler project model syntax as kmodel-extension files, since they are meant to catch project metadata that cannot be stored in the original metadata files for the project.

Proposed Schedule

NOTE: Notation 'd' signifies the date of Kepler project approval with EMO, since this will keep us from having a code repository, etc. @EF.

NOTE: This proposed schedule is DRAFT and subject to change based upon input from other participants about related project plans and schedules

Proposed schedule for Kepler milestones.
Milestone Start Date Target Date Comments
#Milestone 1 d + 1 week d + 7 weeks 1-week delay anticipated to get CVS, other infrastructure setup @EF.
#Milestone 2 d + 9 weeks d + 15 weeks 1-week delay expected to review/fix process using lessons from first dev cycle.
#Milestone 3 d + 16 weeks d + 22 weeks
#Milestone 4 d + 23 weeks d + 29

Kepler Project Integration Strategy

NOTE: The general strategy for implementing Kepler deliverables listed below will be integration of existing technologies from both Eclipse projects (e.g. Buckminster, PDE, ALF, Corona, EMFT, ECF, Phoenix, etc), and other open source community resources (e.g. Apache Maven, Bugzilla, Php, contributed new technologies, Continuum, Eclipse Wiki, etc). The desire is to leverage as much of existing efforts as possible, avoid reimplementation and rework, and cooperatively use all available expertise and technology for Community Lifecycle Mangagement (you heard it hear first :).

<div id="Milestone 1"/>

Milestone 1

Headless Eclipse-Plugin and OSGi Builds

  • Build Eclipse plugin projects. Support building multiple plugins with both internal and external dependencies, multiple features, deployable zip files, and update sites for a small but representative set of existing Eclipse projects.
    • EXIT CRITERIA: BIRT, GEF, ECF projects (and others willing to participat) building deployable full-project plugins, features, zips, and update sites with existing technologies integrated-by-Kepler.

Common Project Model

  • Define extensible initial Kepler project model API
    • Define initial scope of project model: What to initially exclude?
    • Define target scope of project model (i.e. in Kepler 1.0 timeframe): What to eventually exclude?
  • Read (at least) the following native Eclipse project files using existing APIs, and construct a runtime model instance in memory
    • .project
    • .classpath
    • MANIFEST.MF
    • plugin.xml
    • feature.xml
  • Define Kepler native file format and schema, for capturing augmented model information not captured by the original project metadata files
  • Support generating project metadata in one of many specific metadata formats, regardless of metadata origin
    • Mark each generated metadata file as GENERATED in a header comment, to warn users against modifying it
    • Mark original set of project metadata files as authoritative, plus kmodel-extras file

Build Management

  • Initial Framework to orchestrate external builds from Kepler using native Kepler project model.

<div id="Milestone 2"/>

Milestone 2

Headless Eclipse-Plugin and OSGi Builds

  • Maven, Buckminster, PDE, and web site integration to automate/orchestrate the steps which are currently explicit or custom when performing headless plugin builds

Build Management

  • Support automating build targeting to specific platform versions (e.g. Eclipse 2.0, 3.0, 3.1, 3.3M3, current release, etc).
  • Builder bindings: Ability to execute "main build" for any integrated build tool whenever the Eclipse project is built in the IDE (via integration with existing Eclipse builder mechanisms as well as Kepler-defined extension points).
    • Consolidation of Europa Common Build Infrastructure Ant scripts inside a PDE-specific Kepler-Ant integration point. (NOTE: this requires help from those who know PDE/CBI more thoroughly)
      • Using Kepler, allow augmentation of standard PDE builds using these CBI scripts/scriptlets.
  • Accessory builds (using the build tool to execute a non-default build activity, such as generating javadocs)
    • Support for calling specific Maven lifecycle phases/goals
    • Support for calling specific Buckminster actions.
    • Support for calling specific Ant targets

Common Project Model

  • Possible refinements to accommodate Corona, Buckminster, other interested projects (NOTE: this depends on discussions with other projects to determine alignment, etc.)
  • Tracking of the origin for each model element (for eventual write-back purposes)
  • Selection of searchable artifact sources to be used for current project (using configured sources, above)
  • Search for project dependencies using artifact sources (see configuration, above)
    • Use generic dialog provider base for common search elements.
    • Use extension point to augment search form elements.
  • Graphical editor for Kepler model
    • Synchronization with Eclipse .project/.classpath/etc. files
    • Track which elements should be modified using external editors (i.e. not embeddable in the Kepler editor)
      • spawn that editor when one of these elements is chosen for editing
        • if possible, track the spawned editor, and when it is saved, check whether we can change the modified state (label decoration) for the main model editor.

Configuration (currently global-only, not per-project)

  • Model
    • Preferred external project metadata format
      • Eclipse .project/.classpath + kmodel-externals files
  • Searchable artifact sources
    • Ordering of these sources
  • Build Management
    • Extension point for configuring external tools

<div id="Milestone 3"/>

Milestone 3

NOTE: This milestone will remain incomplete until we know more from the outcomes of previous milestones.

Build Management

  • Support graphical configuration helper-classes per plugin
    • Search for graphical editor helper-class for each plugin; use default XML-editor if not found.
  • Search for plugins
    • Add plugin repository (select from searchable artifact source list, filtered for entry with Maven capabilities)
  • Project-level integration for Problems/Errors view
    • Filtering by type of Kepler problem
  • User input/prompt dialog framework (to allow external build tool to prompt the user for information)

Build Server

  • Support for Add/Remove/Edit of project definitions on the build server
  • Support for Triggered builds that starts browser window to monitor build results using native build-server interface.

Configuration

  • Support per-project configuration of all existing Kepler options
  • Build Server
    • Global build-server list

<div id="Milestone 4"/>

Milestone 4

NOTE: This milestone will remain incomplete until we know more from the outcomes of previous milestones.

Build Server

  • Support for graphical management of build server
  • Replace build monitoring/results browser window with integrated notifications framework for remote events.
    • Track elapsed time
    • Track accumulated output
    • Support multiple monitor types
      • Polling monitor: Configurable polling period
      • Async monitor: monitor abstract event connection (can be JMS/socket/etc.)
    • Event/Process management interface for gaining access to server-side controls available for that process.

Configuration

  • Build Server
    • Per-project configuration of build server(s) to be used
      • Allow selection from global list
      • Allow one-off configuration of build server(s) for that project only

<div id="Milestone 5"/>

Milestone 5

NOTE: This milestone will remain incomplete until we know more from the outcomes of previous milestones.

Build Server Goals

  • Support backing up/restoring build server configuration to/from file.
  • Tool Detection
    • Support abstract detection mechanism for use in various detection scenarios (below).
    • Support detection of build servers; add to the global build-server list
    • Support detection of remote dependency sources

Back to the top