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.
Difference between revisions of "STP/Meetings/F2FEclipseSummitEu09"
(→Deployment) |
m (→Deployment) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
=== Attending === | === Attending === | ||
| − | Dobromir Karamelski (Software AG) | + | Dobromir Karamelski (Software AG), Christian Saad (Uni Augsburg, Eclipse JWT), Florian Lautenbacher (Uni Augsburg, Eclipse JWT), |
| − | Christian Saad (Uni Augsburg, Eclipse JWT) | + | Marc Dutoo (open wide, Eclipse JWT), Oisin Hurley (Progress), Mike Milinkovich (Eclipse Foundation), Alain Boulze (Inria), |
| − | Florian Lautenbacher (Uni Augsburg, Eclipse JWT) | + | Etienne Juliot (Obeo, SCA Tools), Wolfgan Neuhaus (Itemis), Oliver Wolf (Sopera, Swordfish), Ricco Deutscher (Sopera) |
| − | Marc Dutoo (open wide, Eclipse JWT) | + | Adrian Mos (Inria, Intermediate Metamodel), Zsolt Beothy-Elo (Sopera, Swordfish) |
| − | Oisin Hurley (Progress) | + | |
| − | Mike Milinkovich (Eclipse Foundation) | + | |
| − | Alain Boulze (Inria) | + | |
| − | Etienne Juliot (Obeo, SCA Tools) | + | |
| − | Wolfgan Neuhaus (Itemis) | + | |
| − | Oliver Wolf (Sopera, Swordfish) | + | |
| − | Ricco Deutscher (Sopera) | + | |
| − | Adrian Mos (Inria, Intermediate Metamodel) | + | |
| − | Zsolt Beothy-Elo (Sopera, Swordfish) | + | |
=== Status SOA TLP === | === Status SOA TLP === | ||
| Line 33: | Line 24: | ||
=== New Repository Project === | === New Repository Project === | ||
| − | * Obeo, Inria, Itemis, SOPERA and expressed interest in starting a repository project as new sub project within the SOA TLP. Short term scope of this project will be to store and manage models and artifacts created by the | + | * Obeo, Inria, Itemis, SOPERA and expressed interest in starting a repository project as new sub project within the SOA TLP. Short term scope of this project will be to store and manage models and artifacts created by the modelers and other tooling. |
| − | * Wolfgang presented the research project Amor (Advanced Model Repository) Itemis started some | + | * Wolfgang presented the research project Amor (Advanced Model Repository) Itemis started some months ago together with Uni Leipzig and Intershop. Goal of the project is to develop a concept, to store, version, retrieve and, reuse artifacts and assets of a model driven software development in a suitable way. The project will implement a generic model repository based on the concepts suitable for all kinds of model driven artifacts and also non model driven artifacts. |
* The Amor repository could be taken as base for the SOA TLP repository. | * The Amor repository could be taken as base for the SOA TLP repository. | ||
| − | * Software AG also expressed in contributing to the repository project, but their focus would be rather a deployment repository. They will also evaluate whether it makes sense to contribute parts of their repository technology to the project. Attendees agreed to extend the scope of the repository to also encompass deployment artifacts and features that helps to standardize deployment and make it | + | * Software AG also expressed in contributing to the repository project, but their focus would be rather a deployment repository. They will also evaluate whether it makes sense to contribute parts of their repository technology to the project. Attendees agreed to extend the scope of the repository to also encompass deployment artifacts and features that helps to standardize deployment and make it more reliable. |
* Next step is to start formulating the proposal for the new repository sub project. Oisin will send the initial mail with a wiki location to start the discussion and the drafting. | * Next step is to start formulating the proposal for the new repository sub project. Oisin will send the initial mail with a wiki location to start the discussion and the drafting. | ||
=== Deployment === | === Deployment === | ||
| − | Attendees identified deployment as important topic that is not yet addresses within the SOA TLP. Some topics | + | Attendees identified deployment as important topic that is not yet addresses within the SOA TLP. Some topics that were raised during discussion about deployment: |
* Deployment within SOA TLP necessary as it is the bridge between tooling and runtime | * Deployment within SOA TLP necessary as it is the bridge between tooling and runtime | ||
* Take SCA assembly model as a standard deployment model | * Take SCA assembly model as a standard deployment model | ||
| Line 46: | Line 37: | ||
* Extend repository to support the deployment of services, components,... | * Extend repository to support the deployment of services, components,... | ||
* Provide deployment model aware OSGi based runtime | * Provide deployment model aware OSGi based runtime | ||
| − | * Follow the activities of the Enterprise Expert | + | * Follow the activities of the Enterprise Expert Group within OSGi, which are working on a similar topic |
* Have a look at the newton project, which uses the SCA model to deploy into an OSGi environment | * Have a look at the newton project, which uses the SCA model to deploy into an OSGi environment | ||
| − | * Software | + | * Software AG is especially interested in this area as they are currently working on this topic and they are willing to contribute within the SOA TLP. |
=== SOA IWG === | === SOA IWG === | ||
| − | There was consensus among the attendees to slightly change the | + | There was consensus among the attendees to slightly change the charter by adding a deployment component as a key piece of the platform between tooling and runtime to allow alternative tooling or runtime components in the platform. |
Latest revision as of 16:53, 10 November 2009
Contents
Eclipse Summit Europe 2009
Attending
Dobromir Karamelski (Software AG), Christian Saad (Uni Augsburg, Eclipse JWT), Florian Lautenbacher (Uni Augsburg, Eclipse JWT), Marc Dutoo (open wide, Eclipse JWT), Oisin Hurley (Progress), Mike Milinkovich (Eclipse Foundation), Alain Boulze (Inria), Etienne Juliot (Obeo, SCA Tools), Wolfgan Neuhaus (Itemis), Oliver Wolf (Sopera, Swordfish), Ricco Deutscher (Sopera) Adrian Mos (Inria, Intermediate Metamodel), Zsolt Beothy-Elo (Sopera, Swordfish)
Status SOA TLP
- Charta approved by board, TLP is ready to start
- SOA TLP will include the following projects from the STP project
- BPM Modeller (active)
- SCA Modeller (active)
- Intermediate Model (active)
- Policy Framework (active)
- Bpel2Java (dormant)
- Enterprise Integration Designer (dormant)
- Project creation for the Intermediate Model and Policy Framework is on the way (the projects are working on the proposals), so we can expect them to become "official" projects shortly.
- The Swordfish project will move from the Runtime project to the SOA TLP and join the other projects in the upcoming weeks.
- As soon as the new projects are created respectively moved to the TLP they will nominate a member for the PMC so that every active subproject is represented in he PMC.
- A new PMC lead has to be elected because Oisin is resigning. In the meeting no volunteer could be found as new lead. so this will be one of the next tasks for the pmc. To reduce the work load one proposed to elect two co-leads. This also has to be discussed.
- Also someone has to take over the role as release engineer from Oisin. As with the PMC lead no volunteer was found yet.
- The JWT project is looking for a new home top level project and expressed interest in joining the SOA TLP. Even if JWT is not a pure SOA project the overlap so significant that it seems to be a good match. The attendees encouraged the idea to join the SOA TLP and welcomed the JWT team.
New Repository Project
- Obeo, Inria, Itemis, SOPERA and expressed interest in starting a repository project as new sub project within the SOA TLP. Short term scope of this project will be to store and manage models and artifacts created by the modelers and other tooling.
- Wolfgang presented the research project Amor (Advanced Model Repository) Itemis started some months ago together with Uni Leipzig and Intershop. Goal of the project is to develop a concept, to store, version, retrieve and, reuse artifacts and assets of a model driven software development in a suitable way. The project will implement a generic model repository based on the concepts suitable for all kinds of model driven artifacts and also non model driven artifacts.
- The Amor repository could be taken as base for the SOA TLP repository.
- Software AG also expressed in contributing to the repository project, but their focus would be rather a deployment repository. They will also evaluate whether it makes sense to contribute parts of their repository technology to the project. Attendees agreed to extend the scope of the repository to also encompass deployment artifacts and features that helps to standardize deployment and make it more reliable.
- Next step is to start formulating the proposal for the new repository sub project. Oisin will send the initial mail with a wiki location to start the discussion and the drafting.
Deployment
Attendees identified deployment as important topic that is not yet addresses within the SOA TLP. Some topics that were raised during discussion about deployment:
- Deployment within SOA TLP necessary as it is the bridge between tooling and runtime
- Take SCA assembly model as a standard deployment model
- Store deployment models in the repository
- Extend repository to support the deployment of services, components,...
- Provide deployment model aware OSGi based runtime
- Follow the activities of the Enterprise Expert Group within OSGi, which are working on a similar topic
- Have a look at the newton project, which uses the SCA model to deploy into an OSGi environment
- Software AG is especially interested in this area as they are currently working on this topic and they are willing to contribute within the SOA TLP.
SOA IWG
There was consensus among the attendees to slightly change the charter by adding a deployment component as a key piece of the platform between tooling and runtime to allow alternative tooling or runtime components in the platform.