Jump to: navigation, search

Difference between revisions of "P2 COSMOS Integration"

(New page: == Background == In 2008 the Solution Deployment Descriptor 1.0 standard was approved as an OASIS standard. Before the ink was drying on that standard, work was underway on a reference i...)
 
 
Line 24: Line 24:
  
 
To wrap up we discussed next steps.  There was agreement that a meeting between now and EclipseCon is not needed.  Instead we will plan to meet at EclipseCon (decision still pending on whether SAS will be there face to face) and use that time to continue our work together.  Based on progress between now and EclipseCon, plus any additional progress post-EclipseCon, we will determine if other calls make sense.
 
To wrap up we discussed next steps.  There was agreement that a meeting between now and EclipseCon is not needed.  Instead we will plan to meet at EclipseCon (decision still pending on whether SAS will be there face to face) and use that time to continue our work together.  Based on progress between now and EclipseCon, plus any additional progress post-EclipseCon, we will determine if other calls make sense.
 +
 +
[[Category:COSMOS]]

Latest revision as of 18:18, 3 March 2010

Background

In 2008 the Solution Deployment Descriptor 1.0 standard was approved as an OASIS standard. Before the ink was drying on that standard, work was underway on a reference implementation of that standard in the COSMOS project. In the initial stages of that project, the COSMOS team and the P2 team met to discuss the design of P2 and the proposed design of the SDD runtime. At that time the SDD runtime and P2 were at different ends of the maturity spectrum. This led to the SDD team going off putting heads down and implementing a runtime to meet SDD conformance level one goals. This was necessary to prove out the SDD 1.0 standard.

That has been done and the SDD work was GA in COSMOS release 1.1. Now the SDD team is tackling conformance level two SDDs which gets into multi-machine and remote deployment capabilities. This has led to a convergence of SDD runtime requirements with existing P2 functionality. Given that convergence and the similar use cases which need to be solved, the SDD team and P2 team are discussing how P2 can be adopted/leveraged for SDD runtime use.

Meeting Minutes

  • March 3, 2010

Attendees

  • Jeff McAffer (EclipseSource)
  • Brad Beck (CA)
  • Jeff Hamm (SAS)
  • Josh Hester (SAS)
  • Mark Mccraw (SAS)
  • Jason Losh (SAS)

Notes

We started the meeting by giving a brief overview of work that has taken place since our last call. The SDD team took the information Jeff M. shared in our last call and focused in on what will be a key area around the P2 metadata repository and how SDD data may be represented as a metadata repository. Jeff H. summarized work he has done to take an exemplary product, wrapper that product content, the SDD and the SDD runtime in an artifact and have that entire package stored in a P2 artifact repository. He has then been able to successfully get that artifact to an end point and install that exemplary package. This work was to familiarize ourselves with P2 and is not the long term architecture.

This led to a discussion around how P2 deals with existing update sites and "converts" them to P2 repositories. The thinking is that we can follow a similar approach for SDDs. Jeff and Jeff had a lengthy discussion which concluded with some good areas for the SDD team to explore around P2 repositories and how we can follow similar patterns that the P2 team used to convert aforementioned update sites into P2 repositories.

We also hit on a couple of questions related to the P2 code base we should use. Jeff M. indicated that if we were flexible with regards to Eclipse version he recommends 3.6. This led to questions related to API contracts and their stability in the 3.6 code base. Jeff M. indicated that we should feel pretty confident that the APIs will change little to none after M6 for 3.6 is passed.

To wrap up we discussed next steps. There was agreement that a meeting between now and EclipseCon is not needed. Instead we will plan to meet at EclipseCon (decision still pending on whether SAS will be there face to face) and use that time to continue our work together. Based on progress between now and EclipseCon, plus any additional progress post-EclipseCon, we will determine if other calls make sense.