Difference between revisions of "Technology Projects Workshop"

Latest revision as of 17:31, 29 January 2007

Overview

(email from Bjorn)

Technology Committers, A number of Technology projects (ALF, Buckminster, Corona, ECF, Kepler) have decided to have a face-to-face meeting at the Hyatt Burlingame in the afternoon of January 24th (after the Council meetings). As with all things Eclipse, any and all committers are welcome to attend, but please RSVP.

Expected participants: developers in the application lifecycle and collaboration spaces. This is a technical, developer-centric, meeting.

Goal: identify areas where the projects can work together to accelerate the delivery of a cohesive Eclipse solution in this space. In other words, how can the projects work together (technically) and avoid duplication.

Presentation: each participant should expect to start the day with a brief (and technical) description of:

• Their project's goals and objects
• Technology the project has to offer in this space
• Common pieces required for a solution
• Candidates for consolidation of technology
• Existing overlaps of technology with other Eclipse projects
• Existing overlaps of technology with third-party (Apache?) open source projects
• Suggestion for next practical steps we should take

RSVP

Please add your name to the following list to RSVP for the Technology Projects Workshop:

• Dennis O'Flynn, Corona Project Lead
• Don Ebright, Corona Architect
• Paul Styles, Corona Product Manager
• Scott Lewis, ECF Project Lead
• Brian Carroll, ALF Project Lead
• Tim Buss, ALF
• Eishay Smith, OHF
• Craig Laverone, Aperi
• Bjorn Freeman-Benson, Technology PMC Lead
• Philip Dodds, Kepler
• Henrik Lindberg, Buckminster Project, Cloudsmith - via phone
• Thomas Hallgren, Buckminster Project, Cloudsmith - via phone

Technology Projects

Please add a short outline of the presentation you plan to bring to the workshop so that we can pre-review each other's work and thus get the short afternoon started more quickly.

Buckminster

Buckminster’s objective is to leverage and extend the Eclipse platform to make mixed-component development as efficient as plug-in development. The basic approach is to introduce a project-agnostic way of describing a development project’s component structure and dependencies, and to provide a mechanism for materializing source and binary artifacts for a project of any degree of complexity.

Buckminster capabilities:

• Complex (recursive) dependency resolution
• Uniform component dependency format - levaraging existing meta data
• Intelligent retrieval mechanisms - from high variability to frozen configurations
• Flexible project workspace binding
• Actions (run builds etc.)
• Headless small footprint packaging

The full presentation is here (in pdf format).

Corona

Corona is the Tools Services Framework. Its goal is to enable tools and people to interact with each other in a common collaboration context. Corona's framework is based upon the following technologies:

• ContextContainer - common context for collaboration within a distributed workgroup environment
  • RepositoryDescriptor - Defines a reference to a repository that is associated with the ContextContainer
  • Events - Distributed event model for ContextContainer notifications
• Server Side Eclipse - Eclipse based server-side environment to manage Corona's workgroup environment
  • Web services - an OSGi-based SOA component framework for server-side Eclipse plug-in deployment
  • Management - manageability of component and resources via WSDM

The Corona presentation is [1]

Eclipse Communication Framework (ECF)

[ECF] is a set of Equinox-based open APIs for asynchronous point-to-point or group messaging. The APIs are abstracted from the underlying protocol, which allows multiple protocols and services to be supported.

APIs Currently Available

• Service Discovery
• Datashare
• File Transfer
• Remote OSGI Services
• Presence, IM, and Chat
• Object Replication
• Others Being Worked On (e.g. VOIP Call setup/signalling API)

ECF bundles may be used for messaging-enabling server, eRCP, RCP, or Eclipse-based tools and applications.

Kepler

[Kepler] is a Community-Oriented Development Platform that will provide technologies and tooling to Eclipse that enables communities to manage and coordinate development in a distributed and highly interdependent manner. It is the intention of the Kepler project to provide abstraction on leading tools provided today in a rich environment.

Eclipse Open Healthcare Framework (OHF)

[OHF] is a framework providing tools, data structures, protocol stack, and frameworks to the Healthcare vertical. Among others, OHF deals with Public Health, Terminology, HL7 messaging, IHE profiles (XDS, PIX, PDQ, ATNA), security, devices, and more.

ALF

The ALF presentation is [2]

Meeting Minutes

Overview

Each Technology ALM/Collaboration project provided a brief overview its its project and addressed the technology points listed in Bjorn's email. The presentation for each project is available as a link in each project's description above.

Technology Overview

Project Model

Several Technology projects define a Project Model used to define a software development. This project model is not the same as an Eclipse IDE project. Rather, it is used to define all of the resources needed to complete a software development project.

• Buckminster / Corona / Kepler all have a need to define a project model.
• Buckminster / Kepler needs their project model for the core framework
• Corona's project model is part of the exemplary implementation based upon their core framework's ContextContainer

Repository Interface

Within the context of a Project Model exist Repository Interfaces. These interfaces define a repository of resources used by the project.

• Corona defines a Repository Descriptor that is a reference to a repository
• Buckminster has repository readers that can access remote repositories
• Kepler has Repository Interfaces

[We should probably clarify what we mean by "repository" - e.g. a Source Code Management (SCM) Repository in particular or a more inclusive notion of data store for development data. For example, I believe that Mylar has some interfaces to issue/bug management systems. Would a modeling tool that used a database be considered a repository?]

Event Model

Both Corona and ALF are involved with event distribution and management.

• Corona defines an event model used within the local Eclipse workspace. Event distribution is provided to create workgroup collaboration.
• ALF defines high level notion of "event", which can be extended for specific vocabularies (e.g. Requirements, Modeling, Testing, etc.) used to notify different ALM stages of process milestone events. Since ALF employs web services to communicate these events, the granularity tends to be larger. For examlple, that a build has completed, an issue approved, a module checked-in - that is, signals that something significant has changed in a tool that other tools may need to be aware of.

Communications

• ECF provides point-to-point communications used to enable collaboration.

Server-Side Platform

• Corona provides an Eclipse based server-side platform for plugin/bundle SOA component deployment

Build Tooling

• Buckminster / Kepler both can interact with Maven to provide build functionality

ContextContainer / Meta Container

• Corona's ContextContainer can be considered a container for metadata used to define a context for collaboration.

Summary

There seems to be 2 categories of issues that Technology ALM/Collaboration projects need to address:

1. Things that are actually similar that projects are going to cooperate on.
   1. Project Model
   2. Project Model's Repository / Service Interfaces
   3. Issue tracking service interface
2. Things that are not actually similar, but projects need to clarify terms / vocabulary to avoid confusion.
   1. Project Model's Repository / Service Interfaces
   2. Event Model
   3. Build Tooling
   4. Community / Team

Action Items

1. (Corona/Buckminster/Kepler) Define common Project Model
2. (Corona/Buckminster/Kepler) Define common Project Repository Interface
3. (Corona/Buckminster/Kepler) Define common Project Service Interface
4. (Kepler/Mylar) Issue tracking service interface
5. (Corona/ALF) Extend event vocabulary to support granular events within the workbench
6. (ALF)Update event vocabulary to support common Project Model and Repository and Service Interfaces
7. (ECF) Setup IRC, IM chat group for more informal regular communication among Corona, Buckminster, Kepler, ALF teams
8. (ALL) F2F Meeting at EclipseCon

Chat Protocols for Continuous Collaboration

We all have our favorite IM/Chat protocols. We're going to try to find one that we all can use to have occasional lightweight online interactions. Please fill in for yourself the protocols that you use/could use and we'll find a protocol that all of us can/could use in a continuous manner.