RE: [alf-dev] ALFSourceCodeMangementVocabularyMeeting+1-303-928-3232 id6

["Adam Simantel" <ASimantel@xxxxxxxxxx>]

The Proposed POC use case 1 was discussed today at the SCM Vocabulary
meeting.

I've made the updates below.  I will capture this on the wiki.

-adam


-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Adam Simantel
Sent: Wednesday, October 04, 2006 9:35 AM
To: ALF Developer Mailing List
Subject: RE: [alf-dev]
ALFSourceCodeMangementVocabularyMeeting+1-303-928-3232
id6053141#Wednesday10:00AM PDT


Hello ALF SCM Vocabulary team,

Below is a proposal in response to this ALF SCM Vocabulary task:

   T30.  POC use case candidates.
   We agreed it would be useful to implement one or more POCs based on
the
   various SCM schemas/WSDLs.  There may be some benefit in trying to do
   this before we start any parallel work trying to wrap real products.
   T24 seems important to complete before we start codeing in parallel. 
   Adam Simantel will suggest a use case for the POC

The proposal is intended for SCM Vocabulary team to review and elaborate
(presumably at the meeting today, time permitting).

Thanks,
-adam


Proposed POC use case 1:
========================

Use case:  Most Simple Continuous Integration Build

Description:  The most basic continuous integration build scenario is
provided.  A developer checks in a file, causing a build to initiate.  A
full copy of the affected stream is populated into an empty workspace as
designated by the build.  The build is performed.  Notification that the
build is completed is provided as an ALF event.
 
Steps:
1. Developer checks in code within their versioning client.

2. Versioning provider fires an ALF Stream Changed event

3. ALF Event Manager receives Stream Changed event.

4. ALF Event Manager initiates an ALF Service Flow "Continuous
Integration 
Build"

5. The Continuous Integration Build service flow facilitates the
remainder of the steps:

6.  ALF requests from the Workspace service a Workspace
    Note: The service flow author has defined build locations.
    Note: The Workspace service has been configured with known
locations.
    Note: Service flow author has to make conscious effort to put the
Workspace service into the flow.

7.  ALF requests from the Versioning service "Materialize a set of files
in a workspace".
7a.  Fires "Workspace update started" event (not relevant to this case)
7b.  Fires "Workspace update completed" event
7c.  Note: At completion, Build service has access to a file system
location
where the source code has been placed
     Note:  Consider callback mechanism.
     Note:  Some considerable discussion on whether this is done by the
Workspace or Versioning service.

8.  ALF service flow continues when "Workspace update completed" event
received

9.  ALF requests from the Build service "Perform build"

10. Build service performs the build, and fires appropriate ALF events.

11. Build service fires "Build Completed" ALF event.


Some implementation pieces and parts:
-	Service flow definition "Most Simple Continuous Integration
Build"
-	Versioning service EVENT "Stream Changed"
-	Build service "Identify Workspace Directory"
-	Versioning service "Materialize a set of files in a workspace"
-	Workspace service EVENT "Workspace update started"
-	Workspace service EVENT "Workspace update
completed"
-	Build service "Perform build"
-	Build service EVENT "Build Completed"

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev