From S0mPRRUvuvRlVm4O@XzQPvII7mdsgt6xg Thu Apr 12 23:32:05 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from foundation.eclipse.org (foundation.eclipse.org [206.191.52.61]) by mail.eclipse.org (Postfix) with ESMTP id C5B8F23700 for ; Thu, 12 Apr 2007 23:32:05 -0400 (EDT) Received: by foundation.eclipse.org (Postfix, from userid 102) id 74858F0E; Thu, 12 Apr 2007 23:32:06 -0400 (EDT) X-Spam-Virus: No X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on foundation.eclipse.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.1 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=disabled version=3.1.7 Received: from EFLYNN (CPE0014bf432755-CM000e5c6d0b62.cpe.net.cable.rogers.com [74.122.221.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by foundation.eclipse.org (Postfix) with ESMTP id C2754E81 for ; Thu, 12 Apr 2007 23:32:05 -0400 (EDT) From: "Lynn Gayowski" To: Date: Thu, 12 Apr 2007 23:31:15 -0400 Organization: Eclipse Foundation, Inc. Message-ID: <001c01c77d7c$31a6cc20$6801a8c0@EFLYNN> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C77D5A.AA952C20" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd9fDEtg8uXfpRzTDeZSo3D2v3sXw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Sanitizer: Eclipse.org anomy configuration Subject: [provisioning-dev] Photos from Ganymede Provisioning Workshop X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 03:32:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C77D5A.AA952C20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello! The photos from the Provisioning Workshop (that turned out) are now posted: http://share.shutterfly.com/action/welcome?sid=0IYt2TVsxasXSw. I put the link just above the table of contents on the wiki page as well. Enjoy! Lynn Gayowski Marketing Events Manager Eclipse Foundation, Inc. P (613) 224-9461 ext. 234 F (613) 224-5172 S0mPRRUvuvRlVm4O@XzQPvII7mdsgt6xg www.eclipse.org ------=_NextPart_000_001D_01C77D5A.AA952C20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =

Hello!  The photos from the Provisioning Workshop (= that turned out) are now posted:  h= ttp://share.shutterfly.com/action/welcome?sid=3D0IYt2TVsxasXSw.  I put the link just above the table of contents on the wiki page as well.

 

Enjoy!

Lynn Gayowski

Marketing Events Manager

Eclipse Foundation, Inc.

P (613) 224-9461 ext. 234

F (613) 224-5172

S0mPRRUvuvRlVm4O@XzQPvII7mdsgt6xg

w= ww.eclipse.org

 

------=_NextPart_000_001D_01C77D5A.AA952C20-- From FkJqwWsCkGROpO8g@b0C/ARcn5yziq/5u Fri Apr 13 08:02:45 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from hotelroom3.mainloop.net (hotelroom3.mainloop.net [192.71.58.59]) by mail.eclipse.org (Postfix) with SMTP id 9770CDFE07 for ; Fri, 13 Apr 2007 08:02:43 -0400 (EDT) Received: (qmail 22439 invoked from network); 13 Apr 2007 14:01:48 +0200 Received: from unknown (HELO ?142.131.81.168?) (142.131.81.168) by www-hotelroom3.mainloop.net with SMTP; 13 Apr 2007 14:01:48 +0200 Message-ID: Date: Fri, 13 Apr 2007 14:02:02 +0200 From: Filip Hrbek Organization: Cloudsmith Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] Photos from Ganymede Provisioning Workshop References: <001c01c77d7c$31a6cc20$6801a8c0@EFLYNN> In-Reply-To: <001c01c77d7c$31a6cc20$6801a8c0@EFLYNN> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 12:02:45 -0000 Thank you, Lynn. Nice photos :-)

Regards
  Filip

Lynn Gayowski napsal(a):

Hello!  The photos from the Provisioning Workshop (that turned out) are now posted:  http://share.shutterfly.com/action/welcome?sid=0IYt2TVsxasXSw.  I put the link just above the table of contents on the wiki page as well.

 

Enjoy!

Lynn Gayowski

Marketing Events Manager

Eclipse Foundation, Inc.

P (613) 224-9461 ext. 234

F (613) 224-5172

S0mPRRUvuvRlVm4O@XzQPvII7mdsgt6xg

www.eclipse.org

 


_______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev
From FkJqwWsCkGROpO8g@b0C/ARcn5yziq/5u Fri Apr 13 09:56:53 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from hotelroom3.mainloop.net (hotelroom3.mainloop.net [192.71.58.59]) by mail.eclipse.org (Postfix) with SMTP id 8DDBD2DC81 for ; Fri, 13 Apr 2007 09:56:51 -0400 (EDT) Received: (qmail 13432 invoked from network); 13 Apr 2007 15:55:57 +0200 Received: from unknown (HELO ?142.131.81.168?) (142.131.81.168) by www-hotelroom3.mainloop.net with SMTP; 13 Apr 2007 15:55:56 +0200 Message-ID: Date: Fri, 13 Apr 2007 15:56:07 +0200 From: Filip Hrbek Organization: Cloudsmith Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: [provisioning-dev] Project intersections X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 13:56:53 -0000 Hi, I'd like to push forward working on the GPW actions. To John: Could you please post the issues you are going to work on? Our team (from the Buckminster project) can start on the intersections related to our project, i.e. Director, Engine, Repository, Profile. To Tim: Could you please post the schematic picture you drew on the flip chart? Regards Filip From John_EljLatxtsXDP9738@YHvLZjvCTR1Igv9U Fri Apr 13 11:28:26 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by mail.eclipse.org (Postfix) with SMTP id 9D5A523790 for ; Fri, 13 Apr 2007 11:28:26 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l3DFRWuS021293 for ; Fri, 13 Apr 2007 11:27:32 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3DFRWRV297378 for ; Fri, 13 Apr 2007 11:27:32 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3DFRWAv016718 for ; Fri, 13 Apr 2007 11:27:32 -0400 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3DFRWmM016710 for ; Fri, 13 Apr 2007 11:27:32 -0400 In-Reply-To: To: "Developer discussions for provisioning \(Update Manager\) initiatives" Subject: Re: [provisioning-dev] Project intersections MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: John Arthorne Message-ID: Date: Fri, 13 Apr 2007 11:27:31 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 04/13/2007 11:27:32, Serialize complete at 04/13/2007 11:27:32 Content-Type: multipart/alternative; boundary="=_alternative 0054E9E6852572BC_=" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 15:28:27 -0000 This is a multipart message in MIME format. --=_alternative 0054E9E6852572BC_= Content-Type: text/plain; charset="US-ASCII" Hi Filip, I have created an initial draft of the project intersections page: http://wiki.eclipse.org/index.php/Provisioning_Project_Intersections The remaining work to do here is to write a more detailed description of each of the intersection points. I can take a crack at this next week, or you can work on it too if you have some time. To all: please feel free to update your project name/description in the "interested parties" section. John Filip Hrbek Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg 13/04/2007 09:56 AM Please respond to "Developer discussions for provisioning \(Update Manager\) initiatives" To "Developer discussions for provisioning (Update Manager) initiatives" cc Subject [provisioning-dev] Project intersections Hi, I'd like to push forward working on the GPW actions. To John: Could you please post the issues you are going to work on? Our team (from the Buckminster project) can start on the intersections related to our project, i.e. Director, Engine, Repository, Profile. To Tim: Could you please post the schematic picture you drew on the flip chart? Regards Filip _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev --=_alternative 0054E9E6852572BC_= Content-Type: text/html; charset="US-ASCII"
Hi Filip,

I have created an initial draft of the project intersections page:

http://wiki.eclipse.org/index.php/Provisioning_Project_Intersections

The remaining work to do here is to write a more detailed description of each of the intersection points. I can take a crack at this next week, or you can work on it too if you have some time.

To all: please feel free to update your project name/description in the "interested parties" section.

John



Filip Hrbek <FkJqwWsCkGROpO8g@b0C/ARcn5yziq/5u>
Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg

13/04/2007 09:56 AM
Please respond to
"Developer discussions for provisioning \(Update Manager\)        initiatives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>

To
"Developer discussions for provisioning (Update Manager) initiatives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>
cc
Subject
[provisioning-dev] Project intersections





Hi,

I'd like to push forward working on the GPW actions.

To John:
Could you please post the issues you are going to work on? Our team
(from the Buckminster project) can start on the intersections related to
our project, i.e. Director, Engine, Repository, Profile.

To Tim:
Could you please post the schematic picture you drew on the flip chart?

Regards
 Filip

_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev

--=_alternative 0054E9E6852572BC_=-- From jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/ Fri Apr 13 14:13:41 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by mail.eclipse.org (Postfix) with SMTP id 51F3F2DC72 for ; Fri, 13 Apr 2007 14:13:40 -0400 (EDT) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2007 14:12:20 -0400 X-IronPort-AV: i="4.14,408,1170651600"; d="scan'208"; a="57607436:sNHT74943177414" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3DICD1M030414 for ; Fri, 13 Apr 2007 14:12:13 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3DICDGd007049 for ; Fri, 13 Apr 2007 18:12:13 GMT Received: from xmb-rtp-209.amer.cisco.com ([64.102.31.11]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 14:12:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [provisioning-dev] Project intersections Date: Fri, 13 Apr 2007 14:11:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] Project intersections thread-index: Acd94Elcnj746cI4SkWE5N9pKAAfLQAAHQ4gAAV3oTA= References: From: "Tim Webb \(tiwebb\)" To: X-OriginalArrivalTime: 13 Apr 2007 18:12:05.0628 (UTC) FILETIME=[3E23DBC0:01C77DF7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2207; t=1176487933; x=1177351933; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/; z=From:=20=22Tim=20Webb=20\(tiwebb\)=22=20 |Subject:=20RE=3A=20[provisioning-dev]=20Project=20intersections |Sender:=20 |To:=20; bh=inQwpCG3rhBmO+RBfJUXkX7wllF6m3SCZYomCSMoRXE=; b=igs1wEDO7X0kXnE5Vf/7BwW6mdCW1tgeLgxuizTcdJ+ZYk1yy82EFdLIATts4DZpn68AeKIt 6o1wN8aPjNj35Ds7VP7ZU5CUtZI9SevitvwpZRqzAEjtzF6a3Oma8rw9; Authentication-Results: rtp-dkim-2; header.From=jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 18:13:42 -0000 I have updated the wiki page below with a very rough cut at the diagram. = I did simplify slightly from the one used at the workshop as some of = the lines were not really representative of how components spoke. I = expect we will be able to evolve this diagram over time by combining = these boxes into the diagram shown on the Equinox provisioning incubator = overview page. Tim ________________________________________ From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg = [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of John Arthorne Sent: Friday, April 13, 2007 8:28 AM To: Developer discussions for provisioning (Update Manager) initiatives Subject: Re: [provisioning-dev] Project intersections Hi Filip,=20 I have created an initial draft of the project intersections page:=20 http://wiki.eclipse.org/index.php/Provisioning_Project_Intersections=20 The remaining work to do here is to write a more detailed description of = each of the intersection points. I can take a crack at this next week, = or you can work on it too if you have some time.=20 To all: please feel free to update your project name/description in the = "interested parties" section.=20 John=20 Filip Hrbek =20 Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg=20 13/04/2007 09:56 AM=20 Please respond to "Developer discussions for provisioning \(Update Manager\) =A0 =A0 =A0 = =A0initiatives" To "Developer discussions for provisioning (Update Manager) initiatives" = =20 cc Subject [provisioning-dev] Project intersections Hi, I'd like to push forward working on the GPW actions. To John: Could you please post the issues you are going to work on? Our team=20 (from the Buckminster project) can start on the intersections related to = our project, i.e. Director, Engine, Repository, Profile. To Tim: Could you please post the schematic picture you drew on the flip chart? Regards =A0Filip _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev From Jeff_TTczmgW07z/8fKPW@YHvLZjvCTR1Igv9U Sat Apr 14 23:23:06 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by mail.eclipse.org (Postfix) with SMTP id D646A2D340 for ; Sat, 14 Apr 2007 23:23:04 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l3F2LJqm029597 for ; Sat, 14 Apr 2007 22:21:19 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3F3M7PA559458 for ; Sat, 14 Apr 2007 23:22:07 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3F3M2lX008405 for ; Sat, 14 Apr 2007 23:22:02 -0400 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3F3M2he008268 for ; Sat, 14 Apr 2007 23:22:02 -0400 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Jeff McAffer Message-ID: Date: Sat, 14 Apr 2007 23:21:46 -0400 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 04/14/2007 23:22:02, Serialize complete at 04/14/2007 23:22:02 Content-Type: multipart/alternative; boundary="=_alternative 00124B1F852572BE_=" Subject: [provisioning-dev] lexicon page moved X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 03:23:06 -0000 This is a multipart message in MIME format. --=_alternative 00124B1F852572BE_= Content-Type: text/plain; charset="US-ASCII" I moved the GPW Lexicon wiki page to Provisioning Terminology since the page contents need to be durable in a context broader than the provisioning workshop. Old links, while not updated automatically, should automatically forward to the new page. If you find any problems, please update the references pages. Jeff --=_alternative 00124B1F852572BE_= Content-Type: text/html; charset="US-ASCII"
I moved the GPW Lexicon wiki page to Provisioning Terminology since the page contents need to be durable in a context broader than the provisioning workshop.  Old links, while not updated automatically, should automatically forward to the new page.  If you find any problems, please update the references pages.

Jeff
--=_alternative 00124B1F852572BE_=-- From Jeff_TTczmgW07z/8fKPW@YHvLZjvCTR1Igv9U Mon Apr 16 00:06:52 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by mail.eclipse.org (Postfix) with SMTP id 2768722C7B for ; Mon, 16 Apr 2007 00:06:51 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l3G46igP029094 for ; Mon, 16 Apr 2007 00:06:44 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3G45qJo558858 for ; Mon, 16 Apr 2007 00:05:52 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3G45aT5007762 for ; Mon, 16 Apr 2007 00:05:36 -0400 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3G45aDG007420 for ; Mon, 16 Apr 2007 00:05:36 -0400 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Jeff McAffer Message-ID: Date: Mon, 16 Apr 2007 00:05:19 -0400 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 04/16/2007 00:05:36, Serialize complete at 04/16/2007 00:05:36 Content-Type: multipart/alternative; boundary="=_alternative 00161D63852572BF_=" Subject: [provisioning-dev] Provisioning work exposure X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 04:06:52 -0000 This is a multipart message in MIME format. --=_alternative 00161D63852572BF_= Content-Type: text/plain; charset="US-ASCII" As per the discussions at the workshop, I summarized some of the details and starting points in a recent blog post to help people get in the pool. http://mcaffer.blogspot.com/2007/04/provisioning-work-starts-in-earnest.html I also created a generic Provisioning wiki page to act as the root for the various pages we are creating. See http://wiki.eclipse.org/index.php/Provisioning Edit as you see fit. Jeff --=_alternative 00161D63852572BF_= Content-Type: text/html; charset="US-ASCII"
As per the discussions at the workshop,  I summarized some of the details and starting points in a recent blog post to help people get in the pool.  
        http://mcaffer.blogspot.com/2007/04/provisioning-work-starts-in-earnest.html
I also created a generic Provisioning wiki page to act as the root for the various pages we are creating.  See
        http://wiki.eclipse.org/index.php/Provisioning
Edit as you see fit.

Jeff --=_alternative 00161D63852572BF_=-- From HyQqJbQXCdyr8QDs@MT0TUEPaEGVw/wC1 Mon Apr 16 03:28:33 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from tada.se (1-1-2-48a.rny.sth.bostream.se [82.182.133.12]) by mail.eclipse.org (Postfix) with SMTP id 6064AE2EE7 for ; Mon, 16 Apr 2007 03:28:32 -0400 (EDT) Received: from [192.168.0.60] (unverified [82.182.133.12]) by tada.se (SurgeMail 3.8i) with ESMTP id 3597-1788151 for ; Mon, 16 Apr 2007 09:27:06 +0200 Message-ID: Date: Mon, 16 Apr 2007 09:27:06 +0200 From: Thomas Hallgren User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] Provisioning work exposure References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: HyQqJbQXCdyr8QDs@MT0TUEPaEGVw/wC1 X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 07:28:34 -0000 Hi Jeff, The Terminology link on your blog page is broken It starts with http://http//... - thomas Jeff McAffer wrote: > > As per the discussions at the workshop, I summarized some of the > details and starting points in a recent blog post to help people get > in the pool. > > http://mcaffer.blogspot.com/2007/04/provisioning-work-starts-in-earnest.html > > I also created a generic Provisioning wiki page to act as the root for > the various pages we are creating. See > http://wiki.eclipse.org/index.php/Provisioning > Edit as you see fit. > > Jeff > ------------------------------------------------------------------------ > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > From NGZw83RUgQCo5vRX@aTpS9YBRvPQjNiNX Mon Apr 16 09:12:39 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mis010.exch010.intermedia.net (mis010.exch010.intermedia.net [64.78.61.97]) by mail.eclipse.org (Postfix) with SMTP id 35FA223154 for ; Mon, 16 Apr 2007 09:12:38 -0400 (EDT) Received: from ehost010-3.exch010.intermedia.net ([64.78.61.55]) by mis010.exch010.intermedia.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 06:07:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78028.3583156D" Date: Mon, 16 Apr 2007 06:07:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Server side provisioning Thread-Index: AceAKCvymuNRK7+7TcS8KD9/FvfxSg== From: "Liebig, Stefan " To: X-OriginalArrivalTime: 16 Apr 2007 13:07:39.0322 (UTC) FILETIME=[35D001A0:01C78028] Subject: [provisioning-dev] Server side provisioning X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 13:12:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C78028.3583156D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not sure whether we have mentioned this on the workshop, but could=20 =B4sever side provisioning=B4 be a topic with the arising of server side = OSGI/Eclipse? =20 Stefan =20 ------_=_NextPart_001_01C78028.3583156D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
I am not sure = whether we have mentioned this on the workshop, but could
=0A=
=B4sever side = provisioning=B4 be a topic with the arising of server side = OSGI/Eclipse?
=0A=
 
=0A=
Stefan
=0A=
=0A=
 
------_=_NextPart_001_01C78028.3583156D-- From Pascal_nZARQQd5G+POZmzf@YHvLZjvCTR1Igv9U Mon Apr 16 09:40:17 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by mail.eclipse.org (Postfix) with SMTP id 32CB41CE9E; Mon, 16 Apr 2007 09:40:15 -0400 (EDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l3GDdFMw028157; Mon, 16 Apr 2007 09:39:15 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3GDdF2K495180; Mon, 16 Apr 2007 09:39:15 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3GDcxw1022149; Mon, 16 Apr 2007 09:38:59 -0400 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3GDcx5k021044; Mon, 16 Apr 2007 09:38:59 -0400 In-Reply-To: References: Subject: Re: [provisioning-dev] Server side provisioning To: "Developer discussions for provisioning \(Update Manager\) initiatives" Cc: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg, fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg X-Mailer: Lotus Notes Build V80_M4_03042007NP March 04, 2007 Message-ID: From: Pascal Rapicault Date: Mon, 16 Apr 2007 09:38:43 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 04/16/2007 09:39:00 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 13:40:17 -0000 It is definitely in scope (see the equinox provisioning incubator scope= description). To be even more concrete, Simon and I are working on a small example revolving around server side provisioning with the equinox prov code ba= se. More to come by the end of the week. PaScaL = "Liebig, Stefan " = = To Sent by: = provisioning-dev- = cc B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM = rg Subj= ect [provisioning-dev] Server side = provisioning = 04/16/2007 09:07 = AM = = = Please respond to = "Developer = discussions for = provisioning = \(Update = Manager\) = initiatives" = = = = I am not sure whether we have mentioned this on the workshop, but could= =B4sever side provisioning=B4 be a topic with the arising of server sid= e OSGI/Eclipse? Stefan _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev = From PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI Tue Apr 17 13:52:32 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mail.eclipse.org (Postfix) with SMTP id C3F64E49EC for ; Tue, 17 Apr 2007 13:52:31 -0400 (EDT) Received: by wx-out-0506.google.com with SMTP id t14so2131703wxc for ; Tue, 17 Apr 2007 10:51:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:importance; b=DcCpr5VtEAIylAlm4id9RdIQCjzjGMzb17on1ye/f3vl1zoFJPglYT1BYmp7KgJXyzvnnrta1i6ttPQ6+8IpxnVMm4m0bD06xycx0Jbfxs2/fnhj/ApA1XjWmgEPVu+YFS2vOPwTW4fJI+O+4Q9euUFSi1cyuoA7CIYjxvYBcU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:importance; b=eVYw4GcMsn2v9VHvEGpjgDDVVIQc6eAm3K/S62n0vCVGaBHYzQJZeGG/mYfoXIBgnIRMe0fXnc2w9EzEZRs8tuIvJztLK6fS2BHPPXnPv2Bwq0Hnr64MGaobkbFasE9bl82man5aFTE3mzTV4YyTTkqVPyVxs+KlKP6aPMp2wBI= Received: by 10.90.52.2 with SMTP id z2mr6697617agz.1176832289089; Tue, 17 Apr 2007 10:51:29 -0700 (PDT) Received: from computer ( [71.198.189.95]) by mx.google.com with ESMTP id 32sm10860101wri.2007.04.17.10.51.24; Tue, 17 Apr 2007 10:51:26 -0700 (PDT) From: "Philippe Ombredanne" To: Date: Tue, 17 Apr 2007 10:50:50 -0700 Message-ID: <023101c78118$f3487a00$0dfbfdc0@computer> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal Subject: [provisioning-dev] Provisioning going forward X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI, "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 17:52:32 -0000 Hi all: I could not join the provisioning workshop last week, so I did read all the posts I could find and here is how I have reformulated the conclusion for me: - Equinox is the way to go for provisioning and will be the core platform way. Everyone will contribute and/or migrate to that. - Maya does address some specific use cases and provides a non Equinox-based solution for now, but will also migrate to Equinox provisioning in a near future, and have specific use cases for Equinox. So we all need to focus and concentrate our energies behind Equinox, since it will be lowest common denominator. Fair enough? -- Cheers Philippe http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com nexB - Open by Design (tm) - http://www.nexb.com From jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/ Tue Apr 17 14:15:42 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by mail.eclipse.org (Postfix) with SMTP id A0AFE23CD7 for ; Tue, 17 Apr 2007 14:15:39 -0400 (EDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2007 14:14:38 -0400 X-IronPort-AV: i="4.14,419,1170651600"; d="scan'208"; a="57882060:sNHT62116948" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3HIEcaJ026711; Tue, 17 Apr 2007 14:14:38 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3HIEOli029701; Tue, 17 Apr 2007 18:14:38 GMT Received: from xmb-rtp-209.amer.cisco.com ([64.102.31.11]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 14:14:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [provisioning-dev] Provisioning going forward Date: Tue, 17 Apr 2007 14:14:20 -0400 Message-ID: In-Reply-To: <023101c78118$f3487a00$0dfbfdc0@computer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] Provisioning going forward thread-index: AceBGRlorKH1AqWDSy6p3SiSfBjJDwAAU0yA References: <023101c78118$f3487a00$0dfbfdc0@computer> From: "Tim Webb \(tiwebb\)" To: , "Developer discussions for provisioning \(Update Manager\)initiatives" X-OriginalArrivalTime: 17 Apr 2007 18:14:32.0001 (UTC) FILETIME=[3F099B10:01C7811C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4010; t=1176833678; x=1177697678; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/; z=From:=20=22Tim=20Webb=20\(tiwebb\)=22=20 |Subject:=20RE=3A=20[provisioning-dev]=20Provisioning=20going=20forward |Sender:=20 |To:=20, =0A=20=20=20=20=20=20=20=20=22Developer=20 discussions=20for=20provisioning=20\(Update=20Manager\)initiatives=22=20

; bh=d5wWrJgh3ZXA8d1ZAlSEbfwqAzyBOlZ+ZIq7AF7jt5Q=; b=Dxo/Aq9YnVWIMitBLd9iHupxDn1Xj5BACGkVVo4bpEfsnu+f6qd6F/zuG5JxLwpTnglQC8Gz lI8ziuABfgJYQaGxZQtSz5Nbrgpq5Nd5ew7WzPrbw6mQgohOBjGaSZjO; Authentication-Results: rtp-dkim-1; header.From=jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 18:15:43 -0000 Philippe, Without a doubt everything will ultimately be built on top of the Equinox provisioning work as it provides the key enabling technology that will provide both consistency and enablement for a variety of services. That said, it is unlikely that Equinox's scope will (or should) grow to cover the full set of use cases that will ultimately need to be supported in a the full Eclipse provisioning solution. Instead, I would look at Equinox to provide a rich set of capabilities for provisioning and then certain projects such as Maya to provide additional user interfaces and concrete implementations to meet specific user scenarios -- in the case of Maya being targeted for organization and enterprise provisioning. To pick a particular example, certain consumers of Eclipse require central management. This is an area that will likely continue to reside in the Maya project even as the Equinox project evolves. Similar to Equinox having extensibility, so will the central server component in a provisioning system to enable capabilities such as licensing and governance. I personally see the continued need for multiple projects to be successful if we are hoping to have a successful end-to-end provisioning story for the 3.4 timeline. From the workshop, we identified multiple areas of intersection between projects. From those intersections we will next be splitting out work to be performed in the various provisioning projects. =20 Regarding where to focus attention, I'd suggest focusing it from a given interest or need instead of project and then we can work as a community to determine which project is the right home for the near term to support development of that component. Once the projects mature out of incubator status, we may then decide to restructure project placements but only once we've better defined and delivered on the base provisioning needs for Eclipse. At the end of the day, there are many areas of provisioning as was highlighted by discussions at the workshop. I absolutely agree that we need to make sure the Equinox provisioning work is very successful but I wouldn't want to do that at the expense of the other provisioning work needed. In addition, as we found at the workshop, by talking through projects like Maya, IBM's Install Manager, SmartUp and other technologies represented, we were able to further mature and identify needs that would be required at the Equinox level. Continuing to move the entire provisioning solution forward will help ensure we have not only a successful base story to replace what we have today but a rich platform that will meet needs of the future. Cheers, Tim -----Original Message----- From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of Philippe Ombredanne Sent: Tuesday, April 17, 2007 10:51 AM To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Subject: [provisioning-dev] Provisioning going forward Hi all: I could not join the provisioning workshop last week, so I did read all the posts I could find and here is how I have reformulated the conclusion for me: - Equinox is the way to go for provisioning and will be the core platform way. Everyone will contribute and/or migrate to that. - Maya does address some specific use cases and provides a non Equinox-based solution for now, but will also migrate to Equinox provisioning in a near future, and have specific use cases for Equinox. So we all need to focus and concentrate our energies behind Equinox, since it will be lowest common denominator. Fair enough? --=20 Cheers Philippe http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com=20 nexB - Open by Design (tm) - http://www.nexb.com=20 _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev From PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI Tue Apr 17 20:50:36 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mail.eclipse.org (Postfix) with SMTP id A035FE4F64 for ; Tue, 17 Apr 2007 20:50:35 -0400 (EDT) Received: by wx-out-0506.google.com with SMTP id t14so2251944wxc for ; Tue, 17 Apr 2007 17:49:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:in-reply-to:x-mimeole:importance; b=kOkqdhcmQ4JXdxhKaHxchzmn0fpw7FtdQPyw3++gXQWYCJ6LoEBIajJff12ucOd4qz4jddTa3eMBOKu1FOGifX2dQyQUbK6YXnDp/vjBwqw1AojxdHO2greLXqL7iA8QT4Xy133PQ00gWLm8f1vYIAJujOL4sAmRozrf4HZ7UUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:in-reply-to:x-mimeole:importance; b=mOF4Ugj9e2SuvPT7YBwIU2n4F5rb9wbq/597VWuJaeE3IAw6FVS3hDZcDWciLHV58v+Z4n1ovdSEZ6HshuzlNs0Z683rMwVBwjI4Xno61yN9NR/Mgy4ErVXTLN8sWUA/taFD8a51Nq9FayqRybuMs6CeKiW68tZilA2Gc60WgRE= Received: by 10.70.74.1 with SMTP id w1mr13909663wxa.1176857373658; Tue, 17 Apr 2007 17:49:33 -0700 (PDT) Received: from computer ( [71.198.189.95]) by mx.google.com with ESMTP id q34sm11687919wrq.2007.04.17.17.49.27; Tue, 17 Apr 2007 17:49:32 -0700 (PDT) From: "Philippe Ombredanne" To: "'Developer discussions for provisioning \(Update Manager\)initiatives'" Subject: RE: [provisioning-dev] Provisioning going forward Date: Tue, 17 Apr 2007 17:48:55 -0700 Message-ID: <02c601c78153$5c8f6ac0$0dfbfdc0@computer> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal Cc: jJYpFJUxaNpf5aLU@XzQPvII7mdsgt6xg X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI, "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 00:50:36 -0000 Tim: I am all with you. I am a pragmatist, and when it comes to open source , there is only one truth: the code. Equinox has a code base, and Maya will have one soon. (That I am anxious/excited to checkout ASAP if possible) I highlighted those. Anyone else that has a code base now, and a plan to make it grow has my respect. So I am cool. You are cool.=20 (Note that BTW, we have one too @ easyeclipse, as we sponsored an intern last summer to work on a replacement to the update manager, it was fun stuff, but I do not think it is worthy pursuing for now). Yet I am worried when I see a gadzillion of projects intersections: it smells like design by comittee to me. (bad smell) Variations one one theme and one code base makes sense, as long as it is clear that there is one theme and code base. Because being a pragmatist, the solution that is part of the core SDK will be the most widely distributed and available. And it will win. So we better make it good, solid and the point of first focus, rather than diluting efforts (beyond existing code base like Maya). Or else we can end up with yet another partially useful and broken story that has been the update manager so far. Wa As a side note, I am the admin for the Google Summer of Code @ Eclipse, together with Wayne Beaton. Among the 21 students that have been selected to contribute to Eclipse this summer, there are a couple which are closely related to provisioning. *Eclipse web interface (with a possible use case to trigger provisioning from an arbitrary web page in any web browser) *New Update manager UI (which will focus to bring a face to Equinox provisioning) *An auto-configuration plugin for Eclipse (in a more holistic view of provisioning, to get automated preferences and discovered services configured) *Java Executable Wrapper Plugin for Eclipse (vaguely related) *WebDAV EFS Implementation ( a potential transport) *Semantic-aware software component provisioning: actually reusing software ( to define a component ontology) I invite everyone to check out those abstract and stand by to support and help those students and their mentors when their work will start in late May, as they can contribute small code bricks to the larger edifice. The best way to get plugged in the short term is to join #eclipse-soc on freenode. http://code.google.com/soc/eclipse/about.html --=20 Cheers Philippe http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf philippe ombredanne @ eclipse.org philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com=20 nexB - Open by Design (tm) - http://www.nexb.com=20 > -----Original Message----- > From: Tim Webb (tiwebb) [mailto:jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/]=20 > Sent: Tuesday, April 17, 2007 11:14 AM > To: PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI; Developer discussions for=20 > provisioning (Update Manager)initiatives > Subject: RE: [provisioning-dev] Provisioning going forward >=20 >=20 > Philippe, >=20 > Without a doubt everything will ultimately be built on top of the > Equinox provisioning work as it provides the key enabling technology > that will provide both consistency and enablement for a variety of > services. That said, it is unlikely that Equinox's scope will (or > should) grow to cover the full set of use cases that will ultimately > need to be supported in a the full Eclipse provisioning solution. > Instead, I would look at Equinox to provide a rich set of capabilities > for provisioning and then certain projects such as Maya to provide > additional user interfaces and concrete implementations to=20 > meet specific > user scenarios -- in the case of Maya being targeted for organization > and enterprise provisioning. >=20 > To pick a particular example, certain consumers of Eclipse require > central management. This is an area that will likely=20 > continue to reside > in the Maya project even as the Equinox project evolves. Similar to > Equinox having extensibility, so will the central server=20 > component in a > provisioning system to enable capabilities such as licensing and > governance. I personally see the continued need for multiple projects > to be successful if we are hoping to have a successful end-to-end > provisioning story for the 3.4 timeline. From the workshop, we > identified multiple areas of intersection between projects. =20 > From those > intersections we will next be splitting out work to be=20 > performed in the > various provisioning projects. =20 >=20 > Regarding where to focus attention, I'd suggest focusing it=20 > from a given > interest or need instead of project and then we can work as a=20 > community > to determine which project is the right home for the near term to > support development of that component. Once the projects=20 > mature out of > incubator status, we may then decide to restructure project placements > but only once we've better defined and delivered on the base > provisioning needs for Eclipse. At the end of the day, there are many > areas of provisioning as was highlighted by discussions at=20 > the workshop. >=20 > I absolutely agree that we need to make sure the Equinox provisioning > work is very successful but I wouldn't want to do that at the=20 > expense of > the other provisioning work needed. In addition, as we found at the > workshop, by talking through projects like Maya, IBM's=20 > Install Manager, > SmartUp and other technologies represented, we were able to further > mature and identify needs that would be required at the Equinox level. > Continuing to move the entire provisioning solution forward will help > ensure we have not only a successful base story to replace=20 > what we have > today but a rich platform that will meet needs of the future. >=20 > Cheers, > Tim >=20 > -----Original Message----- > From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg > [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of Philippe > Ombredanne > Sent: Tuesday, April 17, 2007 10:51 AM > To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > Subject: [provisioning-dev] Provisioning going forward >=20 > Hi all: > I could not join the provisioning workshop last week, so I=20 > did read all > the posts I could find and here is how I have reformulated the > conclusion for me: > - Equinox is the way to go for provisioning and will be the core > platform way. Everyone will contribute and/or migrate to that. > - Maya does address some specific use cases and provides a non > Equinox-based solution for now, but will also migrate to Equinox > provisioning in a near future, and have specific use cases=20 > for Equinox. >=20 > So we all need to focus and concentrate our energies behind Equinox, > since it will be lowest common denominator. > Fair enough? >=20 > --=20 > Cheers > Philippe > http://easyeclipse.org - http://phpeclipse.net -=20 > http://eclipse.org/atf > philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com=20 > nexB - Open by Design (tm) - http://www.nexb.com=20 >=20 >=20 > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev >=20 From John_EljLatxtsXDP9738@YHvLZjvCTR1Igv9U Wed Apr 18 10:14:43 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by mail.eclipse.org (Postfix) with SMTP id 15A4123DEF for ; Wed, 18 Apr 2007 10:14:42 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l3IEDdvC011497 for ; Wed, 18 Apr 2007 10:13:39 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3IEDcLK403934 for ; Wed, 18 Apr 2007 10:13:38 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3IEDcJ9000960 for ; Wed, 18 Apr 2007 10:13:38 -0400 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3IEDcvC000932 for ; Wed, 18 Apr 2007 10:13:38 -0400 In-Reply-To: <02c601c78153$5c8f6ac0$0dfbfdc0@computer> To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Subject: RE: [provisioning-dev] Provisioning going forward MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: John Arthorne Message-ID: Date: Wed, 18 Apr 2007 10:13:36 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 04/18/2007 10:13:38, Serialize complete at 04/18/2007 10:13:38 Content-Type: multipart/alternative; boundary="=_alternative 004E2637852572C1_=" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 14:14:43 -0000 This is a multipart message in MIME format. --=_alternative 004E2637852572C1_= Content-Type: text/plain; charset="US-ASCII" I just wanted to clarify the project intersections list. Creating this list wasn't a "design by committee" exercise. Many people with existing open and proprietary technologies came to the workshop, and this list was just an attempt to identify where the common areas of interest are between these existing technologies. Then, going forward, the people who have an interest in those areas can collaborate on a common technology, under whatever project is appropriate for that area. I.e., this wasn't an attempt to see how we can mash up these existing technologies and code into a single blob. I agree with you that the Equinox provisioning work is important, as it will likely define the basic foundation on which other work is built. However, I disagree that everyone needs to focus on this area alone. There are use cases that lie outside the scope of the Equinox work, and there is plenty of room for projects to build interesting new things on top of that foundation. In fact, having other projects building on the Equinox foundation in parallel is probably the best (only?) way to ensure that the basic API and metadata is rich and extensible enough to build upon in the future. As with the initial Eclipse platform, that was built in parallel with exemplary extensions (JDT and PDE), the other provisioning work going on in open and closed source at the same time will help make the underlying foundation much stronger. John "Philippe Ombredanne" Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg 17/04/2007 08:48 PM Please respond to PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI; Please respond to "Developer discussions for provisioning \(Update Manager\) initiatives" To "'Developer discussions for provisioning \(Update Manager\)initiatives'" cc jJYpFJUxaNpf5aLU@XzQPvII7mdsgt6xg Subject RE: [provisioning-dev] Provisioning going forward Tim: I am all with you. I am a pragmatist, and when it comes to open source , there is only one truth: the code. Equinox has a code base, and Maya will have one soon. (That I am anxious/excited to checkout ASAP if possible) I highlighted those. Anyone else that has a code base now, and a plan to make it grow has my respect. So I am cool. You are cool. (Note that BTW, we have one too @ easyeclipse, as we sponsored an intern last summer to work on a replacement to the update manager, it was fun stuff, but I do not think it is worthy pursuing for now). Yet I am worried when I see a gadzillion of projects intersections: it smells like design by comittee to me. (bad smell) Variations one one theme and one code base makes sense, as long as it is clear that there is one theme and code base. Because being a pragmatist, the solution that is part of the core SDK will be the most widely distributed and available. And it will win. So we better make it good, solid and the point of first focus, rather than diluting efforts (beyond existing code base like Maya). Or else we can end up with yet another partially useful and broken story that has been the update manager so far. Wa As a side note, I am the admin for the Google Summer of Code @ Eclipse, together with Wayne Beaton. Among the 21 students that have been selected to contribute to Eclipse this summer, there are a couple which are closely related to provisioning. *Eclipse web interface (with a possible use case to trigger provisioning from an arbitrary web page in any web browser) *New Update manager UI (which will focus to bring a face to Equinox provisioning) *An auto-configuration plugin for Eclipse (in a more holistic view of provisioning, to get automated preferences and discovered services configured) *Java Executable Wrapper Plugin for Eclipse (vaguely related) *WebDAV EFS Implementation ( a potential transport) *Semantic-aware software component provisioning: actually reusing software ( to define a component ontology) I invite everyone to check out those abstract and stand by to support and help those students and their mentors when their work will start in late May, as they can contribute small code bricks to the larger edifice. The best way to get plugged in the short term is to join #eclipse-soc on freenode. http://code.google.com/soc/eclipse/about.html -- Cheers Philippe http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf philippe ombredanne @ eclipse.org philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com nexB - Open by Design (tm) - http://www.nexb.com > -----Original Message----- > From: Tim Webb (tiwebb) [mailto:jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/] > Sent: Tuesday, April 17, 2007 11:14 AM > To: PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI; Developer discussions for > provisioning (Update Manager)initiatives > Subject: RE: [provisioning-dev] Provisioning going forward > > > Philippe, > > Without a doubt everything will ultimately be built on top of the > Equinox provisioning work as it provides the key enabling technology > that will provide both consistency and enablement for a variety of > services. That said, it is unlikely that Equinox's scope will (or > should) grow to cover the full set of use cases that will ultimately > need to be supported in a the full Eclipse provisioning solution. > Instead, I would look at Equinox to provide a rich set of capabilities > for provisioning and then certain projects such as Maya to provide > additional user interfaces and concrete implementations to > meet specific > user scenarios -- in the case of Maya being targeted for organization > and enterprise provisioning. > > To pick a particular example, certain consumers of Eclipse require > central management. This is an area that will likely > continue to reside > in the Maya project even as the Equinox project evolves. Similar to > Equinox having extensibility, so will the central server > component in a > provisioning system to enable capabilities such as licensing and > governance. I personally see the continued need for multiple projects > to be successful if we are hoping to have a successful end-to-end > provisioning story for the 3.4 timeline. From the workshop, we > identified multiple areas of intersection between projects. > From those > intersections we will next be splitting out work to be > performed in the > various provisioning projects. > > Regarding where to focus attention, I'd suggest focusing it > from a given > interest or need instead of project and then we can work as a > community > to determine which project is the right home for the near term to > support development of that component. Once the projects > mature out of > incubator status, we may then decide to restructure project placements > but only once we've better defined and delivered on the base > provisioning needs for Eclipse. At the end of the day, there are many > areas of provisioning as was highlighted by discussions at > the workshop. > > I absolutely agree that we need to make sure the Equinox provisioning > work is very successful but I wouldn't want to do that at the > expense of > the other provisioning work needed. In addition, as we found at the > workshop, by talking through projects like Maya, IBM's > Install Manager, > SmartUp and other technologies represented, we were able to further > mature and identify needs that would be required at the Equinox level. > Continuing to move the entire provisioning solution forward will help > ensure we have not only a successful base story to replace > what we have > today but a rich platform that will meet needs of the future. > > Cheers, > Tim > > -----Original Message----- > From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg > [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of Philippe > Ombredanne > Sent: Tuesday, April 17, 2007 10:51 AM > To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > Subject: [provisioning-dev] Provisioning going forward > > Hi all: > I could not join the provisioning workshop last week, so I > did read all > the posts I could find and here is how I have reformulated the > conclusion for me: > - Equinox is the way to go for provisioning and will be the core > platform way. Everyone will contribute and/or migrate to that. > - Maya does address some specific use cases and provides a non > Equinox-based solution for now, but will also migrate to Equinox > provisioning in a near future, and have specific use cases > for Equinox. > > So we all need to focus and concentrate our energies behind Equinox, > since it will be lowest common denominator. > Fair enough? > > -- > Cheers > Philippe > http://easyeclipse.org - http://phpeclipse.net - > http://eclipse.org/atf > philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com > nexB - Open by Design (tm) - http://www.nexb.com > > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev --=_alternative 004E2637852572C1_= Content-Type: text/html; charset="US-ASCII"
I just wanted to clarify the project intersections list.  Creating this list wasn't a "design by committee" exercise. Many people with existing open and proprietary technologies came to the workshop, and this list was just an attempt to identify where the common areas of interest are between these existing technologies. Then, going forward, the people who have an interest in those areas can collaborate on a common technology, under whatever project is appropriate for that area. I.e., this wasn't an attempt to see how we can mash up these existing technologies and code into a single blob.

I agree with you that the Equinox provisioning work is important, as it will likely define the basic foundation on which other work is built. However, I disagree that everyone needs to focus on this area alone. There are use cases that lie outside the scope of the Equinox work, and there is plenty of room for projects to build interesting new things on top of that foundation. In fact, having other projects building on the Equinox foundation in parallel is probably the best (only?) way to ensure that the basic API and metadata is rich and extensible enough to build upon in the future.  As with the initial Eclipse platform, that was built in parallel with exemplary extensions (JDT and PDE), the other provisioning work going on in open and closed source at the same time will help make the underlying foundation much stronger.

John



"Philippe Ombredanne" <PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI>
Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg

17/04/2007 08:48 PM
Please respond to
PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI; Please respond to
"Developer discussions for provisioning \(Update Manager\)        initiatives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>

To
"'Developer discussions for provisioning \(Update Manager\)initiatives'" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>
cc
jJYpFJUxaNpf5aLU@XzQPvII7mdsgt6xg
Subject
RE: [provisioning-dev] Provisioning going forward





Tim:
I am all with you.
I am a pragmatist, and when it comes to open source , there is only one
truth: the code.
Equinox has a code base, and Maya will have one soon. (That I am
anxious/excited to checkout ASAP if possible)
I highlighted those. Anyone else that has a code base now, and a plan to
make it grow has my respect.
So I am cool. You are cool.
(Note that BTW, we have one too @ easyeclipse, as we sponsored an intern
last summer to work on a replacement to the update manager, it was fun
stuff, but I do not think it is worthy pursuing for now).

Yet I am worried when I see a gadzillion of projects intersections: it
smells like design by comittee to me. (bad smell)
Variations one one theme and one code base makes sense, as long as it is
clear that there is one theme and code base.
Because being a pragmatist, the solution that is part of the core SDK
will be the most widely distributed and available.
And it will win. So we better make it good, solid and the point of first
focus, rather than diluting efforts (beyond existing code base like
Maya).
Or else we can end up with yet another partially useful and broken story
that has been the update manager so far.

Wa

As a side note, I am the admin for the Google Summer of Code @ Eclipse,
together with Wayne Beaton.  Among the 21 students that have been
selected to contribute to Eclipse this summer, there are a couple which
are closely related to provisioning.
*Eclipse web interface (with a possible use case to trigger provisioning
from an arbitrary web page in any web browser)
*New Update manager UI (which will focus to bring a face to Equinox
provisioning)
*An auto-configuration plugin for Eclipse (in a more holistic view of
provisioning, to get automated preferences and discovered services
configured)
*Java Executable Wrapper Plugin for Eclipse (vaguely related)
*WebDAV EFS Implementation ( a potential transport)
*Semantic-aware software component provisioning: actually reusing
software ( to define a component ontology)

I invite everyone to check out those abstract and stand by to support
and help those students and their mentors when their work will start in
late May, as they can contribute small code bricks to the larger
edifice. The best way to get plugged in the short term is to join
#eclipse-soc on freenode.
http://code.google.com/soc/eclipse/about.html


--
Cheers
Philippe
http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf
philippe ombredanne @ eclipse.org
philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com




> -----Original Message-----
> From: Tim Webb (tiwebb) [mailto:jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/]
> Sent: Tuesday, April 17, 2007 11:14 AM
> To: PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI; Developer discussions for
> provisioning (Update Manager)initiatives
> Subject: RE: [provisioning-dev] Provisioning going forward
>
>
> Philippe,
>
> Without a doubt everything will ultimately be built on top of the
> Equinox provisioning work as it provides the key enabling technology
> that will provide both consistency and enablement for a variety of
> services.  That said, it is unlikely that Equinox's scope will (or
> should) grow to cover the full set of use cases that will ultimately
> need to be supported in a the full Eclipse provisioning solution.
> Instead, I would look at Equinox to provide a rich set of capabilities
> for provisioning and then certain projects such as Maya to provide
> additional user interfaces and concrete implementations to
> meet specific
> user scenarios -- in the case of Maya being targeted for organization
> and enterprise provisioning.
>
> To pick a particular example, certain consumers of Eclipse require
> central management.  This is an area that will likely
> continue to reside
> in the Maya project even as the Equinox project evolves.  Similar to
> Equinox having extensibility, so will the central server
> component in a
> provisioning system to enable capabilities such as licensing and
> governance.  I personally see the continued need for multiple projects
> to be successful if we are hoping to have a successful end-to-end
> provisioning story for the 3.4 timeline.  From the workshop, we
> identified multiple areas of intersection between projects.  
> From those
> intersections we will next be splitting out work to be
> performed in the
> various provisioning projects.  
>
> Regarding where to focus attention, I'd suggest focusing it
> from a given
> interest or need instead of project and then we can work as a
> community
> to determine which project is the right home for the near term to
> support development of that component.  Once the projects
> mature out of
> incubator status, we may then decide to restructure project placements
> but only once we've better defined and delivered on the base
> provisioning needs for Eclipse.  At the end of the day, there are many
> areas of provisioning as was highlighted by discussions at
> the workshop.
>
> I absolutely agree that we need to make sure the Equinox provisioning
> work is very successful but I wouldn't want to do that at the
> expense of
> the other provisioning work needed.  In addition, as we found at the
> workshop, by talking through projects like Maya, IBM's
> Install Manager,
> SmartUp and other technologies represented, we were able to further
> mature and identify needs that would be required at the Equinox level.
> Continuing to move the entire provisioning solution forward will help
> ensure we have not only a successful base story to replace
> what we have
> today but a rich platform that will meet needs of the future.
>
> Cheers,
> Tim
>
> -----Original Message-----
> From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg
> [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of Philippe
> Ombredanne
> Sent: Tuesday, April 17, 2007 10:51 AM
> To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
> Subject: [provisioning-dev] Provisioning going forward
>
> Hi all:
> I could not join the provisioning workshop last week, so I
> did read all
> the posts I could find and here is how I have reformulated the
> conclusion for me:
> - Equinox is the way to go for provisioning and will be the core
> platform way. Everyone will contribute and/or migrate to that.
> - Maya does address some specific use cases and provides a non
> Equinox-based solution for now, but will also migrate to Equinox
> provisioning in a near future, and have specific use cases
> for Equinox.
>
> So we all need to focus and concentrate our energies behind Equinox,
> since it will be lowest common denominator.
> Fair enough?
>
> --
> Cheers
> Philippe
> http://easyeclipse.org - http://phpeclipse.net -
> http://eclipse.org/atf
> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
> nexB - Open by Design (tm) - http://www.nexb.com
>
>
> _______________________________________________
> provisioning-dev mailing list
> bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
> https://dev.eclipse.org/mailman/listinfo/provisioning-dev
>

_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev

--=_alternative 004E2637852572C1_=-- From b01NNcLhHUZeEP70@EOCq6JOAWVtjPI0r Wed Apr 18 12:23:30 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mail.eclipse.org (Postfix) with SMTP id E5ACA2E24B for ; Wed, 18 Apr 2007 12:23:28 -0400 (EDT) Received: from [212.227.126.200] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1HeCv7-0008KT-00 for bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg; Wed, 18 Apr 2007 18:22:13 +0200 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1HeCv7-0000UG-07 for bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg; Wed, 18 Apr 2007 18:22:13 +0200 Received: from xchgfe03.exchange.xchg ([172.23.1.44]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 18:22:12 +0200 Received: from mk.local ([87.177.158.181]) by xchgfe03.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 18:22:12 +0200 From: Markus Knauer Organization: Innoopract Informationssysteme GmbH To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Date: Wed, 18 Apr 2007 18:22:09 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: X-OriginalArrivalTime: 18 Apr 2007 16:22:12.0926 (UTC) FILETIME=[B8A61DE0:01C781D5] X-Provags-ID: kundenserver.de mFit/2ULPjzYnh9d@uAVsZ3wjdw/a/1s6 ident:@172.23.1.26 Subject: [provisioning-dev] Eclipse Maya Creation Review X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 16:23:30 -0000 I just wanted to point everybody from the provisioning teams to bug #181669 - after the Creation Review today it is open for voting. https://bugs.eclipse.org/bugs/show_bug.cgi?id=181669 Feel free to vote on that bug for this new and promising project! Markus From denaGb0BDqBF9vJv@N40YPuwdJSyTGzwe Wed Apr 18 12:54:37 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from jade.aracnet.com (jade.aracnet.com [216.99.193.136]) by mail.eclipse.org (Postfix) with SMTP id 53934234A3 for ; Wed, 18 Apr 2007 12:54:34 -0400 (EDT) Received: from [192.168.1.105] (216-99-211-121.dsl.aracnet.com [216.99.211.121]) (authenticated bits=0) by jade.aracnet.com (8.13.6/8.12.8) with ESMTP id l3IGrU59006649 for ; Wed, 18 Apr 2007 09:53:31 -0700 Message-ID: Date: Wed, 18 Apr 2007 09:51:38 -0800 From: Scott Lewis User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [provisioning-dev] ECF and EFS living together happily X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 16:54:37 -0000 Hi Folks, FYI...ECF has a new plugin that implements the ECF filetransfer API using EFS (Eclipse File System). The point of this is that now any code that uses the ECF filetransfer API (e.g. the equinox provisioning incubator code), will transparently be able to use any EFS implementations for file transfer...e.g. efs:file://c:/foo.txt efs:ftp://ftp.eclipse.org/foo/bar.txt etc. This is intended to be in support of the 'protocol pluggability' technical goal WRT the provisioning work. The plugin is: org.eclipse.ecf.provider.filetransfer.efs and is in From denaGb0BDqBF9vJv@N40YPuwdJSyTGzwe Wed Apr 18 12:58:51 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from jade.aracnet.com (jade.aracnet.com [216.99.193.136]) by mail.eclipse.org (Postfix) with SMTP id 3B2A523E71 for ; Wed, 18 Apr 2007 12:58:50 -0400 (EDT) Received: from [192.168.1.105] (216-99-211-121.dsl.aracnet.com [216.99.211.121]) (authenticated bits=0) by jade.aracnet.com (8.13.6/8.12.8) with ESMTP id l3IGvkL4010026 for ; Wed, 18 Apr 2007 09:57:47 -0700 Message-ID: Date: Wed, 18 Apr 2007 09:55:54 -0800 From: Scott Lewis User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] ECF and EFS living together happily References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 16:58:51 -0000 Sorry. Hit send accidently. To finish/continue: Scott Lewis wrote: > Hi Folks, > > FYI...ECF has a new plugin that implements the ECF filetransfer API > using EFS (Eclipse File System). > The point of this is that now any code that uses the ECF filetransfer > API (e.g. the equinox provisioning incubator code), will transparently > be able to use any EFS implementations for file transfer...for those > runtime environments that support EFS...e.g. > > efs:file://c:/foo.txt > efs:ftp://ftp.eclipse.org/foo/bar.txt efs:webdav://dev.eclipse.org/foo/blah.txt > etc. > > This is intended to be in support of the 'protocol pluggability' > technical goal WRT the provisioning work. > > The plugin is: org.eclipse.ecf.provider.filetransfer.efs and is in dev.eclipse.org:/cvsroot/technology/org.eclipse.ecf/providers Thanks. Sorry about the send problems/confusion. Scott From SRS0=SIc0=JX=compeople.de=NGZw83RUgQCo5vRX@EIsrG3AEPJfH8uIN Fri Apr 20 09:41:14 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mail.eclipse.org (Postfix) with SMTP id 6CEB523F54 for ; Fri, 20 Apr 2007 09:41:12 -0400 (EDT) Received: from [217.224.28.15] (helo=[192.168.178.21]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1HetLI37mn-0007Ur; Fri, 20 Apr 2007 15:40:05 +0200 Message-ID: Date: Fri, 20 Apr 2007 15:40:08 +0200 From: Stefan Liebig User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] Photos from Ganymede Provisioning Workshop References: <001c01c77d7c$31a6cc20$6801a8c0@EFLYNN> In-Reply-To: <001c01c77d7c$31a6cc20$6801a8c0@EFLYNN> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19K2yBknf1uRNeWZyFKBSls8JXbp9WqlH0c3JE qAdb6stuFdEBGdOuNewH0aRm2ZRqRSbBcXZb7iAtt9xBbjxRs2 rZZ38rPb3MH2gVChQikJg== X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 13:41:14 -0000 Hello!

Just a few more photos at http://picasaweb.google.com/stefan.liebig/41007GanymedeProvisioningWorkshopInMontebello
There is also link to them below Lynn´s link on the wiki page.

Tschüß,
Stefan

Lynn Gayowski wrote:

Hello!  The photos from the Provisioning Workshop (that turned out) are now posted:  http://share.shutterfly.com/action/welcome?sid=0IYt2TVsxasXSw.  I put the link just above the table of contents on the wiki page as well.

 

Enjoy!

Lynn Gayowski

Marketing Events Manager

Eclipse Foundation, Inc.

P (613) 224-9461 ext. 234

F (613) 224-5172

S0mPRRUvuvRlVm4O@XzQPvII7mdsgt6xg

www.eclipse.org

 


_______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev
From ibUJb3sa9f9eQvpv@NI2tUOVyBgDlja3U Fri Apr 20 14:59:44 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.eclipse.org (Postfix) with SMTP id C110223F7E for ; Fri, 20 Apr 2007 14:59:43 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l3KIwaSM025358 for ; Fri, 20 Apr 2007 14:58:36 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l3KIwZk7007811 for ; Fri, 20 Apr 2007 14:58:36 -0400 Received: from touchme.toronto.redhat.com (IDENT:WDiYDPqf/uCuLoKB@PVpMn8dKDgreGpjk [172.16.14.9]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l3KIwZAk009437 for ; Fri, 20 Apr 2007 14:58:35 -0400 Received: from [172.16.14.122] (to-dhcp22.toronto.redhat.com [172.16.14.122]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 81662800238 for ; Fri, 20 Apr 2007 14:58:35 -0400 (EDT) From: Andrew Overholt To: "Developer discussions for provisioning (Update Manager) initiatives" Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-D47R+veJJoYLiL7vMbWJ" Date: Fri, 20 Apr 2007 14:56:43 -0400 Message-Id: Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) Subject: [provisioning-dev] Multi-user installation concerns X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 18:59:45 -0000 --=-D47R+veJJoYLiL7vMbWJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I wrote up some thoughts regarding $subj. I had a bit of a brainstorming session yesterday with some other Red Hat folks here and they brought up some points that I hadn't already thought of. Jim: sorry we haven't had a chance to sync up yet. I wanted to get this out there so people could discuss it ASAP. Feel free to change things or add a completely separate page if you like :) http://wiki.eclipse.org/index.php/Multi-User_Install_Concerns I'm going to be at the Eclipse Forum Europe next week so I won't be on IRC but I should have email access. I look forward to discussing these issues and working out solutions. Take care, Andrew --=-D47R+veJJoYLiL7vMbWJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGKQzq3yjNjou+b0IRAid9AJ0Tu32VS2CEEuvzojojU3C+MVtmYQCeNsOT 7O6Eh0cVxMzGuYCUByPqhs4= =g7/w -----END PGP SIGNATURE----- --=-D47R+veJJoYLiL7vMbWJ-- From FkJqwWsCkGROpO8g@b0C/ARcn5yziq/5u Tue Apr 24 18:56:19 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from hotelroom3.mainloop.net (hotelroom3.mainloop.net [192.71.58.59]) by mail.eclipse.org (Postfix) with SMTP id 0524A2446D for ; Tue, 24 Apr 2007 18:56:15 -0400 (EDT) Received: (qmail 9883 invoked from network); 25 Apr 2007 00:55:01 +0200 Received: from nat-sloane.pilsfree.net (HELO ?10.109.233.159?) (62.240.183.254) by www-hotelroom3.mainloop.net with SMTP; 25 Apr 2007 00:55:00 +0200 Message-ID: Date: Wed, 25 Apr 2007 00:55:18 +0200 From: Filip Hrbek Organization: Cloudsmith Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] Project intersections References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 22:56:19 -0000 Hi John,

do you have any progress in GPW stuff?

Thanks, Filip


John Arthorne wrote:

Hi Filip,

I have created an initial draft of the project intersections page:

http://wiki.eclipse.org/index.php/Provisioning_Project_Intersections

The remaining work to do here is to write a more detailed description of each of the intersection points. I can take a crack at this next week, or you can work on it too if you have some time.

To all: please feel free to update your project name/description in the "interested parties" section.

John



Filip Hrbek <FkJqwWsCkGROpO8g@b0C/ARcn5yziq/5u>
Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg

13/04/2007 09:56 AM
Please respond to
"Developer discussions for provisioning \(Update Manager\)        initiatives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>

To
"Developer discussions for provisioning (Update Manager) initiatives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>
cc

Subject
[provisioning-dev] Project intersections







Hi,

I'd like to push forward working on the GPW actions.

To John:
Could you please post the issues you are going to work on? Our team
(from the Buckminster project) can start on the intersections related to
our project, i.e. Director, Engine, Repository, Profile.

To Tim:
Could you please post the schematic picture you drew on the flip chart?

Regards
 Filip

_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev


_______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev
From L4z5JpgB9u8VG8O1@Yp5HW06labJ8PMwQ Wed Apr 25 17:28:26 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from peanut.coconut-palm-software.com (coconut-palm-software.com [64.81.137.6]) by mail.eclipse.org (Postfix) with SMTP id D967C232D9 for ; Wed, 25 Apr 2007 17:28:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by peanut.coconut-palm-software.com (Postfix) with ESMTP id 9A53B17B8EAC for ; Wed, 25 Apr 2007 17:22:55 -0500 (CDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Apr 25 17:22:54 2007 X-DSPAM-Confidence: 0.5790 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 462fd4be190851823314927 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.259, BAYES_00=-2.599, DSPAM_HAM=-0.1, HTML_00_10=0.795, HTML_MESSAGE=0.001] Received: from peanut.coconut-palm-software.com ([127.0.0.1]) by localhost (peanut.coconut-palm-software.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT9PtiMgRnMX for ; Wed, 25 Apr 2007 17:22:54 -0500 (CDT) Received: from peanut.coconut-palm-software.com (peanut.coconut-palm-software.com [192.168.0.11]) by peanut.coconut-palm-software.com (Postfix) with ESMTP id 5F6B517B8E9E for ; Wed, 25 Apr 2007 17:22:54 -0500 (CDT) Message-ID: Date: Wed, 25 Apr 2007 17:22:54 -0500 (CDT) From: "David J. Orme" To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1191_4962999.1177539774291" Subject: [provisioning-dev] Improved update generation/distribution algorithm X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2007 21:28:26 -0000 ------=_Part_1191_4962999.1177539774291 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The current feature-based update sites can get huge quickly when small numb= ers of changes are scattered across a large number of features. This kind o= f situation happens easily when releasing a dot-level or a patchlevel upgra= de--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed.=20 The purpose of this email is to open a dialog and to outline our solution. = Apologies in advance for those who are less comfortable with expressing alg= orithms in formal math. Time constraints have dictated communication using = the most compact and efficient means possible.=20 The algorithm we developed worked as follows:=20 The build server maintains copies of all production versions of the applica= tion. In the general case, then, we need an algorithm to upgrade a given us= er from a version V(n) to a version V(n+delta) where delta is the number of= versions that have elapsed since the user last upgraded. We want this algo= rithm to have the following properties:=20 =E2=80=A2 Send a minimal number of bits across the wire=20 =E2=80=A2 Be as simple as possible=20 =E2=80=A2 Be verifiably correct. We couldn't afford to have 40k-70k of = broken clients if the algorithm malfunctioned.=20 =E2=80=A2 Related to the previous: Have safeguards built-in so that if = a bad update site is ever generated, the whole thing fails fast--before *an= y* bits are ever sent to clients.=20 You will notice some conflicts in the requirements above. In particular, th= e requirement to send the fewest number of bits over the wire conflicts wit= h the requirements to be as simple as possible and to be verifiably correct= . The result was that our algorithm sacrifices some efficiency in the numbe= r of bits it sends over the wire in order to be simpler and more verifiably= correct.=20 The result: In our application, going from version 1.0.0 to version 1.0.1 u= sing update site features resulted in about a 10 meg download. After applyi= ng our algorithm, the download size shrunk to about 3 megs. This is still l= arge for some of our users who utilize a dial-up connection, but it is doab= le, whereas the 10 meg download would simply be prohibitive.=20 Here is the algorithm:=20 First, we simplify the problem. Instead of upgrading users from an arbitrar= y version V(n) to V(n+delta), we only upgrade them from V(n) to V(n+1). Goi= ng to V(n+delta) is simply an iteration of the algorithm over delta steps. = This simplification works fine for our user population. If it would be acce= ptable for the general Eclipse population is an open question.=20 Second, we notice that sending JAR'd plugins is very expensive. Suppose onl= y two classes in a large plugin change: the whole plugin must still be ship= ped.=20 Our algorithm then is simple. We dynamically generate a function F where F(= P(V(n))) =3D P(V(n+1)). F is really just a zipped collection of files that = encodes just the files that changed between the two plugin versions.=20 This is accomplished using the following algorithm. For a given plugin P in= two versions V(n) and V(n+1):=20 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.=20 2. For files that correspond to each other in the two plugins, MD5 hash= them, and if the hashes are different, put the file from P(V(n+1)) into F.= =20 3. Include new files from P(V(n+1)) in F.=20 4. Create a text file manifest listing files in P(V(n)) that are no lon= ger included in P(V(n+1)) and include that text file in F.=20 5. Package all of the files in F in a zip file.=20 I believe that the algorithm for applying this function F to P(V(n)) to get= a P(V(n+1)) is self-evident.=20 This approach has advantages over binary-diffing the two plugin jars P(V(n)= ) and P(V(n+1)): If the order of the files contained in the plugin changes = between versions, a naive binary diff algorithm will not achieve nearly the= same amount of "compression" that we achieve.=20 So we have described a simple algorithm that is able to dramatically reduce= download bandwidth requirements over using update sites. However, we have = not described how we achieved the "fail-fast" requirement. If a flawed upda= te site is ever generated, we want to detect this automatically at build ti= me rather than after 50,000 clients have already downloaded it and broken t= heir installs.=20 Here is the algorithm we use:=20 After a build has completed, we have the following artifacts on our build s= erver:=20 P(V(n)) - the old version=20 P(V(n+1)) - the original new version generated by PDEBuild=20 F - the function (basically an intelligent binary diff) we generated that w= e can apply to P(V(n)) to get P(V(n+1))=20 The approach we take to validate F is the following:=20 1. Apply F to P(V(n)) on the build server using the same code that is r= unning on the clients.=20 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice t= he prime there). So formally, F(P(V(n))) =3D P(V(n+1))'=20 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the versi= on originally generated by PDEBuild.=20 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary= directories and perform an MD5 hash on all files, making sure that all fil= es present in one are also present in the other and that their hashes are e= qual.=20 5. If applying F to P(V(n)) on the build server using the same code as = is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on t= he server, then it should work on the clients as well.=20 In our implementation, all update site building on the build server was don= e in Ruby. The effort to implement the server side of this algorithm in Rub= y was about three days. The effort to implement the client-side (fully unit= -tested, pair-programmed, one pair programming team working on it full-time= ) in Java was about a month. This was due to the hassle of working with Jav= a input and output streams. However, the result was that the Java code work= ed entirely in memory, piping input streams into output streams and so on u= ntil only the final results were written to disk. Thus, the Java solution w= ould be immune to breakage resulting from something on the file system bein= g changed in a way we did not expect.=20 Let me know if you have any questions.=20 Regards,=20 Dave Orme=20 ------=_Part_1191_4962999.1177539774291 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit The current feature-based update sites can get huge quickly when small numbers of changes are scattered across a large number of features.  This kind of situation happens easily when releasing a dot-level or a patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed.

The purpose of this email is to open a dialog and to outline our solution.  Apologies in advance for those who are less comfortable with expressing algorithms in formal math.  Time constraints have dictated communication using the most compact and efficient means possible.

The algorithm we developed worked as follows:

The build server maintains copies of all production versions of the application.  In the general case, then, we need an algorithm to upgrade a given user from a version V(n) to a version V(n+delta) where delta is the number of versions that have elapsed since the user last upgraded.  We want this algorithm to have the following properties:
  • Send a minimal number of bits across the wire
  • Be as simple as possible
  • Be verifiably correct.  We couldn't afford to have 40k-70k of broken clients if the algorithm malfunctioned.
  • Related to the previous: Have safeguards built-in so that if a bad update site is ever generated, the whole thing fails fast--before *any* bits are ever sent to clients.
You will notice some conflicts in the requirements above.  In particular, the requirement to send the fewest number of bits over the wire conflicts with the requirements to be as simple as possible and to be verifiably correct.  The result was that our algorithm sacrifices some efficiency in the number of bits it sends over the wire in order to be simpler and more verifiably correct.

The result: In our application, going from version 1.0.0 to version 1.0.1 using update site features resulted in about a 10 meg download.  After applying our algorithm, the download size shrunk to about 3 megs.  This is still large for some of our users who utilize a dial-up connection, but it is doable, whereas the 10 meg download would simply be prohibitive.

Here is the algorithm:

First, we simplify the problem.  Instead of upgrading users from an arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to V(n+1).  Going to V(n+delta) is simply an iteration of the algorithm over delta steps.  This simplification works fine for our user population.  If it would be acceptable for the general Eclipse population is an open question.

Second, we notice that sending JAR'd plugins is very expensive.  Suppose only two classes in a large plugin change: the whole plugin must still be shipped.

Our algorithm then is simple.  We dynamically generate a function F where F(P(V(n))) = P(V(n+1)).  F is really just a zipped collection of files that encodes just the files that changed between the two plugin versions.

This is accomplished using the following algorithm.  For a given plugin P in two versions V(n) and V(n+1):
  1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.
  2. For files that correspond to each other in the two plugins, MD5 hash them, and if the hashes are different, put the file from P(V(n+1)) into F.
  3. Include new files from P(V(n+1)) in F.
  4. Create a text file manifest listing files in P(V(n)) that are no longer included in P(V(n+1)) and include that text file in F.
  5. Package all of the files in F in a zip file.
I believe that the algorithm for applying this function F to P(V(n)) to get a P(V(n+1)) is self-evident.

This approach has advantages over binary-diffing the two plugin jars P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin changes between versions, a naive binary diff algorithm will not achieve nearly the same amount of "compression" that we achieve.

So we have described a simple algorithm that is able to dramatically reduce download bandwidth requirements over using update sites.  However, we have not described how we achieved the "fail-fast" requirement.  If a flawed update site is ever generated, we want to detect this automatically at build time rather than after 50,000 clients have already downloaded it and broken their installs.

Here is the algorithm we use:

After a build has completed, we have the following artifacts on our build server:

P(V(n)) - the old version
P(V(n+1)) - the original new version generated by PDEBuild
F - the function (basically an intelligent binary diff) we generated that we can apply to P(V(n)) to get P(V(n+1))

The approach we take to validate F is the following:
  1. Apply F to P(V(n)) on the build server using the same code that is running on the clients.
  2. Let's call the result of applying F to P(V(n)), P(V(n+1))'  (notice the prime there).  So formally, F(P(V(n))) = P(V(n+1))'
  3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the version originally generated by PDEBuild.
  4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary directories and perform an MD5 hash on all files, making sure that all files present in one are also present in the other and that their hashes are equal.
  5. If applying F to P(V(n)) on the build server using the same code as is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on the server, then it should work on the clients as well.
In our implementation, all update site building on the build server was done in Ruby.  The effort to implement the server side of this algorithm in Ruby was about three days.  The effort to implement the client-side (fully unit-tested, pair-programmed, one pair programming team working on it full-time) in Java was about a month.  This was due to the hassle of working with Java input and output streams.  However, the result was that the Java code worked entirely in memory, piping input streams into output streams and so on until only the final results were written to disk.  Thus, the Java solution would be immune to breakage resulting from something on the file system being changed in a way we did not expect.

Let me know if you have any questions.


Regards,

Dave Orme

------=_Part_1191_4962999.1177539774291-- From PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI Wed Apr 25 19:47:03 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mail.eclipse.org (Postfix) with SMTP id 565DD2477A for ; Wed, 25 Apr 2007 19:47:02 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id u52so347387pyb for ; Wed, 25 Apr 2007 16:45:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:subject:date:message-id:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:importance:in-reply-to:x-mimeole; b=GBP8jMnYGpRxuNxQA4ubv4qlzOO4EqeldhWpXYLLgDf8dQq+wN1RrciDl+sFhCh+O2wONzmQ+nzrfBHpl0mRKZoFTCFvSCvyfTH3sgVqTgVKca3uhPApx6zAZ1v03MrzN5hAQGN9TMe4OOdNelZ/gi3x2lvC/FDQYSUGtfXYViM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:subject:date:message-id:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:importance:in-reply-to:x-mimeole; b=fs1eowaQWaLAgupu0S/qMK3P6kMskmC5iMs9JTSOAI8sI+qKmoO5q3tWhqgBiVK+oBdyjw5AfjWmN9znzBpQSZf9sMVYrDzc8rjzZOjmCyZg/eizBQKNn2ouF9WSBWlrsFKmL4ToKIkl/liO0vZ3CUdpbi938Oh1kqpu3mArwYY= Received: by 10.65.219.1 with SMTP id w1mr2532963qbq.1177544745437; Wed, 25 Apr 2007 16:45:45 -0700 (PDT) Received: from computer ( [71.198.189.95]) by mx.google.com with ESMTP id 38sm264568nzk.2007.04.25.16.45.34; Wed, 25 Apr 2007 16:45:43 -0700 (PDT) From: "Philippe Ombredanne" To: "'Developer discussions for provisioning \(Update Manager\)initiatives'" Subject: RE: [provisioning-dev] Improved update generation/distribution algorithm Date: Wed, 25 Apr 2007 16:45:00 -0700 Message-ID: <010a01c78793$c4368c80$0dfbfdc0@computer> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010B_01C78759.17D7B480" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI, "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2007 23:47:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_010B_01C78759.17D7B480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David: Mighty interesting! Would the code be availabel somewhere for review? Cordially =20 -- Cheers Philippe http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf -----Original Message----- From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of David J. Orme Sent: Wednesday, April 25, 2007 3:23 PM To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Subject: [provisioning-dev] Improved update generation/distribution algorithm The current feature-based update sites can get huge quickly when small numbers of changes are scattered across a large number of features. This kind of situation happens easily when releasing a dot-level or a patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed. The purpose of this email is to open a dialog and to outline our solution. Apologies in advance for those who are less comfortable with expressing algorithms in formal math. Time constraints have dictated communication using the most compact and efficient means possible. The algorithm we developed worked as follows: The build server maintains copies of all production versions of the application. In the general case, then, we need an algorithm to upgrade a given user from a version V(n) to a version V(n+delta) where delta is the number of versions that have elapsed since the user last upgraded. We want this algorithm to have the following properties: * Send a minimal number of bits across the wire=20 * Be as simple as possible=20 * Be verifiably correct. We couldn't afford to have 40k-70k of broken clients if the algorithm malfunctioned.=20 * Related to the previous: Have safeguards built-in so that if a bad update site is ever generated, the whole thing fails fast--before *any* bits are ever sent to clients. You will notice some conflicts in the requirements above. In particular, the requirement to send the fewest number of bits over the wire conflicts with the requirements to be as simple as possible and to be verifiably correct. The result was that our algorithm sacrifices some efficiency in the number of bits it sends over the wire in order to be simpler and more verifiably correct. The result: In our application, going from version 1.0.0 to version 1.0.1 using update site features resulted in about a 10 meg download. After applying our algorithm, the download size shrunk to about 3 megs. This is still large for some of our users who utilize a dial-up connection, but it is doable, whereas the 10 meg download would simply be prohibitive. Here is the algorithm: First, we simplify the problem. Instead of upgrading users from an arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to V(n+1). Going to V(n+delta) is simply an iteration of the algorithm over delta steps. This simplification works fine for our user population. If it would be acceptable for the general Eclipse population is an open question. Second, we notice that sending JAR'd plugins is very expensive. Suppose only two classes in a large plugin change: the whole plugin must still be shipped. Our algorithm then is simple. We dynamically generate a function F where F(P(V(n))) =3D P(V(n+1)). F is really just a zipped collection of files that encodes just the files that changed between the two plugin versions. This is accomplished using the following algorithm. For a given plugin P in two versions V(n) and V(n+1): 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.=20 2. For files that correspond to each other in the two plugins, MD5 hash them, and if the hashes are different, put the file from P(V(n+1)) into F.=20 3. Include new files from P(V(n+1)) in F.=20 4. Create a text file manifest listing files in P(V(n)) that are no longer included in P(V(n+1)) and include that text file in F.=20 5. Package all of the files in F in a zip file. I believe that the algorithm for applying this function F to P(V(n)) to get a P(V(n+1)) is self-evident. This approach has advantages over binary-diffing the two plugin jars P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin changes between versions, a naive binary diff algorithm will not achieve nearly the same amount of "compression" that we achieve. So we have described a simple algorithm that is able to dramatically reduce download bandwidth requirements over using update sites. However, we have not described how we achieved the "fail-fast" requirement. If a flawed update site is ever generated, we want to detect this automatically at build time rather than after 50,000 clients have already downloaded it and broken their installs. Here is the algorithm we use: After a build has completed, we have the following artifacts on our build server: P(V(n)) - the old version P(V(n+1)) - the original new version generated by PDEBuild F - the function (basically an intelligent binary diff) we generated that we can apply to P(V(n)) to get P(V(n+1)) The approach we take to validate F is the following: 1. Apply F to P(V(n)) on the build server using the same code that is running on the clients.=20 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice the prime there). So formally, F(P(V(n))) =3D P(V(n+1))' 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the version originally generated by PDEBuild.=20 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary directories and perform an MD5 hash on all files, making sure that all files present in one are also present in the other and that their hashes are equal.=20 5. If applying F to P(V(n)) on the build server using the same code as is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on the server, then it should work on the clients as well. In our implementation, all update site building on the build server was done in Ruby. The effort to implement the server side of this algorithm in Ruby was about three days. The effort to implement the client-side (fully unit-tested, pair-programmed, one pair programming team working on it full-time) in Java was about a month. This was due to the hassle of working with Java input and output streams. However, the result was that the Java code worked entirely in memory, piping input streams into output streams and so on until only the final results were written to disk. Thus, the Java solution would be immune to breakage resulting from something on the file system being changed in a way we did not expect. Let me know if you have any questions. Regards, Dave Orme ------=_NextPart_000_010B_01C78759.17D7B480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 David:
Mighty interesting!
Would the code be availabel somewhere for=20 review?
Cordially
 


--
Cheers
Philippe
http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf

=



-----Original Message-----
From:=20 fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg=20 [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of = David J.=20 Orme
Sent: Wednesday, April 25, 2007 3:23 PM
To:=20 bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Subject: [provisioning-dev] = Improved=20 update generation/distribution algorithm

The = current=20 feature-based update sites can get huge quickly when small numbers of = changes=20 are scattered across a large number of features.  This kind of = situation=20 happens easily when releasing a dot-level or a patchlevel upgrade--ie: = 1.0.0=20 to 1.0.1--where lots of small bugs are fixed.

The purpose of = this email=20 is to open a dialog and to outline our solution.  Apologies in = advance=20 for those who are less comfortable with expressing algorithms in = formal=20 math.  Time constraints have dictated communication using the = most=20 compact and efficient means possible.

The algorithm we = developed worked=20 as follows:

The build server maintains copies of all production = versions of the application.  In the general case, then, we need = an=20 algorithm to upgrade a given user from a version V(n) to a version = V(n+delta)=20 where delta is the number of versions that have elapsed since the user = last=20 upgraded.  We want this algorithm to have the following = properties:
  • Send a minimal number of bits across the wire
  • Be as simple as possible
  • Be verifiably correct.  We couldn't afford to have 40k-70k = of=20 broken clients if the algorithm malfunctioned.
  • Related to the previous: Have safeguards built-in so that if a = bad=20 update site is ever generated, the whole thing fails fast--before = *any* bits=20 are ever sent to clients.
You will notice some conflicts in = the=20 requirements above.  In particular, the requirement to send the = fewest=20 number of bits over the wire conflicts with the requirements to be as = simple=20 as possible and to be verifiably correct.  The result was that = our=20 algorithm sacrifices some efficiency in the number of bits it sends = over the=20 wire in order to be simpler and more verifiably correct.

The = result: In=20 our application, going from version 1.0.0 to version 1.0.1 using = update site=20 features resulted in about a 10 meg download.  After applying our = algorithm, the download size shrunk to about 3 megs.  This is = still large=20 for some of our users who utilize a dial-up connection, but it is = doable,=20 whereas the 10 meg download would simply be prohibitive.

Here = is the=20 algorithm:

First, we simplify the problem.  Instead of = upgrading=20 users from an arbitrary version V(n) to V(n+delta), we only upgrade = them from=20 V(n) to V(n+1).  Going to V(n+delta) is simply an iteration of = the=20 algorithm over delta steps.  This simplification works fine for = our user=20 population.  If it would be acceptable for the general Eclipse = population=20 is an open question.

Second, we notice that sending JAR'd = plugins is=20 very expensive.  Suppose only two classes in a large plugin = change: the=20 whole plugin must still be shipped.

Our algorithm then is = simple. =20 We dynamically generate a function F where F(P(V(n))) =3D = P(V(n+1)).  F is=20 really just a zipped collection of files that encodes just the files = that=20 changed between the two plugin versions.

This is accomplished = using the=20 following algorithm.  For a given plugin P in two versions V(n) = and=20 V(n+1):
  1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.
  2. For files that correspond to each other in the two plugins, MD5 = hash=20 them, and if the hashes are different, put the file from P(V(n+1)) = into F.
  3. Include new files from P(V(n+1)) in F.
  4. Create a text file manifest listing files in P(V(n)) that are no = longer=20 included in P(V(n+1)) and include that text file in F.
  5. Package all of the files in F in a zip file.
I = believe that=20 the algorithm for applying this function F to P(V(n)) to get a = P(V(n+1)) is=20 self-evident.

This approach has advantages over binary-diffing = the two=20 plugin jars P(V(n)) and P(V(n+1)): If the order of the files contained = in the=20 plugin changes between versions, a naive binary diff algorithm will = not=20 achieve nearly the same amount of "compression" that we = achieve.

So we=20 have described a simple algorithm that is able to dramatically reduce = download=20 bandwidth requirements over using update sites.  However, we have = not=20 described how we achieved the "fail-fast" requirement.  If a = flawed=20 update site is ever generated, we want to detect this automatically at = build=20 time rather than after 50,000 clients have already downloaded it and = broken=20 their installs.

Here is the algorithm we use:

After a = build has=20 completed, we have the following artifacts on our build = server:

P(V(n))=20 - the old version
P(V(n+1)) - the original new version generated by = PDEBuild
F - the function (basically an intelligent binary diff) we = generated that we can apply to P(V(n)) to get P(V(n+1))

The = approach we=20 take to validate F is the following:
  1. Apply F to P(V(n)) on the build server using the same code that = is=20 running on the clients.
  2. Let's call the result of applying F to P(V(n)), P(V(n+1))'  = (notice=20 the prime there).  So formally, F(P(V(n))) =3D P(V(n+1))'
  3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the = version=20 originally generated by PDEBuild.
  4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into = temporary=20 directories and perform an MD5 hash on all files, making sure that = all files=20 present in one are also present in the other and that their hashes = are=20 equal.
  5. If applying F to P(V(n)) on the build server using the same code = as is=20 running on the clients produces a P(V(n+1))' identical to P(V(n+1)) = on the=20 server, then it should work on the clients as well.
In = our=20 implementation, all update site building on the build server was done = in=20 Ruby.  The effort to implement the server side of this algorithm = in Ruby=20 was about three days.  The effort to implement the client-side = (fully=20 unit-tested, pair-programmed, one pair programming team working on it=20 full-time) in Java was about a month.  This was due to the hassle = of=20 working with Java input and output streams.  However, the result = was that=20 the Java code worked entirely in memory, piping input streams into = output=20 streams and so on until only the final results were written to = disk. =20 Thus, the Java solution would be immune to breakage resulting from = something=20 on the file system being changed in a way we did not = expect.

Let me=20 know if you have any questions.


Regards,

Dave=20 Orme

------=_NextPart_000_010B_01C78759.17D7B480-- From Pascal_nZARQQd5G+POZmzf@YHvLZjvCTR1Igv9U Wed Apr 25 23:05:07 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by mail.eclipse.org (Postfix) with SMTP id B2C4DEE65A; Wed, 25 Apr 2007 23:05:07 -0400 (EDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l3Q33nOk003740; Wed, 25 Apr 2007 23:03:49 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3Q33n9x486884; Wed, 25 Apr 2007 23:03:49 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3Q33ngL012892; Wed, 25 Apr 2007 23:03:49 -0400 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3Q33m4Y012889; Wed, 25 Apr 2007 23:03:49 -0400 In-Reply-To: References: Subject: Re: [provisioning-dev] Improved update generation/distribution algorithm To: "Developer discussions for provisioning \(Update Manager\) initiatives" Cc: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg, fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg X-Mailer: Lotus Notes Build V80_M4_03042007NP March 04, 2007 Message-ID: From: Pascal Rapicault Date: Wed, 25 Apr 2007 23:03:47 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 04/25/2007 23:03:48 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 03:05:08 -0000 Hi Dave, This is really interesting and is definitely something we would like to have. I would like to thank you for presenting here what you have because it gives us a base to discuss and evolve from which is much better than if we had to start from scratch. Now here are a few questions: - From the description, it seems that the server can be a directory or a plain http server (or any other form of "dumb" server), am I correct? - Is the size of the update site ever an issue? - With a server that could run code, have you considered the generation of the deltas on the fly given what the client has? - Have you identified the threshold in the size of the delta where it would be more effective to senfdthe full file? - The application of F on the client seems to be pretty memory intensive. Could you characterize the complexity of F in terms of memory? - Even though you verify the content of the server, there are always many things that can go wrong. So on the client how do you ensure that F(P(V(n))) is equal to P(V(n+1)). What about shipping a checksum of the expected result after the merge? - Do you handle signed jars? - In your example, you say that 3M is still large? Why do you think so, are the actual changes smaller? Why don't you ship the delta of each files instead of each complete file? - How do you see that fit with the concept of artifact repository developed in equinox and our attempt to use a mirroring metaphor instead of download? Thank you, PaScaL "David J. Orme" To Sent by: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg provisioning-dev- cc B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM rg Subject [provisioning-dev] Improved update generation/distribution algorithm 04/25/2007 06:22 PM Please respond to "Developer discussions for provisioning \(Update Manager\) initiatives" The current feature-based update sites can get huge quickly when small numbers of changes are scattered across a large number of features. This kind of situation happens easily when releasing a dot-level or a patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed. The purpose of this email is to open a dialog and to outline our solution. Apologies in advance for those who are less comfortable with expressing algorithms in formal math. Time constraints have dictated communication using the most compact and efficient means possible. The algorithm we developed worked as follows: The build server maintains copies of all production versions of the application. In the general case, then, we need an algorithm to upgrade a given user from a version V(n) to a version V(n+delta) where delta is the number of versions that have elapsed since the user last upgraded. We want this algorithm to have the following properties: Send a minimal number of bits across the wire Be as simple as possible Be verifiably correct. We couldn't afford to have 40k-70k of broken clients if the algorithm malfunctioned. Related to the previous: Have safeguards built-in so that if a bad update site is ever generated, the whole thing fails fast--before *any* bits are ever sent to clients. You will notice some conflicts in the requirements above. In particular, the requirement to send the fewest number of bits over the wire conflicts with the requirements to be as simple as possible and to be verifiably correct. The result was that our algorithm sacrifices some efficiency in the number of bits it sends over the wire in order to be simpler and more verifiably correct. The result: In our application, going from version 1.0.0 to version 1.0.1 using update site features resulted in about a 10 meg download. After applying our algorithm, the download size shrunk to about 3 megs. This is still large for some of our users who utilize a dial-up connection, but it is doable, whereas the 10 meg download would simply be prohibitive. Here is the algorithm: First, we simplify the problem. Instead of upgrading users from an arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to V(n+1). Going to V(n+delta) is simply an iteration of the algorithm over delta steps. This simplification works fine for our user population. If it would be acceptable for the general Eclipse population is an open question. Second, we notice that sending JAR'd plugins is very expensive. Suppose only two classes in a large plugin change: the whole plugin must still be shipped. Our algorithm then is simple. We dynamically generate a function F where F(P(V(n))) = P(V(n+1)). F is really just a zipped collection of files that encodes just the files that changed between the two plugin versions. This is accomplished using the following algorithm. For a given plugin P in two versions V(n) and V(n+1): 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories. 2. For files that correspond to each other in the two plugins, MD5 hash them, and if the hashes are different, put the file from P(V(n+1)) into F. 3. Include new files from P(V(n+1)) in F. 4. Create a text file manifest listing files in P(V(n)) that are no longer included in P(V(n+1)) and include that text file in F. 5. Package all of the files in F in a zip file. I believe that the algorithm for applying this function F to P(V(n)) to get a P(V(n+1)) is self-evident. This approach has advantages over binary-diffing the two plugin jars P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin changes between versions, a naive binary diff algorithm will not achieve nearly the same amount of "compression" that we achieve. So we have described a simple algorithm that is able to dramatically reduce download bandwidth requirements over using update sites. However, we have not described how we achieved the "fail-fast" requirement. If a flawed update site is ever generated, we want to detect this automatically at build time rather than after 50,000 clients have already downloaded it and broken their installs. Here is the algorithm we use: After a build has completed, we have the following artifacts on our build server: P(V(n)) - the old version P(V(n+1)) - the original new version generated by PDEBuild F - the function (basically an intelligent binary diff) we generated that we can apply to P(V(n)) to get P(V(n+1)) The approach we take to validate F is the following: 1. Apply F to P(V(n)) on the build server using the same code that is running on the clients. 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice the prime there). So formally, F(P(V(n))) = P(V(n+1))' 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the version originally generated by PDEBuild. 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary directories and perform an MD5 hash on all files, making sure that all files present in one are also present in the other and that their hashes are equal. 5. If applying F to P(V(n)) on the build server using the same code as is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on the server, then it should work on the clients as well. In our implementation, all update site building on the build server was done in Ruby. The effort to implement the server side of this algorithm in Ruby was about three days. The effort to implement the client-side (fully unit-tested, pair-programmed, one pair programming team working on it full-time) in Java was about a month. This was due to the hassle of working with Java input and output streams. However, the result was that the Java code worked entirely in memory, piping input streams into output streams and so on until only the final results were written to disk. Thus, the Java solution would be immune to breakage resulting from something on the file system being changed in a way we did not expect. Let me know if you have any questions. Regards, Dave Orme _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev From NGZw83RUgQCo5vRX@aTpS9YBRvPQjNiNX Thu Apr 26 04:51:46 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mis010-1.exch010.intermedia.net (mis010-1.exch010.intermedia.net [64.78.61.91]) by mail.eclipse.org (Postfix) with SMTP id 0B56923CE7 for ; Thu, 26 Apr 2007 04:51:43 -0400 (EDT) Received: from ehost010-3.exch010.intermedia.net ([64.78.61.55]) by mis010-1.exch010.intermedia.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 01:50:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C787DF.47C11042" Subject: Re: [provisioning-dev] Improved update generation/distribution algorithm Date: Thu, 26 Apr 2007 01:41:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] Improved update generation/distribution algorithm Thread-Index: AceHgAgBxelFqfv3TVSMILKb9qn2jwAXrOhF References: From: "Liebig, Stefan " To: X-OriginalArrivalTime: 26 Apr 2007 08:50:24.0136 (UTC) FILETIME=[EDDB0880:01C787DF] X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 08:51:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C787DF.47C11042 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the approach taken by us = (http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#Smartup_s= oftware_update) is somehow similar. At least we have the same = requirements. Would be nice if we could join our efforts. For that I = will give you a brief outline of our mechanism/algorithm. First our alg. updates resources from V(n) to V(n+delta) with delta>0 in = a single step. Resources might be jars, zips, dlls, docs, ... Since our solution is not (yet) eclipse based we do not have plugin jars = like eclipse has. But this is not a general restriction for our = mechanism. =20 Our mechanism is based on delta encodings = (http://en.wikipedia.org/wiki/Delta_encoding). In our particular case we have decided to use the xdelta alg. = (http://en.wikipedia.org/wiki/Xdelta) which is pretty good usable for = many types of data. However, it performs very bad when =B4diffing=B4 = compressed data like zips and jars. Because of that we unpack zips (in memory) into somthing similar to a = tar and perfom the =B4binary diffing=B4 on the different version of = these =B4tars=B4. The resulting delta (or patch) is then zipped (it = really gets smaller!) and send of the wire. =B4Applying=B4 this delta on = the =B4old=B4 version creates the =B4new=B4 version of the =B4tared=B4 = resource. The resulting version is then converted back into a zip. For this mechanism to work properly it required that versions of = resources can be uniquely identified. For this identification we use a = combination of the resource name and the MD5 hash of the resource. The = resource name is similar to the artifactId in mavens project.xml, i.e. = the name of the resource without any version specific parts in it. =20 The simplified update flow is: - the client gets somehow the information that a resource should be = updated to a newer one - therefore it asks the update server for the delta between the old and = the new version - the update server generates the delta or has it already generated and = cached and sends it back - the client applies this delta to old version and gets the new version This happens for all required resources. =20 Our update server is an active server component realized as a servlet. = It manages all resources in their different versions. The server is = capable of generating deltas in advance and keeping them in a cache for = faster response times. If a requested delta is not available it = generates them on demand. In case that a delta is requested for a =B4very=B4 old version of a = resource which is no longer available on the server (has been removed by = an administrator) the server will respond with a zipped version of the = complete resource. Every delta/patch send to the client has a type that = tells the client how to handle the =B4delta=B4. The situation that the server does not have a base (old) version for = generating a delta may also be the result of the manipulation of a = resource on the client side. The identification for this manipulated = resource (resource name + md5 hash) will most likely not reference a = resource on the server. This case will also result in returning a = complete (zipped) resource. =20 As I already mentioned it seems that Dave and we have similar = requirements but we solve them differently. The challenge will be to = provide with the new provisioning a base where different mechanisms can = be plugged in. There might also be a generalized delta layer in which Daves and our = solution could be plugged in. =20 Comments, questions? Stefan ________________________________ Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Do 26.04.2007 00:22 An: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Betreff: [provisioning-dev] Improved update generation/distribution = algorithm The current feature-based update sites can get huge quickly when small = numbers of changes are scattered across a large number of features. = This kind of situation happens easily when releasing a dot-level or a = patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are = fixed. The purpose of this email is to open a dialog and to outline our = solution. Apologies in advance for those who are less comfortable with = expressing algorithms in formal math. Time constraints have dictated = communication using the most compact and efficient means possible. The algorithm we developed worked as follows: The build server maintains copies of all production versions of the = application. In the general case, then, we need an algorithm to upgrade = a given user from a version V(n) to a version V(n+delta) where delta is = the number of versions that have elapsed since the user last upgraded. = We want this algorithm to have the following properties: * Send a minimal number of bits across the wire=20 * Be as simple as possible=20 * Be verifiably correct. We couldn't afford to have 40k-70k of broken = clients if the algorithm malfunctioned.=20 * Related to the previous: Have safeguards built-in so that if a bad = update site is ever generated, the whole thing fails fast--before *any* = bits are ever sent to clients. You will notice some conflicts in the requirements above. In = particular, the requirement to send the fewest number of bits over the = wire conflicts with the requirements to be as simple as possible and to = be verifiably correct. The result was that our algorithm sacrifices = some efficiency in the number of bits it sends over the wire in order to = be simpler and more verifiably correct. The result: In our application, going from version 1.0.0 to version = 1.0.1 using update site features resulted in about a 10 meg download. = After applying our algorithm, the download size shrunk to about 3 megs. = This is still large for some of our users who utilize a dial-up = connection, but it is doable, whereas the 10 meg download would simply = be prohibitive. Here is the algorithm: First, we simplify the problem. Instead of upgrading users from an = arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to = V(n+1). Going to V(n+delta) is simply an iteration of the algorithm = over delta steps. This simplification works fine for our user = population. If it would be acceptable for the general Eclipse = population is an open question. Second, we notice that sending JAR'd plugins is very expensive. Suppose = only two classes in a large plugin change: the whole plugin must still = be shipped. Our algorithm then is simple. We dynamically generate a function F = where F(P(V(n))) =3D P(V(n+1)). F is really just a zipped collection of = files that encodes just the files that changed between the two plugin = versions. This is accomplished using the following algorithm. For a given plugin = P in two versions V(n) and V(n+1): 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.=20 2. For files that correspond to each other in the two plugins, MD5 hash = them, and if the hashes are different, put the file from P(V(n+1)) into = F.=20 3. Include new files from P(V(n+1)) in F.=20 4. Create a text file manifest listing files in P(V(n)) that are no = longer included in P(V(n+1)) and include that text file in F.=20 5. Package all of the files in F in a zip file. =09 I believe that the algorithm for applying this function F to P(V(n)) to = get a P(V(n+1)) is self-evident. This approach has advantages over binary-diffing the two plugin jars = P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin = changes between versions, a naive binary diff algorithm will not achieve = nearly the same amount of "compression" that we achieve. So we have described a simple algorithm that is able to dramatically = reduce download bandwidth requirements over using update sites. = However, we have not described how we achieved the "fail-fast" = requirement. If a flawed update site is ever generated, we want to = detect this automatically at build time rather than after 50,000 clients = have already downloaded it and broken their installs. Here is the algorithm we use: After a build has completed, we have the following artifacts on our = build server: P(V(n)) - the old version P(V(n+1)) - the original new version generated by PDEBuild F - the function (basically an intelligent binary diff) we generated = that we can apply to P(V(n)) to get P(V(n+1)) The approach we take to validate F is the following: 1. Apply F to P(V(n)) on the build server using the same code that is = running on the clients.=20 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice = the prime there). So formally, F(P(V(n))) =3D P(V(n+1))' =09 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the = version originally generated by PDEBuild.=20 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary = directories and perform an MD5 hash on all files, making sure that all = files present in one are also present in the other and that their hashes = are equal.=20 5. If applying F to P(V(n)) on the build server using the same code as = is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) = on the server, then it should work on the clients as well. =09 In our implementation, all update site building on the build server was = done in Ruby. The effort to implement the server side of this algorithm = in Ruby was about three days. The effort to implement the client-side = (fully unit-tested, pair-programmed, one pair programming team working = on it full-time) in Java was about a month. This was due to the hassle = of working with Java input and output streams. However, the result was = that the Java code worked entirely in memory, piping input streams into = output streams and so on until only the final results were written to = disk. Thus, the Java solution would be immune to breakage resulting = from something on the file system being changed in a way we did not = expect. Let me know if you have any questions. Regards, Dave Orme ------_=_NextPart_001_01C787DF.47C11042 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
I think the = approach taken by us (http://wiki.eclipse.org/index.php/GPW_Lightning_Re= trospectives#Smartup_software_update) is somehow similar. At least = we have the same requirements. Would be nice if we could join our = efforts. For that I will give you a brief outline of our = mechanism/algorithm.
=0A=
First our = alg. updates resources from V(n) to V(n+delta) with delta>0 in a = single step. Resources might be jars, zips, dlls, docs, ...
Since our = solution is not (yet) eclipse based we do not have plugin jars like = eclipse has. But this is not a general restriction for our = mechanism.
=0A=
 
=0A=
Our mechanism = is based on delta encodings (http://en.wikipedia.= org/wiki/Delta_encoding).
In our particular case we have decided = to use the xdelta alg. (http://en.wikipedia.org/wiki= /Xdelta) which is pretty good usable for many types of data. = However, it performs very bad when =B4diffing=B4 compressed data like = zips and jars.
Because of that we unpack zips (in memory) into = somthing similar to a tar and perfom the =B4binary diffing=B4 on the = different version of these =B4tars=B4. The resulting delta (or patch) is = then zipped (it really gets smaller!) and send of the wire. = =B4Applying=B4 this delta on the =B4old=B4 version creates the =B4new=B4 = version of the =B4tared=B4 resource. The resulting version is then = converted back into a zip.
For this mechanism to work properly it = required that versions of resources can be uniquely identified. For this = identification we use a combination of the resource name and the MD5 = hash of the resource. The resource name is similar to the artifactId in = mavens project.xml, i.e. the name of the resource without any version = specific parts in it.
=0A=
 
=0A=
The = simplified update flow is:
- the client gets somehow the information = that a resource should be updated to a newer one
- therefore it asks = the update server for the delta between the old and the new version
- = the update server generates the delta or has it already generated and = cached and sends it back
- the client applies this delta to old = version and gets the new version
=0A=
This happens = for all required resources.
=0A=
 
=0A=
Our update = server is an active server component realized as a servlet. It manages = all resources in their different versions. The server is capable of = generating deltas in advance and keeping them in a cache for faster = response times. If a requested delta is not available it generates them = on demand.
In case that a delta is requested for a =B4very=B4 old = version of a resource which is no longer available on the server (has = been removed by an administrator) the server will respond with a zipped = version of the complete resource. Every delta/patch send to the client = has a type that tells the client how to handle the =B4delta=B4.
The = situation that the server does not have a base (old) version for = generating a delta may also be the result of the manipulation of a = resource on the client side. The identification for this manipulated = resource (resource name + md5 hash) will most likely not reference a = resource on the server. This case will also result in returning a = complete (zipped) resource.
=0A=
 
=0A=
As I already = mentioned it seems that Dave and we have similar requirements but we = solve them differently. The challenge will be to provide with the new = provisioning a base where different mechanisms can be plugged = in.
There might also be a generalized delta layer in which Daves and = our solution could be plugged in.
=0A=
 
=0A=
Comments, = questions?
=0A=

Stefan
=0A=
=0A=
=0A=

=0A=
=0A= Von: = fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. = Orme
Gesendet: Do 26.04.2007 00:22
An: = bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Betreff: [provisioning-dev] = Improved update generation/distribution algorithm

=0A=
The current feature-based update sites can get huge quickly when = small numbers of changes are scattered across a large number of = features.  This kind of situation happens easily when releasing a = dot-level or a patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of = small bugs are fixed.

The purpose of this email is to open a = dialog and to outline our solution.  Apologies in advance for those = who are less comfortable with expressing algorithms in formal = math.  Time constraints have dictated communication using the most = compact and efficient means possible.

The algorithm we developed = worked as follows:

The build server maintains copies of all = production versions of the application.  In the general case, then, = we need an algorithm to upgrade a given user from a version V(n) to a = version V(n+delta) where delta is the number of versions that have = elapsed since the user last upgraded.  We want this algorithm to = have the following properties:
=0A=
    =0A=
  • Send a minimal number of bits across the wire =0A=
  • Be as simple as possible =0A=
  • Be verifiably correct.  We couldn't afford to have 40k-70k of = broken clients if the algorithm malfunctioned. =0A=
  • Related to the previous: Have safeguards built-in so that if a bad = update site is ever generated, the whole thing fails fast--before *any* = bits are ever sent to clients.
You will notice some conflicts = in the requirements above.  In particular, the requirement to send = the fewest number of bits over the wire conflicts with the requirements = to be as simple as possible and to be verifiably correct.  The = result was that our algorithm sacrifices some efficiency in the number = of bits it sends over the wire in order to be simpler and more = verifiably correct.

The result: In our application, going from = version 1.0.0 to version 1.0.1 using update site features resulted in = about a 10 meg download.  After applying our algorithm, the = download size shrunk to about 3 megs.  This is still large for some = of our users who utilize a dial-up connection, but it is doable, whereas = the 10 meg download would simply be prohibitive.

Here is the = algorithm:

First, we simplify the problem.  Instead of = upgrading users from an arbitrary version V(n) to V(n+delta), we only = upgrade them from V(n) to V(n+1).  Going to V(n+delta) is simply an = iteration of the algorithm over delta steps.  This simplification = works fine for our user population.  If it would be acceptable for = the general Eclipse population is an open question.

Second, we = notice that sending JAR'd plugins is very expensive.  Suppose only = two classes in a large plugin change: the whole plugin must still be = shipped.

Our algorithm then is simple.  We dynamically = generate a function F where F(P(V(n))) =3D P(V(n+1)).  F is really = just a zipped collection of files that encodes just the files that = changed between the two plugin versions.

This is accomplished = using the following algorithm.  For a given plugin P in two = versions V(n) and V(n+1):
=0A=
    =0A=
  1. Unpack P(V(n)) and P(V(n+1)) into temporary directories. =0A=
  2. For files that correspond to each other in the two plugins, MD5 hash = them, and if the hashes are different, put the file from P(V(n+1)) into = F. =0A=
  3. Include new files from P(V(n+1)) in F. =0A=
  4. Create a text file manifest listing files in P(V(n)) that are no = longer included in P(V(n+1)) and include that text file in F. =0A=
  5. Package all of the files in F in a zip file.
I believe = that the algorithm for applying this function F to P(V(n)) to get a = P(V(n+1)) is self-evident.

This approach has advantages over = binary-diffing the two plugin jars P(V(n)) and P(V(n+1)): If the order = of the files contained in the plugin changes between versions, a naive = binary diff algorithm will not achieve nearly the same amount of = "compression" that we achieve.

So we have described a simple = algorithm that is able to dramatically reduce download bandwidth = requirements over using update sites.  However, we have not = described how we achieved the "fail-fast" requirement.  If a flawed = update site is ever generated, we want to detect this automatically at = build time rather than after 50,000 clients have already downloaded it = and broken their installs.

Here is the algorithm we = use:

After a build has completed, we have the following artifacts = on our build server:

P(V(n)) - the old version
P(V(n+1)) - the = original new version generated by PDEBuild
F - the function = (basically an intelligent binary diff) we generated that we can apply to = P(V(n)) to get P(V(n+1))

The approach we take to validate F is = the following:
=0A=
    =0A=
  1. Apply F to P(V(n)) on the build server using the same code that is = running on the clients. =0A=
  2. Let's call the result of applying F to P(V(n)), P(V(n+1))'  = (notice the prime there).  So formally, F(P(V(n))) =3D = P(V(n+1))'
    =0A=
  3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the = version originally generated by PDEBuild. =0A=
  4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary = directories and perform an MD5 hash on all files, making sure that all = files present in one are also present in the other and that their hashes = are equal. =0A=
  5. If applying F to P(V(n)) on the build server using the same code as = is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) = on the server, then it should work on the clients as = well.
In our implementation, all update site building on = the build server was done in Ruby.  The effort to implement the = server side of this algorithm in Ruby was about three days.  The = effort to implement the client-side (fully unit-tested, pair-programmed, = one pair programming team working on it full-time) in Java was about a = month.  This was due to the hassle of working with Java input and = output streams.  However, the result was that the Java code worked = entirely in memory, piping input streams into output streams and so on = until only the final results were written to disk.  Thus, the Java = solution would be immune to breakage resulting from something on the = file system being changed in a way we did not expect.

Let me know = if you have any questions.


Regards,

Dave = Orme

------_=_NextPart_001_01C787DF.47C11042-- From L4z5JpgB9u8VG8O1@Yp5HW06labJ8PMwQ Thu Apr 26 09:54:03 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from peanut.coconut-palm-software.com (coconut-palm-software.com [64.81.137.6]) by mail.eclipse.org (Postfix) with SMTP id DB29C247B7 for ; Thu, 26 Apr 2007 09:54:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by peanut.coconut-palm-software.com (Postfix) with ESMTP id 502D317B8ECD; Thu, 26 Apr 2007 09:48:27 -0500 (CDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Apr 26 09:48:26 2007 X-DSPAM-Confidence: 0.6768 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4630bbba318129363443463 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.187, BAYES_00=-2.599, DSPAM_HAM=-0.1, HTML_MESSAGE=0.001] Received: from peanut.coconut-palm-software.com ([127.0.0.1]) by localhost (peanut.coconut-palm-software.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBkE9EbTxv4j; Thu, 26 Apr 2007 09:48:25 -0500 (CDT) Received: from peanut.coconut-palm-software.com (peanut.coconut-palm-software.com [192.168.0.11]) by peanut.coconut-palm-software.com (Postfix) with ESMTP id 89E1E17B8EC9; Thu, 26 Apr 2007 09:48:25 -0500 (CDT) Message-ID: Date: Thu, 26 Apr 2007 09:48:25 -0500 (CDT) From: "David J. Orme" To: PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI, Developer discussions for provisioning Subject: Re: [provisioning-dev] Improved update generation/distribution algorithm In-Reply-To: <010a01c78793$c4368c80$0dfbfdc0@computer> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1259_8033651.1177598905432" Cc: X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 13:54:04 -0000 ------=_Part_1259_8033651.1177598905432 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Phillippe,=20 I'm cleared by this client to contribute UI stuff to JFace, but not update = manager code. It's a month or two process to get clearance through their le= gal department. For a single code contribution, this was not judged to be a= n efficient use of peoples' time. Sorry.=20 However, writing my own description of what we did is certainly fine.=20 Regards,=20 Dave=20 ----- Original Message -----=20 From: Philippe Ombredanne =20 To: Developer discussions for provisioning (Update Manager)initiatives =20 Sent: Wednesday, April 25, 2007 6:45:00 PM GMT-0800=20 Subject: RE: [provisioning-dev] Improved update generation/distribution alg= orithm=20 Message=20 Hi David:=20 Mighty interesting!=20 Would the code be availabel somewhere for review?=20 Cordially=20 --=20 Cheers=20 Philippe=20 http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf=20 -----Original Message-----=20 From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg [mailto:provisioning-dev-bounces= @eclipse.org] On Behalf Of David J. Orme=20 Sent: Wednesday, April 25, 2007 3:23 PM=20 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg=20 Subject: [provisioning-dev] Improved update generation/distribution algorit= hm=20 The current feature-based update sites can get huge quickly when small numb= ers of changes are scattered across a large number of features. This kind o= f situation happens easily when releasing a dot-level or a patchlevel upgra= de--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed.=20 The purpose of this email is to open a dialog and to outline our solution. = Apologies in advance for those who are less comfortable with expressing alg= orithms in formal math. Time constraints have dictated communication using = the most compact and efficient means possible.=20 The algorithm we developed worked as follows:=20 The build server maintains copies of all production versions of the applica= tion. In the general case, then, we need an algorithm to upgrade a given us= er from a version V(n) to a version V(n+delta) where delta is the number of= versions that have elapsed since the user last upgraded. We want this algo= rithm to have the following properties:=20 =E2=80=A2 Send a minimal number of bits across the wire=20 =E2=80=A2 Be as simple as possible=20 =E2=80=A2 Be verifiably correct. We couldn't afford to have 40k-70k of = broken clients if the algorithm malfunctioned.=20 =E2=80=A2 Related to the previous: Have safeguards built-in so that if = a bad update site is ever generated, the whole thing fails fast--before *an= y* bits are ever sent to clients.=20 You will notice some conflicts in the requirements above. In particular, th= e requirement to send the fewest number of bits over the wire conflicts wit= h the requirements to be as simple as possible and to be verifiably correct= . The result was that our algorithm sacrifices some efficiency in the numbe= r of bits it sends over the wire in order to be simpler and more verifiably= correct.=20 The result: In our application, going from version 1.0.0 to version 1.0.1 u= sing update site features resulted in about a 10 meg download. After applyi= ng our algorithm, the download size shrunk to about 3 megs. This is still l= arge for some of our users who utilize a dial-up connection, but it is doab= le, whereas the 10 meg download would simply be prohibitive.=20 Here is the algorithm:=20 First, we simplify the problem. Instead of upgrading users from an arbitrar= y version V(n) to V(n+delta), we only upgrade them from V(n) to V(n+1). Goi= ng to V(n+delta) is simply an iteration of the algorithm over delta steps. = This simplification works fine for our user population. If it would be acce= ptable for the general Eclipse population is an open question.=20 Second, we notice that sending JAR'd plugins is very expensive. Suppose onl= y two classes in a large plugin change: the whole plugin must still be ship= ped.=20 Our algorithm then is simple. We dynamically generate a function F where F(= P(V(n))) =3D P(V(n+1)). F is really just a zipped collection of files that = encodes just the files that changed between the two plugin versions.=20 This is accomplished using the following algorithm. For a given plugin P in= two versions V(n) and V(n+1):=20 2. Unpack P(V(n)) and P(V(n+1)) into temporary directories.=20 3. For files that correspond to each other in the two plugins, MD5 hash= them, and if the hashes are different, put the file from P(V(n+1)) into F.= =20 4. Include new files from P(V(n+1)) in F.=20 5. Create a text file manifest listing files in P(V(n)) that are no lon= ger included in P(V(n+1)) and include that text file in F.=20 6. Package all of the files in F in a zip file.=20 I believe that the algorithm for applying this function F to P(V(n)) to get= a P(V(n+1)) is self-evident.=20 This approach has advantages over binary-diffing the two plugin jars P(V(n)= ) and P(V(n+1)): If the order of the files contained in the plugin changes = between versions, a naive binary diff algorithm will not achieve nearly the= same amount of "compression" that we achieve.=20 So we have described a simple algorithm that is able to dramatically reduce= download bandwidth requirements over using update sites. However, we have = not described how we achieved the "fail-fast" requirement. If a flawed upda= te site is ever generated, we want to detect this automatically at build ti= me rather than after 50,000 clients have already downloaded it and broken t= heir installs.=20 Here is the algorithm we use:=20 After a build has completed, we have the following artifacts on our build s= erver:=20 P(V(n)) - the old version=20 P(V(n+1)) - the original new version generated by PDEBuild=20 F - the function (basically an intelligent binary diff) we generated that w= e can apply to P(V(n)) to get P(V(n+1))=20 The approach we take to validate F is the following:=20 2. Apply F to P(V(n)) on the build server using the same code that is r= unning on the clients.=20 3. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice t= he prime there). So formally, F(P(V(n))) =3D P(V(n+1))'=20 4. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the versi= on originally generated by PDEBuild.=20 5. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary= directories and perform an MD5 hash on all files, making sure that all fil= es present in one are also present in the other and that their hashes are e= qual.=20 6. If applying F to P(V(n)) on the build server using the same code as = is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on t= he server, then it should work on the clients as well.=20 In our implementation, all update site building on the build server was don= e in Ruby. The effort to implement the server side of this algorithm in Rub= y was about three days. The effort to implement the client-side (fully unit= -tested, pair-programmed, one pair programming team working on it full-time= ) in Java was about a month. This was due to the hassle of working with Jav= a input and output streams. However, the result was that the Java code work= ed entirely in memory, piping input streams into output streams and so on u= ntil only the final results were written to disk. Thus, the Java solution w= ould be immune to breakage resulting from something on the file system bein= g changed in a way we did not expect.=20 Let me know if you have any questions.=20 Regards,=20 Dave Orme=20 ------=_Part_1259_8033651.1177598905432 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Phillippe,

I'm cleared by this client to contribute UI stuff to JFace, but not update manager code.  It's a month or two process to get clearance through their legal department.  For a single code contribution, this was not judged to be an efficient use of peoples' time.  Sorry.

However, writing my own description of what we did is certainly fine.


Regards,

Dave
----- Original Message -----
From: Philippe Ombredanne <PzxQY3dtp+oFL0+H@RgofA6Na+BoXv9wI>
To: Developer discussions for provisioning (Update Manager)initiatives <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>
Sent: Wednesday, April 25, 2007 6:45:00 PM GMT-0800
Subject: RE: [provisioning-dev] Improved update generation/distribution algorithm

Message
Hi David:
Mighty interesting!
Would the code be availabel somewhere for review?
Cordially
 


--
Cheers
Philippe
http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf



-----Original Message-----
From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of David J. Orme
Sent: Wednesday, April 25, 2007 3:23 PM
To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Subject: [provisioning-dev] Improved update generation/distribution algorithm

The current feature-based update sites can get huge quickly when small numbers of changes are scattered across a large number of features.  This kind of situation happens easily when releasing a dot-level or a patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed.

The purpose of this email is to open a dialog and to outline our solution.  Apologies in advance for those who are less comfortable with expressing algorithms in formal math.  Time constraints have dictated communication using the most compact and efficient means possible.

The algorithm we developed worked as follows:

The build server maintains copies of all production versions of the application.  In the general case, then, we need an algorithm to upgrade a given user from a version V(n) to a version V(n+delta) where delta is the number of versions that have elapsed since the user last upgraded.  We want this algorithm to have the following properties:
  • Send a minimal number of bits across the wire
  • Be as simple as possible
  • Be verifiably correct.  We couldn't afford to have 40k-70k of broken clients if the algorithm malfunctioned.
  • Related to the previous: Have safeguards built-in so that if a bad update site is ever generated, the whole thing fails fast--before *any* bits are ever sent to clients.
You will notice some conflicts in the requirements above.  In particular, the requirement to send the fewest number of bits over the wire conflicts with the requirements to be as simple as possible and to be verifiably correct.  The result was that our algorithm sacrifices some efficiency in the number of bits it sends over the wire in order to be simpler and more verifiably correct.

The result: In our application, going from version 1.0.0 to version 1.0.1 using update site features resulted in about a 10 meg download.  After applying our algorithm, the download size shrunk to about 3 megs.  This is still large for some of our users who utilize a dial-up connection, but it is doable, whereas the 10 meg download would simply be prohibitive.

Here is the algorithm:

First, we simplify the problem.  Instead of upgrading users from an arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to V(n+1).  Going to V(n+delta) is simply an iteration of the algorithm over delta steps.  This simplification works fine for our user population.  If it would be acceptable for the general Eclipse population is an open question.

Second, we notice that sending JAR'd plugins is very expensive.  Suppose only two classes in a large plugin change: the whole plugin must still be shipped.

Our algorithm then is simple.  We dynamically generate a function F where F(P(V(n))) = P(V(n+1)).  F is really just a zipped collection of files that encodes just the files that changed between the two plugin versions.

This is accomplished using the following algorithm.  For a given plugin P in two versions V(n) and V(n+1):
  1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.
  2. For files that correspond to each other in the two plugins, MD5 hash them, and if the hashes are different, put the file from P(V(n+1)) into F.
  3. Include new files from P(V(n+1)) in F.
  4. Create a text file manifest listing files in P(V(n)) that are no longer included in P(V(n+1)) and include that text file in F.
  5. Package all of the files in F in a zip file.
I believe that the algorithm for applying this function F to P(V(n)) to get a P(V(n+1)) is self-evident.

This approach has advantages over binary-diffing the two plugin jars P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin changes between versions, a naive binary diff algorithm will not achieve nearly the same amount of "compression" that we achieve.

So we have described a simple algorithm that is able to dramatically reduce download bandwidth requirements over using update sites.  However, we have not described how we achieved the "fail-fast" requirement.  If a flawed update site is ever generated, we want to detect this automatically at build time rather than after 50,000 clients have already downloaded it and broken their installs.

Here is the algorithm we use:

After a build has completed, we have the following artifacts on our build server:

P(V(n)) - the old version
P(V(n+1)) - the original new version generated by PDEBuild
F - the function (basically an intelligent binary diff) we generated that we can apply to P(V(n)) to get P(V(n+1))

The approach we take to validate F is the following:
  1. Apply F to P(V(n)) on the build server using the same code that is running on the clients.
  2. Let's call the result of applying F to P(V(n)), P(V(n+1))'  (notice the prime there).  So formally, F(P(V(n))) = P(V(n+1))'
  3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the version originally generated by PDEBuild.
  4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary directories and perform an MD5 hash on all files, making sure that all files present in one are also present in the other and that their hashes are equal.
  5. If applying F to P(V(n)) on the build server using the same code as is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on the server, then it should work on the clients as well.
In our implementation, all update site building on the build server was done in Ruby.  The effort to implement the server side of this algorithm in Ruby was about three days.  The effort to implement the client-side (fully unit-tested, pair-programmed, one pair programming team working on it full-time) in Java was about a month.  This was due to the hassle of working with Java input and output streams.  However, the result was that the Java code worked entirely in memory, piping input streams into output streams and so on until only the final results were written to disk.  Thus, the Java solution would be immune to breakage resulting from something on the file system being changed in a way we did not expect.

Let me know if you have any questions.


Regards,

Dave Orme

------=_Part_1259_8033651.1177598905432-- From L4z5JpgB9u8VG8O1@Yp5HW06labJ8PMwQ Thu Apr 26 10:33:53 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from peanut.coconut-palm-software.com (coconut-palm-software.com [64.81.137.6]) by mail.eclipse.org (Postfix) with SMTP id 4893324024 for ; Thu, 26 Apr 2007 10:33:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by peanut.coconut-palm-software.com (Postfix) with ESMTP id B4E9B17B8EC9 for ; Thu, 26 Apr 2007 10:28:14 -0500 (CDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Apr 26 10:28:13 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4630c50d151592008015569 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1, HTML_30_40=0.374, HTML_MESSAGE=0.001] Received: from peanut.coconut-palm-software.com ([127.0.0.1]) by localhost (peanut.coconut-palm-software.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZVCGoHs2CjW for ; Thu, 26 Apr 2007 10:28:12 -0500 (CDT) Received: from peanut.coconut-palm-software.com (peanut.coconut-palm-software.com [192.168.0.11]) by peanut.coconut-palm-software.com (Postfix) with ESMTP id A57EF17B8E62 for ; Thu, 26 Apr 2007 10:28:12 -0500 (CDT) Message-ID: Date: Thu, 26 Apr 2007 10:28:12 -0500 (CDT) From: "David J. Orme" To: Developer discussions for provisioning Subject: Re: [provisioning-dev] Improved update generation/distribution algorithm In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1262_10845621.1177601292507" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 14:33:53 -0000 ------=_Part_1262_10845621.1177601292507 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Pascal, Excellent questions! - From the description, it seems that the server can be a directory or a plain http server (or any other form of "dumb" server), am I correct? We use a plain HTTP server and Apache HTTPClient on the client side. Anything that can copy files will work. - Is the size of the update site ever an issue? For us, no. We use a separate physical build server and update site server. For a project like Eclipse, this is a good question, since an algorithm like this would be required to eventually keep terabytes of information around in order to generate diffs. This is one reason we decided to only support upgrading between adjacent versions. Adding 3 megs of overhead per version isn't bad. But that number goes up exponentially if you want to support upgrading to an arbitrary V(n+delta). - With a server that could run code, have you considered the generation of the deltas on the fly given what the client has? Well, there is an exponential growth in the number of differences you could have for V(n+delta) as delta gets big. So you can't test all possibilities of delta. I guess if you run the test at build time and build on the fly--when a user requests an update for a specific value of delta--maybe this doesn't matter. You just test for the set of deltas that you've actually generated. - Have you identified the threshold in the size of the delta where it would be more effective to send the full file? We didn't. Our system is a CRM system that is used every day by most of our users. We figured it wasn't bad to penalize the few folks that didn't stay up to date. :-) - The application of F on the client seems to be pretty memory intensive. Could you characterize the complexity of F in terms of memory? We only process a single file at a time out of the ZipInputStream. So the upper bound of RAM is whatever is required to decompress a file and write it to disk plus the size of a HashMap of all file paths in P(V(n)). So the algorithm on the client is: 1. Populate a Set with file paths in P(V(n)). 2. For each file in the ZipInputStream: if the file is the deletion manifest, remove all entries it lists from the file path Set ; else copy the file from the ZipInputStream into the JarOutputStream of the new plugin, then remove its path from the Set . (If the file is not in the Set , it's a new file and no extra processing is required.) 3. After this loop, any files remaining in the Set are the same from last time and are copied from the old plugin JAR P(V(n)) to the new plugin JAR P(V(n+1)). - Even though you verify the content of the server, there are always many things that can go wrong. So on the client how do you ensure that F(P(V(n))) is equal to P(V(n+1)). What about shipping a checksum of the expected result after the merge? One property of this algorithm is that it doesn't guarantee that the order of the elements inside the JAR are the same after the merge. So you can't just MD5 hash the two JARs and compare them. As long as the update apply code is identical on client and server, the only things that can go wrong are things that are otherwise detectable or are out of our control anyway. If the disk fills up, we can detect that. If solar radiation or an EMP bomb hits the computer, we've got much worse problems than we can detect and deal with anyway. The problem I forsee will occur when we want to upgrade the code that applies updates. It would be advantageous to change the implementation so that it guarantees that file orders within the JAR files so that a checksum could be sent and used to verify the update at the client as well. But then you've got an O(n) lookup algorithm in a ListSet rather than an O(1) lookup algorithm in our existing HashSet. Maybe we don't care. Maybe O(n)*number of plugins is fast enough and we optimized prematurely. It's an interesting open question, at the least. - Do you handle signed jars? Not in our implementation. - In your example, you say that 3M is still large? Why do you think so, are the actual changes smaller? Why don't you ship the delta of each files instead of each complete file? 3M is still a pretty long download for a modem, but it's not horrible. We could ship a delta of the individual classes (binary diff the actual class files too) but we chose not to do that because we decided that 3M was small enough and the extra complexity (and possibility of bugs) was not worth the potential gain for our use-case. - How do you see that fit with the concept of artifact repository developed in equinox and our attempt to use a mirroring metaphor instead of download? This is a way to mirror new versions of plugins between repositories using minimal bandwidth with reasonable assurances of correctness. "David J. Orme" To Sent by: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg provisioning-dev- cc B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM rg Subject [provisioning-dev] Improved update generation/distribution algorithm 04/25/2007 06:22 PM Please respond to "Developer discussions for provisioning \(Update Manager\) initiatives" The current feature-based update sites can get huge quickly when small numbers of changes are scattered across a large number of features. This kind of situation happens easily when releasing a dot-level or a patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed. The purpose of this email is to open a dialog and to outline our solution. Apologies in advance for those who are less comfortable with expressing algorithms in formal math. Time constraints have dictated communication using the most compact and efficient means possible. The algorithm we developed worked as follows: The build server maintains copies of all production versions of the application. In the general case, then, we need an algorithm to upgrade a given user from a version V(n) to a version V(n+delta) where delta is the number of versions that have elapsed since the user last upgraded. We want this algorithm to have the following properties: Send a minimal number of bits across the wire Be as simple as possible Be verifiably correct. We couldn't afford to have 40k-70k of broken clients if the algorithm malfunctioned. Related to the previous: Have safeguards built-in so that if a bad update site is ever generated, the whole thing fails fast--before *any* bits are ever sent to clients. You will notice some conflicts in the requirements above. In particular, the requirement to send the fewest number of bits over the wire conflicts with the requirements to be as simple as possible and to be verifiably correct. The result was that our algorithm sacrifices some efficiency in the number of bits it sends over the wire in order to be simpler and more verifiably correct. The result: In our application, going from version 1.0.0 to version 1.0.1 using update site features resulted in about a 10 meg download. After applying our algorithm, the download size shrunk to about 3 megs. This is still large for some of our users who utilize a dial-up connection, but it is doable, whereas the 10 meg download would simply be prohibitive. Here is the algorithm: First, we simplify the problem. Instead of upgrading users from an arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to V(n+1). Going to V(n+delta) is simply an iteration of the algorithm over delta steps. This simplification works fine for our user population. If it would be acceptable for the general Eclipse population is an open question. Second, we notice that sending JAR'd plugins is very expensive. Suppose only two classes in a large plugin change: the whole plugin must still be shipped. Our algorithm then is simple. We dynamically generate a function F where F(P(V(n))) = P(V(n+1)). F is really just a zipped collection of files that encodes just the files that changed between the two plugin versions. This is accomplished using the following algorithm. For a given plugin P in two versions V(n) and V(n+1): 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories. 2. For files that correspond to each other in the two plugins, MD5 hash them, and if the hashes are different, put the file from P(V(n+1)) into F. 3. Include new files from P(V(n+1)) in F. 4. Create a text file manifest listing files in P(V(n)) that are no longer included in P(V(n+1)) and include that text file in F. 5. Package all of the files in F in a zip file. I believe that the algorithm for applying this function F to P(V(n)) to get a P(V(n+1)) is self-evident. This approach has advantages over binary-diffing the two plugin jars P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin changes between versions, a naive binary diff algorithm will not achieve nearly the same amount of "compression" that we achieve. So we have described a simple algorithm that is able to dramatically reduce download bandwidth requirements over using update sites. However, we have not described how we achieved the "fail-fast" requirement. If a flawed update site is ever generated, we want to detect this automatically at build time rather than after 50,000 clients have already downloaded it and broken their installs. Here is the algorithm we use: After a build has completed, we have the following artifacts on our build server: P(V(n)) - the old version P(V(n+1)) - the original new version generated by PDEBuild F - the function (basically an intelligent binary diff) we generated that we can apply to P(V(n)) to get P(V(n+1)) The approach we take to validate F is the following: 1. Apply F to P(V(n)) on the build server using the same code that is running on the clients. 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice the prime there). So formally, F(P(V(n))) = P(V(n+1))' 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the version originally generated by PDEBuild. 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary directories and perform an MD5 hash on all files, making sure that all files present in one are also present in the other and that their hashes are equal. 5. If applying F to P(V(n)) on the build server using the same code as is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on the server, then it should work on the clients as well. In our implementation, all update site building on the build server was done in Ruby. The effort to implement the server side of this algorithm in Ruby was about three days. The effort to implement the client-side (fully unit-tested, pair-programmed, one pair programming team working on it full-time) in Java was about a month. This was due to the hassle of working with Java input and output streams. However, the result was that the Java code worked entirely in memory, piping input streams into output streams and so on until only the final results were written to disk. Thus, the Java solution would be immune to breakage resulting from something on the file system being changed in a way we did not expect. Let me know if you have any questions. Regards, Dave Orme _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev ------=_Part_1262_10845621.1177601292507 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Pascal,

Excellent questions!

- From the descri= ption, it seems that the server can be a directory or a
plain http serve= r (or any other form of "dumb" server), am I correct?

We use a plain= HTTP server and Apache HTTPClient on the client side.

Anything that= can copy files will work.

- Is the size of the update site ever an = issue?

For us, no.  We use a separate physical build server and= update site server.  For a project like Eclipse, this is a good quest= ion, since an algorithm like this would be required to eventually keep tera= bytes of information around in order to generate diffs.  This is one r= eason we decided to only support upgrading between adjacent versions. = Adding 3 megs of overhead per version isn't bad.  But that number goe= s up exponentially if you want to support upgrading to an arbitrary V(n+del= ta).

- With a server that could run code, have you considered the ge= neration of
the deltas on the fly given what the client has?

Well= , there is an exponential growth in the number of differences you could hav= e for V(n+delta) as delta gets big.  So you can't test all possibiliti= es of delta.  I guess if you run the test at build time and build on t= he fly--when a user requests an update for a specific value of delta--maybe= this doesn't matter.  You just test for the set of deltas that you've= actually generated.

- Have you identified the threshold in the size= of the delta where it would
be more effective to send the full file?
We didn't.  Our system is a CRM system that is used every day by = most of our users.  We figured it wasn't bad to penalize the few folks= that didn't stay up to date. :-)

- The application of F on the clie= nt seems to be pretty memory intensive.
Could you characterize the compl= exity of F in terms of memory?

We only process a single file at a ti= me out of the ZipInputStream.  So the upper bound of RAM is whatever i= s required to decompress a file and write it to disk plus the size of a Has= hMap of all file paths in P(V(n)).  So the algorithm on the client is:=
  1. Populate a Set with file paths in P(V(n)).
  2. For each fil= e in the ZipInputStream: if the file is the deletion manifest, remove all e= ntries it lists from the file path Set; else copy the file from the ZipInpu= tStream into the JarOutputStream of the new plugin, then remove its path fr= om the Set.  (If the file is not in the Set, it's a new file and no ex= tra processing is required.)
  3. After this loop, any files remaining i= n the Set are the same from last time and are copied from the old plugin JA= R P(V(n)) to the new plugin JAR P(V(n+1)).
- Even though you = verify the content of the server, there are always many
things that can = go wrong. So on the client how do you ensure that
F(P(V(n))) is equal to= P(V(n+1)). What about shipping a checksum of the
expected result after = the merge?

One property of this algorithm is that it doesn't guarant= ee that the order of the elements inside the JAR are the same after the mer= ge.  So you can't just MD5 hash the two JARs and compare them.

= As long as the update apply code is identical on client and server, the onl= y things that can go wrong are things that are otherwise detectable or are = out of our control anyway.  If the disk fills up, we can detect that.&= nbsp; If solar radiation or an EMP bomb hits the computer, we've got much w= orse problems than we can detect and deal with anyway.

The problem I= forsee will occur when we want to upgrade the code that applies updates.&n= bsp; It would be advantageous to change the implementation so that it guara= ntees that file orders within the JAR files so that a checksum could be sen= t and used to verify the update at the client as well.  But then you'v= e got an O(n) lookup algorithm in a ListSet rather than an O(1) lookup algo= rithm in our existing HashSet.  Maybe we don't care.  Maybe O(n)*= number of plugins is fast enough and we optimized prematurely.  It's a= n interesting open question, at the least.

- Do you handle signed ja= rs?

Not in our implementation.

- In your example, you say tha= t 3M is still large? Why do you think so, are
the actual changes smaller= ? Why don't you ship the delta of each files
instead of each complete fi= le?

3M is still a pretty long download for a modem, but it's not hor= rible.

We could ship a delta of the individual classes (binary diff = the actual class files too) but we chose not to do that because we decided = that 3M was small enough and the extra complexity (and possibility of bugs)= was not worth the potential gain for our use-case.

- How do you see= that fit with the concept of artifact repository developed
in equinox a= nd our attempt to use a mirroring metaphor instead of download?

This= is a way to mirror new versions of plugins between repositories using mini= mal bandwidth with reasonable assurances of correctness.


 &= nbsp;                    =                     &nbs= p;                     &n= bsp;        
         &nbs= p;   "David J. Orme"               =                      = ;          
         =     <djo@coconut-palm            = ;                     &nb= sp;          
        = ;     -software.com>            =                     &nbs= p;           To
       &nb= sp;     Sent by:              =    bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg        
&= nbsp;            provisioning-dev-   &nb= sp;                     &= nbsp;                cc
 &= nbsp;           B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM     &n= bsp;                     =                  
 &n= bsp;           rg         &nbs= p;                     &n= bsp;                    S= ubject
                 &n= bsp;                     = [provisioning-dev] Improved update  
       &nb= sp;                     &= nbsp;         generation/distribution algorithm   =
             04/25/2007 06:22  =                     &nbs= p;                     &n= bsp;
             PM     &n= bsp;                     =                      = ;            
       &= nbsp;                    =                     &nbs= p;                     &n= bsp;  
               &nbs= p;                     &n= bsp;                     =                
   &n= bsp;         Please respond to       &nb= sp;                     &= nbsp;              
   &nb= sp;            "Developer      = ;                     &nb= sp;                     <= br>              discussions for &n= bsp;                     =                      = ;  
               provisio= ning                     =                      = ;      
             &= nbsp;   \(Update               &nbs= p;                     &n= bsp;            
      = ;           Manager\)         =                      = ;                  
 =               initiatives"    =                     &nbs= p;                     &n= bsp;
             <provisioning-de= v                     &nb= sp;                     &= nbsp;
               @eclipse.o= rg>                    = ;                     &nb= sp;    
              = ;                     &nb= sp;                     &= nbsp;                
 &nb= sp;                     &= nbsp;                    =                     &nbs= p;        




The current feature-base= d update sites can get huge quickly when small
numbers of changes are sc= attered across a large number of features.  This
kind of situation = happens easily when releasing a dot-level or a patchlevel
upgrade--ie: 1= .0.0 to 1.0.1--where lots of small bugs are fixed.

The purpose of th= is email is to open a dialog and to outline our solution.
Apologies in a= dvance for those who are less comfortable with expressing
algorithms in = formal math.  Time constraints have dictated communication
using th= e most compact and efficient means possible.

The algorithm we develo= ped worked as follows:

The build server maintains copies of all prod= uction versions of the
application.  In the general case, then, we = need an algorithm to upgrade a
given user from a version V(n) to a versi= on V(n+delta) where delta is the
number of versions that have elapsed si= nce the user last upgraded.  We want
this algorithm to have the fol= lowing properties:
      Send a minimal number of bi= ts across the wire
      Be as simple as possible      Be verifiably correct.  We couldn't afford = to have 40k-70k of broken
      clients if the algor= ithm malfunctioned.
      Related to the previous: H= ave safeguards built-in so that if a bad
      updat= e site is ever generated, the whole thing fails fast--before
  = ;    *any* bits are ever sent to clients.
You will notice some= conflicts in the requirements above.  In particular,
the requireme= nt to send the fewest number of bits over the wire conflicts
with the re= quirements to be as simple as possible and to be verifiably
correct. &nb= sp;The result was that our algorithm sacrifices some efficiency in
the n= umber of bits it sends over the wire in order to be simpler and more
ver= ifiably correct.

The result: In our application, going from version = 1.0.0 to version 1.0.1
using update site features resulted in about a 10= meg download.  After
applying our algorithm, the download size shr= unk to about 3 megs.  This is
still large for some of our users who= utilize a dial-up connection, but it
is doable, whereas the 10 meg down= load would simply be prohibitive.

Here is the algorithm:

Firs= t, we simplify the problem.  Instead of upgrading users from an
arb= itrary version V(n) to V(n+delta), we only upgrade them from V(n) to
V(n= +1).  Going to V(n+delta) is simply an iteration of the algorithm over=
delta steps.  This simplification works fine for our user populati= on.  If
it would be acceptable for the general Eclipse population i= s an open
question.

Second, we notice that sending JAR'd plugins = is very expensive.  Suppose
only two classes in a large plugin chan= ge: the whole plugin must still be
shipped.

Our algorithm then is= simple.  We dynamically generate a function F where
F(P(V(n))) =3D= P(V(n+1)).  F is really just a zipped collection of files that
enc= odes just the files that changed between the two plugin versions.

Th= is is accomplished using the following algorithm.  For a given plugin = P
in two versions V(n) and V(n+1):
   1. Unpack P(V(n)) and= P(V(n+1)) into temporary directories.
   2. For files that co= rrespond to each other in the two plugins, MD5 hash
     =  them, and if the hashes are different, put the file from P(V(n+1))      into F.
   3. Include new files fro= m P(V(n+1)) in F.
   4. Create a text file manifest listing fi= les in P(V(n)) that are no
      longer included in = P(V(n+1)) and include that text file in F.
   5. Package all o= f the files in F in a zip file.
I believe that the algorithm for applyin= g this function F to P(V(n)) to get
a P(V(n+1)) is self-evident.

= This approach has advantages over binary-diffing the two plugin jars
P(V= (n)) and P(V(n+1)): If the order of the files contained in the plugin
ch= anges between versions, a naive binary diff algorithm will not achieve
n= early the same amount of "compression" that we achieve.

So we have d= escribed a simple algorithm that is able to dramatically reduce
download= bandwidth requirements over using update sites.  However, we have
= not described how we achieved the "fail-fast" requirement.  If a flawe= d
update site is ever generated, we want to detect this automatically at=
build time rather than after 50,000 clients have already downloaded it = and
broken their installs.

Here is the algorithm we use:

A= fter a build has completed, we have the following artifacts on our buildserver:

P(V(n)) - the old version
P(V(n+1)) - the original new v= ersion generated by PDEBuild
F - the function (basically an intelligent = binary diff) we generated that
we can apply to P(V(n)) to get P(V(n+1))<= br>
The approach we take to validate F is the following:
  = 1. Apply F to P(V(n)) on the build server using the same code that is
&= nbsp;     running on the clients.
   2. Let's c= all the result of applying F to P(V(n)), P(V(n+1))'  (notice
 =      the prime there).  So formally, F(P(V(n))) =3D P(V= (n+1))'
   3. We need to prove that P(V(n+1))' is the same as = P(V(n+1)), the
      version originally generated by= PDEBuild.
   4. To do this, we simply unpack P(V(n+1))' and P= (V(n+1)) into temporary
      directories and perfor= m an MD5 hash on all files, making sure that
      a= ll files present in one are also present in the other and that their
&nb= sp;     hashes are equal.
   5. If applying F t= o P(V(n)) on the build server using the same code as
    =  is running on the clients produces a P(V(n+1))' identical to
&nbs= p;     P(V(n+1)) on the server, then it should work on the c= lients as well.
In our implementation, all update site building on the b= uild server was
done in Ruby.  The effort to implement the server s= ide of this algorithm in
Ruby was about three days.  The effort to = implement the client-side (fully
unit-tested, pair-programmed, one pair = programming team working on it
full-time) in Java was about a month. &nb= sp;This was due to the hassle of
working with Java input and output stre= ams.  However, the result was that
the Java code worked entirely in= memory, piping input streams into output
streams and so on until only t= he final results were written to disk.  Thus,
the Java solution wou= ld be immune to breakage resulting from something on
the file system bei= ng changed in a way we did not expect.

Let me know if you have any q= uestions.


Regards,

Dave Orme
_________________________= ______________________
provisioning-dev mailing list
provisioning-dev= @eclipse.org
https://dev.eclipse.org/mailman/listinfo/provisioning-dev

_______________________________________________
provisioning-d= ev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/= mailman/listinfo/provisioning-dev
------=_Part_1262_10845621.1177601292507-- From L4z5JpgB9u8VG8O1@Yp5HW06labJ8PMwQ Thu Apr 26 10:44:54 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from peanut.coconut-palm-software.com (coconut-palm-software.com [64.81.137.6]) by mail.eclipse.org (Postfix) with SMTP id 9D15F23474 for ; Thu, 26 Apr 2007 10:44:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by peanut.coconut-palm-software.com (Postfix) with ESMTP id A276717B8EC9 for ; Thu, 26 Apr 2007 10:39:21 -0500 (CDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Apr 26 10:39:20 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4630c7a8257512008015569 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=-0.488, BAYES_00=-2.599, DSPAM_HAM=-0.1, HTML_10_20=1.351, HTML_MESSAGE=0.001] Received: from peanut.coconut-palm-software.com ([127.0.0.1]) by localhost (peanut.coconut-palm-software.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSSW6F6z8jqG for ; Thu, 26 Apr 2007 10:39:19 -0500 (CDT) Received: from peanut.coconut-palm-software.com (peanut.coconut-palm-software.com [192.168.0.11]) by peanut.coconut-palm-software.com (Postfix) with ESMTP id 77BE917B8E62 for ; Thu, 26 Apr 2007 10:39:19 -0500 (CDT) Message-ID: Date: Thu, 26 Apr 2007 10:39:19 -0500 (CDT) From: "David J. Orme" To: Developer discussions for provisioning Subject: Re: [provisioning-dev] Improved update generation/distribution algorithm In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1263_8044549.1177601959342" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 14:44:55 -0000 ------=_Part_1263_8044549.1177601959342 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is really interesting too. What kind of space reduction measurements h= ave you gotten?=20 Regards,=20 Dave=20 ----- Original Message -----=20 From: Stefan Liebig =20 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg=20 Sent: Thursday, April 26, 2007 3:41:50 AM GMT-0800=20 Subject: Re: [provisioning-dev] Improved update generation/distribution alg= orithm=20 I think the approach taken by us ( http://wiki.eclipse.org/index.php/GPW_Li= ghtning_Retrospectives#Smartup_software_update ) is somehow similar. At lea= st we have the same requirements. Would be nice if we could join our effort= s. For that I will give you a brief outline of our mechanism/algorithm.=20 First our alg. updates resources from V(n) to V(n+delta) with delta>0 in a = single step. Resources might be jars, zips, dlls, docs, ...=20 Since our solution is not (yet) eclipse based we do not have plugin jars li= ke eclipse has. But this is not a general restriction for our mechanism.=20 Our mechanism is based on delta encodings ( http://en.wikipedia.org/wiki/De= lta_encoding ).=20 In our particular case we have decided to use the xdelta alg. ( http://en.w= ikipedia.org/wiki/Xdelta ) which is pretty good usable for many types of da= ta. However, it performs very bad when =C2=B4diffing=C2=B4 compressed data = like zips and jars.=20 Because of that we unpack zips (in memory) into somthing similar to a tar a= nd perfom the =C2=B4binary diffing=C2=B4 on the different version of these = =C2=B4tars=C2=B4. The resulting delta (or patch) is then zipped (it really = gets smaller!) and send of the wire. =C2=B4Applying=C2=B4 this delta on the= =C2=B4old=C2=B4 version creates the =C2=B4new=C2=B4 version of the =C2=B4t= ared=C2=B4 resource. The resulting version is then converted back into a zi= p.=20 For this mechanism to work properly it required that versions of resources = can be uniquely identified. For this identification we use a combination of= the resource name and the MD5 hash of the resource. The resource name is s= imilar to the artifactId in mavens project.xml, i.e. the name of the resour= ce without any version specific parts in it.=20 The simplified update flow is:=20 - the client gets somehow the information that a resource should be updated= to a newer one=20 - therefore it asks the update server for the delta between the old and the= new version=20 - the update server generates the delta or has it already generated and cac= hed and sends it back=20 - the client applies this delta to old version and gets the new version=20 This happens for all required resources.=20 Our update server is an active server component realized as a servlet. It m= anages all resources in their different versions. The server is capable of = generating deltas in advance and keeping them in a cache for faster respons= e times. If a requested delta is not available it generates them on demand.= =20 In case that a delta is requested for a =C2=B4very=C2=B4 old version of a r= esource which is no longer available on the server (has been removed by an = administrator) the server will respond with a zipped version of the complet= e resource. Every delta/patch send to the client has a type that tells the = client how to handle the =C2=B4delta=C2=B4.=20 The situation that the server does not have a base (old) version for genera= ting a delta may also be the result of the manipulation of a resource on th= e client side. The identification for this manipulated resource (resource n= ame + md5 hash) will most likely not reference a resource on the server. Th= is case will also result in returning a complete (zipped) resource.=20 As I already mentioned it seems that Dave and we have similar requirements = but we solve them differently. The challenge will be to provide with the ne= w provisioning a base where different mechanisms can be plugged in.=20 There might also be a generalized delta layer in which Daves and our soluti= on could be plugged in.=20 Comments, questions?=20 Stefan=20 Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme=20 Gesendet: Do 26.04.2007 00:22=20 An: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg=20 Betreff: [provisioning-dev] Improved update generation/distribution algorit= hm=20 The current feature-based update sites can get huge quickly when small numb= ers of changes are scattered across a large number of features. This kind o= f situation happens easily when releasing a dot-level or a patchlevel upgra= de--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed.=20 The purpose of this email is to open a dialog and to outline our solution. = Apologies in advance for those who are less comfortable with expressing alg= orithms in formal math. Time constraints have dictated communication using = the most compact and efficient means possible.=20 The algorithm we developed worked as follows:=20 The build server maintains copies of all production versions of the applica= tion. In the general case, then, we need an algorithm to upgrade a given us= er from a version V(n) to a version V(n+delta) where delta is the number of= versions that have elapsed since the user last upgraded. We want this algo= rithm to have the following properties:=20 =E2=80=A2 Send a minimal number of bits across the wire=20 =E2=80=A2 Be as simple as possible=20 =E2=80=A2 Be verifiably correct. We couldn't afford to have 40k-70k of = broken clients if the algorithm malfunctioned.=20 =E2=80=A2 Related to the previous: Have safeguards built-in so that if = a bad update site is ever generated, the whole thing fails fast--before *an= y* bits are ever sent to clients.=20 You will notice some conflicts in the requirements above. In particular, th= e requirement to send the fewest number of bits over the wire conflicts wit= h the requirements to be as simple as possible and to be verifiably correct= . The result was that our algorithm sacrifices some efficiency in the numbe= r of bits it sends over the wire in order to be simpler and more verifiably= correct.=20 The result: In our application, going from version 1.0.0 to version 1.0.1 u= sing update site features resulted in about a 10 meg download. After applyi= ng our algorithm, the download size shrunk to about 3 megs. This is still l= arge for some of our users who utilize a dial-up connection, but it is doab= le, whereas the 10 meg download would simply be prohibitive.=20 Here is the algorithm:=20 First, we simplify the problem. Instead of upgrading users from an arbitrar= y version V(n) to V(n+delta), we only upgrade them from V(n) to V(n+1). Goi= ng to V(n+delta) is simply an iteration of the algorithm over delta steps. = This simplification works fine for our user population. If it would be acce= ptable for the general Eclipse population is an open question.=20 Second, we notice that sending JAR'd plugins is very expensive. Suppose onl= y two classes in a large plugin change: the whole plugin must still be ship= ped.=20 Our algorithm then is simple. We dynamically generate a function F where F(= P(V(n))) =3D P(V(n+1)). F is really just a zipped collection of files that = encodes just the files that changed between the two plugin versions.=20 This is accomplished using the following algorithm. For a given plugin P in= two versions V(n) and V(n+1):=20 2. Unpack P(V(n)) and P(V(n+1)) into temporary directories.=20 3. For files that correspond to each other in the two plugins, MD5 hash= them, and if the hashes are different, put the file from P(V(n+1)) into F.= =20 4. Include new files from P(V(n+1)) in F.=20 5. Create a text file manifest listing files in P(V(n)) that are no lon= ger included in P(V(n+1)) and include that text file in F.=20 6. Package all of the files in F in a zip file.=20 I believe that the algorithm for applying this function F to P(V(n)) to get= a P(V(n+1)) is self-evident.=20 This approach has advantages over binary-diffing the two plugin jars P(V(n)= ) and P(V(n+1)): If the order of the files contained in the plugin changes = between versions, a naive binary diff algorithm will not achieve nearly the= same amount of "compression" that we achieve.=20 So we have described a simple algorithm that is able to dramatically reduce= download bandwidth requirements over using update sites. However, we have = not described how we achieved the "fail-fast" requirement. If a flawed upda= te site is ever generated, we want to detect this automatically at build ti= me rather than after 50,000 clients have already downloaded it and broken t= heir installs.=20 Here is the algorithm we use:=20 After a build has completed, we have the following artifacts on our build s= erver:=20 P(V(n)) - the old version=20 P(V(n+1)) - the original new version generated by PDEBuild=20 F - the function (basically an intelligent binary diff) we generated that w= e can apply to P(V(n)) to get P(V(n+1))=20 The approach we take to validate F is the following:=20 2. Apply F to P(V(n)) on the build server using the same code that is r= unning on the clients.=20 3. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice t= he prime there). So formally, F(P(V(n))) =3D P(V(n+1))'=20 4. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the versi= on originally generated by PDEBuild.=20 5. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary= directories and perform an MD5 hash on all files, making sure that all fil= es present in one are also present in the other and that their hashes are e= qual.=20 6. If applying F to P(V(n)) on the build server using the same code as = is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on t= he server, then it should work on the clients as well.=20 In our implementation, all update site building on the build server was don= e in Ruby. The effort to implement the server side of this algorithm in Rub= y was about three days. The effort to implement the client-side (fully unit= -tested, pair-programmed, one pair programming team working on it full-time= ) in Java was about a month. This was due to the hassle of working with Jav= a input and output streams. However, the result was that the Java code work= ed entirely in memory, piping input streams into output streams and so on u= ntil only the final results were written to disk. Thus, the Java solution w= ould be immune to breakage resulting from something on the file system bein= g changed in a way we did not expect.=20 Let me know if you have any questions.=20 Regards,=20 Dave Orme=20 ------=_Part_1263_8044549.1177601959342 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is really interesting too.  What kind of space reduct= ion measurements have you gotten?


Regards,

Dave
----- = Original Message -----
From: Stefan Liebig <NGZw83RUgQCo5vRX@P+eEZb3FG8AqBHU6= e>
To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Sent: Thursday, April 26, 2007= 3:41:50 AM GMT-0800
Subject: Re: [provisioning-dev] Improved update gen= eration/distribution algorithm

I think = the approach taken by us (http://= wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#Smartup_software_up= date) is somehow similar. At least we have the same requirements. Would= be nice if we could join our efforts. For that I will give you a brief out= line of our mechanism/algorithm.
First ou= r alg. updates resources from V(n) to V(n+delta) with delta>0 in a singl= e step. Resources might be jars, zips, dlls, docs, ...
Since our solutio= n is not (yet) eclipse based we do not have plugin jars like eclipse has. B= ut this is not a general restriction for our mechanism.
 
Our mech= anism is based on delta encodings (http://en.wikipedia.org/wiki/Delta_encodi= ng).
In our particular case we have decided to use the xdelta alg. (= http://en= .wikipedia.org/wiki/Xdelta) which is pretty good usable for many types = of data. However, it performs very bad when =C2=B4diffing=C2=B4 compressed = data like zips and jars.
Because of that we unpack zips (in memory) into= somthing similar to a tar and perfom the =C2=B4binary diffing=C2=B4 on the= different version of these =C2=B4tars=C2=B4. The resulting delta (or patch= ) is then zipped (it really gets smaller!) and send of the wire. =C2=B4Appl= ying=C2=B4 this delta on the =C2=B4old=C2=B4 version creates the =C2=B4new= =C2=B4 version of the =C2=B4tared=C2=B4 resource. The resulting version is = then converted back into a zip.
For this mechanism to work properly it r= equired that versions of resources can be uniquely identified. For this ide= ntification we use a combination of the resource name and the MD5 hash of t= he resource. The resource name is similar to the artifactId in mavens proje= ct.xml, i.e. the name of the resource without any version specific parts in= it.
 
The simp= lified update flow is:
- the client gets somehow the information that a = resource should be updated to a newer one
- therefore it asks the update= server for the delta between the old and the new version
- the update s= erver generates the delta or has it already generated and cached and sends = it back
- the client applies this delta to old version and gets the new = version
This hap= pens for all required resources.
 
Our upda= te server is an active server component realized as a servlet. It manages a= ll resources in their different versions. The server is capable of generati= ng deltas in advance and keeping them in a cache for faster response times.= If a requested delta is not available it generates them on demand.
In c= ase that a delta is requested for a =C2=B4very=C2=B4 old version of a resou= rce which is no longer available on the server (has been removed by an admi= nistrator) the server will respond with a zipped version of the complete re= source. Every delta/patch send to the client has a type that tells the clie= nt how to handle the =C2=B4delta=C2=B4.
The situation that the server do= es not have a base (old) version for generating a delta may also be the res= ult of the manipulation of a resource on the client side. The identificatio= n for this manipulated resource (resource name + md5 hash) will most likely= not reference a resource on the server. This case will also result in retu= rning a complete (zipped) resource.
&= nbsp;
As I alr= eady mentioned it seems that Dave and we have similar requirements but we s= olve them differently. The challenge will be to provide with the new provis= ioning a base where different mechanisms can be plugged in.
There might = also be a generalized delta layer in which Daves and our solution could be = plugged in.
&= nbsp;
Comments= , questions?

Stef= an


Von: provisioning-dev-bounces@eclip= se.org im Auftrag von David J. Orme
Gesendet: Do 26.04.2007 00:22=
An: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Betreff: [provisionin= g-dev] Improved update generation/distribution algorithm

The current feature-based update sites can get huge quickly when small= numbers of changes are scattered across a large number of features.  = This kind of situation happens easily when releasing a dot-level or a patch= level upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed.
<= br>The purpose of this email is to open a dialog and to outline our solutio= n.  Apologies in advance for those who are less comfortable with expre= ssing algorithms in formal math.  Time constraints have dictated commu= nication using the most compact and efficient means possible.

The al= gorithm we developed worked as follows:

The build server maintains c= opies of all production versions of the application.  In the general c= ase, then, we need an algorithm to upgrade a given user from a version V(n)= to a version V(n+delta) where delta is the number of versions that have el= apsed since the user last upgraded.  We want this algorithm to have th= e following properties:
  • Send a minimal number of bits across the wire=20
  • Be as simple as possible=20
  • Be verifiably correct.  We couldn't afford to have 40k-70k of= broken clients if the algorithm malfunctioned.=20
  • Related to the previous: Have safeguards built-in so that if a bad= update site is ever generated, the whole thing fails fast--before *any* bi= ts are ever sent to clients.
You will notice some conflicts in the= requirements above.  In particular, the requirement to send the fewes= t number of bits over the wire conflicts with the requirements to be as sim= ple as possible and to be verifiably correct.  The result was that our= algorithm sacrifices some efficiency in the number of bits it sends over t= he wire in order to be simpler and more verifiably correct.

The resu= lt: In our application, going from version 1.0.0 to version 1.0.1 using upd= ate site features resulted in about a 10 meg download.  After applying= our algorithm, the download size shrunk to about 3 megs.  This is sti= ll large for some of our users who utilize a dial-up connection, but it is = doable, whereas the 10 meg download would simply be prohibitive.

Her= e is the algorithm:

First, we simplify the problem.  Instead of= upgrading users from an arbitrary version V(n) to V(n+delta), we only upgr= ade them from V(n) to V(n+1).  Going to V(n+delta) is simply an iterat= ion of the algorithm over delta steps.  This simplification works fine= for our user population.  If it would be acceptable for the general E= clipse population is an open question.

Second, we notice that sendin= g JAR'd plugins is very expensive.  Suppose only two classes in a larg= e plugin change: the whole plugin must still be shipped.

Our algorit= hm then is simple.  We dynamically generate a function F where F(P(V(n= ))) =3D P(V(n+1)).  F is really just a zipped collection of files that= encodes just the files that changed between the two plugin versions.
This is accomplished using the following algorithm.  For a given plu= gin P in two versions V(n) and V(n+1):
  1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.=20
  2. For files that correspond to each other in the two plugins, MD5 ha= sh them, and if the hashes are different, put the file from P(V(n+1)) into = F.=20
  3. Include new files from P(V(n+1)) in F.=20
  4. Create a text file manifest listing files in P(V(n)) that are no l= onger included in P(V(n+1)) and include that text file in F.=20
  5. Package all of the files in F in a zip file.
I believ= e that the algorithm for applying this function F to P(V(n)) to get a P(V(n= +1)) is self-evident.

This approach has advantages over binary-diffi= ng the two plugin jars P(V(n)) and P(V(n+1)): If the order of the files con= tained in the plugin changes between versions, a naive binary diff algorith= m will not achieve nearly the same amount of "compression" that we achieve.=

So we have described a simple algorithm that is able to dramaticall= y reduce download bandwidth requirements over using update sites.  How= ever, we have not described how we achieved the "fail-fast" requirement.&nb= sp; If a flawed update site is ever generated, we want to detect this autom= atically at build time rather than after 50,000 clients have already downlo= aded it and broken their installs.

Here is the algorithm we use:
=
After a build has completed, we have the following artifacts on our bui= ld server:

P(V(n)) - the old version
P(V(n+1)) - the original new= version generated by PDEBuild
F - the function (basically an intelligen= t binary diff) we generated that we can apply to P(V(n)) to get P(V(n+1))
The approach we take to validate F is the following:
  1. Apply F to P(V(n)) on the build server using the same code that is runn= ing on the clients.=20
  2. Let's call the result of applying F to P(V(n)), P(V(n+1))'  (= notice the prime there).  So formally, F(P(V(n))) =3D P(V(n+1))'
  3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the ver= sion originally generated by PDEBuild.=20
  4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into tempora= ry directories and perform an MD5 hash on all files, making sure that all f= iles present in one are also present in the other and that their hashes are= equal.=20
  5. If applying F to P(V(n)) on the build server using the same code a= s is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on= the server, then it should work on the clients as well.
In ou= r implementation, all update site building on the build server was done in = Ruby.  The effort to implement the server side of this algorithm in Ru= by was about three days.  The effort to implement the client-side (ful= ly unit-tested, pair-programmed, one pair programming team working on it fu= ll-time) in Java was about a month.  This was due to the hassle of wor= king with Java input and output streams.  However, the result was that= the Java code worked entirely in memory, piping input streams into output = streams and so on until only the final results were written to disk.  = Thus, the Java solution would be immune to breakage resulting from somethin= g on the file system being changed in a way we did not expect.

Let m= e know if you have any questions.


Regards,

Dave Orme
<= br>
------=_Part_1263_8044549.1177601959342-- From AugMCAIJ9XSwp9BM@XzQPvII7mdsgt6xg Thu Apr 26 12:01:39 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from foundation.eclipse.org (foundation.eclipse.org [206.191.52.61]) by mail.eclipse.org (Postfix) with ESMTP id 0580D247CD for ; Thu, 26 Apr 2007 12:01:39 -0400 (EDT) Received: by foundation.eclipse.org (Postfix, from userid 102) id AB5962DA5; Thu, 26 Apr 2007 12:01:39 -0400 (EDT) X-Spam-Virus: No X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on foundation.eclipse.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=3.1 tests=AWL,BAYES_00,HTML_20_30, HTML_MESSAGE autolearn=disabled version=3.1.7 Received: from [192.168.1.74] (foundationhq [206.191.52.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by foundation.eclipse.org (Postfix) with ESMTP id 1DD6A2D77 for ; Thu, 26 Apr 2007 12:01:38 -0400 (EDT) Message-ID: Date: Thu, 26 Apr 2007 12:01:37 -0400 From: Denis Roy Organization: Eclipse Foundation, Inc. User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] Improved update generation/distribution algorithm References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070503070509090008050705" X-Sanitizer: Eclipse.org anomy configuration X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 16:01:39 -0000 This is a multi-part message in MIME format. --------------070503070509090008050705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit A few thoughts... David J. Orme wrote: > - Is the size of the update site ever an issue? > > For us, no. We use a separate physical build server and update site > server. For a project like Eclipse, this is a good question, since an > algorithm like this would be required to eventually keep terabytes of > information around in order to generate diffs. For those of us who maintain large update sites and can't afford terabytes of disk space, the answer is yes, the size of the update site is an issue to consider :) > > - With a server that could run code, have you considered the generation of > the deltas on the fly given what the client has? > Two considerations: a) big update sites with lots of traffic can potentially require massive server resources to generate deltas on-the-fly. b) deltas on-the-fly means we can't use the free bandwidth provided by mirror sites. Although sending deltas likely translates to a much smaller transfer than what we send out now, static "dumb http" mirrors also allow users to pick a server geographically close to them instead of one set of servers in one physical location. Thanks, Denis > - How do you see that fit with the concept of artifact repository > developed > in equinox and our attempt to use a mirroring metaphor instead of > download? > > This is a way to mirror new versions of plugins between repositories > using minimal bandwidth with reasonable assurances of correctness. > > > > > "David J. Orme" > > > -software.com> > To > Sent by: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > > provisioning-dev- > cc > B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM > > rg > Subject > [provisioning-dev] Improved > update > generation/distribution > algorithm > 04/25/2007 06:22 > > PM > > > > > > Please respond to > > "Developer > > discussions for > > provisioning > > \(Update > > Manager\) > > initiatives" > > > @eclipse.org> > > > > > > > > > > The current feature-based update sites can get huge quickly when small > numbers of changes are scattered across a large number of features. This > kind of situation happens easily when releasing a dot-level or a > patchlevel > upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed. > > The purpose of this email is to open a dialog and to outline our solution. > Apologies in advance for those who are less comfortable with expressing > algorithms in formal math. Time constraints have dictated communication > using the most compact and efficient means possible. > > The algorithm we developed worked as follows: > > The build server maintains copies of all production versions of the > application. In the general case, then, we need an algorithm to upgrade a > given user from a version V(n) to a version V(n+delta) where delta is the > number of versions that have elapsed since the user last upgraded. We > want > this algorithm to have the following properties: > Send a minimal number of bits across the wire > Be as simple as possible > Be verifiably correct. We couldn't afford to have 40k-70k of broken > clients if the algorithm malfunctioned. > Related to the previous: Have safeguards built-in so that if a bad > update site is ever generated, the whole thing fails fast--before > *any* bits are ever sent to clients. > You will notice some conflicts in the requirements above. In particular, > the requirement to send the fewest number of bits over the wire conflicts > with the requirements to be as simple as possible and to be verifiably > correct. The result was that our algorithm sacrifices some efficiency in > the number of bits it sends over the wire in order to be simpler and more > verifiably correct. > > The result: In our application, going from version 1.0.0 to version 1.0.1 > using update site features resulted in about a 10 meg download. After > applying our algorithm, the download size shrunk to about 3 megs. This is > still large for some of our users who utilize a dial-up connection, but it > is doable, whereas the 10 meg download would simply be prohibitive. > > Here is the algorithm: > > First, we simplify the problem. Instead of upgrading users from an > arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to > V(n+1). Going to V(n+delta) is simply an iteration of the algorithm over > delta steps. This simplification works fine for our user population. If > it would be acceptable for the general Eclipse population is an open > question. > > Second, we notice that sending JAR'd plugins is very expensive. Suppose > only two classes in a large plugin change: the whole plugin must still be > shipped. > > Our algorithm then is simple. We dynamically generate a function F where > F(P(V(n))) = P(V(n+1)). F is really just a zipped collection of files > that > encodes just the files that changed between the two plugin versions. > > This is accomplished using the following algorithm. For a given plugin P > in two versions V(n) and V(n+1): > 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories. > 2. For files that correspond to each other in the two plugins, MD5 hash > them, and if the hashes are different, put the file from P(V(n+1)) > into F. > 3. Include new files from P(V(n+1)) in F. > 4. Create a text file manifest listing files in P(V(n)) that are no > longer included in P(V(n+1)) and include that text file in F. > 5. Package all of the files in F in a zip file. > I believe that the algorithm for applying this function F to P(V(n)) > to get > a P(V(n+1)) is self-evident. > > This approach has advantages over binary-diffing the two plugin jars > P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin > changes between versions, a naive binary diff algorithm will not achieve > nearly the same amount of "compression" that we achieve. > > So we have described a simple algorithm that is able to dramatically > reduce > download bandwidth requirements over using update sites. However, we have > not described how we achieved the "fail-fast" requirement. If a flawed > update site is ever generated, we want to detect this automatically at > build time rather than after 50,000 clients have already downloaded it and > broken their installs. > > Here is the algorithm we use: > > After a build has completed, we have the following artifacts on our build > server: > > P(V(n)) - the old version > P(V(n+1)) - the original new version generated by PDEBuild > F - the function (basically an intelligent binary diff) we generated that > we can apply to P(V(n)) to get P(V(n+1)) > > The approach we take to validate F is the following: > 1. Apply F to P(V(n)) on the build server using the same code that is > running on the clients. > 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice > the prime there). So formally, F(P(V(n))) = P(V(n+1))' > 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the > version originally generated by PDEBuild. > 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary > directories and perform an MD5 hash on all files, making sure that > all files present in one are also present in the other and that > their > hashes are equal. > 5. If applying F to P(V(n)) on the build server using the same code as > is running on the clients produces a P(V(n+1))' identical to > P(V(n+1)) on the server, then it should work on the clients as well. > In our implementation, all update site building on the build server was > done in Ruby. The effort to implement the server side of this > algorithm in > Ruby was about three days. The effort to implement the client-side (fully > unit-tested, pair-programmed, one pair programming team working on it > full-time) in Java was about a month. This was due to the hassle of > working with Java input and output streams. However, the result was that > the Java code worked entirely in memory, piping input streams into output > streams and so on until only the final results were written to disk. > Thus, > the Java solution would be immune to breakage resulting from something on > the file system being changed in a way we did not expect. > > Let me know if you have any questions. > > > Regards, > > Dave Orme > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > ------------------------------------------------------------------------ > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > -- Denis Roy Manager, IT Infrastructure Eclipse Foundation, Inc. -- http://www.eclipse.org/ Office: 613.224.9461 x224 (Eastern time) Cell: 819.210.6481 AugMCAIJ9XSwp9BM@XzQPvII7mdsgt6xg --------------070503070509090008050705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit A few thoughts...

David J. Orme wrote:
- Is the size of the update site ever an issue?

For us, no.  We use a separate physical build server and update site server.  For a project like Eclipse, this is a good question, since an algorithm like this would be required to eventually keep terabytes of information around in order to generate diffs.
For those of us who maintain large update sites and can't afford terabytes of disk space, the answer is yes, the size of the update site is an issue to consider  :)

- With a server that could run code, have you considered the generation of
the deltas on the fly given what the client has?

Two considerations:
a) big update sites with lots of traffic can potentially require massive server resources to generate deltas on-the-fly.
b) deltas on-the-fly means we can't use the free bandwidth provided by mirror sites. Although sending deltas likely translates to a much smaller transfer than what we send out now, static "dumb http" mirrors also allow users to pick a server geographically close to them instead of one set of servers in one physical location.

Thanks,

Denis

- How do you see that fit with the concept of artifact repository developed
in equinox and our attempt to use a mirroring metaphor instead of download?

This is a way to mirror new versions of plugins between repositories using minimal bandwidth with reasonable assurances of correctness.


                                                                          
             "David J. Orme"                                              
             <djo@coconut-palm                                            
             -software.com>                                             To
             Sent by:                  bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg        
             provisioning-dev-                                          cc
             B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM                                            
             rg                                                    Subject
                                       [provisioning-dev] Improved update  
                                       generation/distribution algorithm  
             04/25/2007 06:22                                              
             PM                                                            
                                                                          
                                                                          
             Please respond to                                            
                "Developer                                                
              discussions for                                              
               provisioning                                                
                 \(Update                                                  
                 Manager\)                                                
               initiatives"                                                
             <provisioning-dev                                            
               @eclipse.org>                                              
                                                                          
                                                                          




The current feature-based update sites can get huge quickly when small
numbers of changes are scattered across a large number of features.  This
kind of situation happens easily when releasing a dot-level or a patchlevel
upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed.

The purpose of this email is to open a dialog and to outline our solution.
Apologies in advance for those who are less comfortable with expressing
algorithms in formal math.  Time constraints have dictated communication
using the most compact and efficient means possible.

The algorithm we developed worked as follows:

The build server maintains copies of all production versions of the
application.  In the general case, then, we need an algorithm to upgrade a
given user from a version V(n) to a version V(n+delta) where delta is the
number of versions that have elapsed since the user last upgraded.  We want
this algorithm to have the following properties:
      Send a minimal number of bits across the wire
      Be as simple as possible
      Be verifiably correct.  We couldn't afford to have 40k-70k of broken
      clients if the algorithm malfunctioned.
      Related to the previous: Have safeguards built-in so that if a bad
      update site is ever generated, the whole thing fails fast--before
      *any* bits are ever sent to clients.
You will notice some conflicts in the requirements above.  In particular,
the requirement to send the fewest number of bits over the wire conflicts
with the requirements to be as simple as possible and to be verifiably
correct.  The result was that our algorithm sacrifices some efficiency in
the number of bits it sends over the wire in order to be simpler and more
verifiably correct.

The result: In our application, going from version 1.0.0 to version 1.0.1
using update site features resulted in about a 10 meg download.  After
applying our algorithm, the download size shrunk to about 3 megs.  This is
still large for some of our users who utilize a dial-up connection, but it
is doable, whereas the 10 meg download would simply be prohibitive.

Here is the algorithm:

First, we simplify the problem.  Instead of upgrading users from an
arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to
V(n+1).  Going to V(n+delta) is simply an iteration of the algorithm over
delta steps.  This simplification works fine for our user population.  If
it would be acceptable for the general Eclipse population is an open
question.

Second, we notice that sending JAR'd plugins is very expensive.  Suppose
only two classes in a large plugin change: the whole plugin must still be
shipped.

Our algorithm then is simple.  We dynamically generate a function F where
F(P(V(n))) = P(V(n+1)).  F is really just a zipped collection of files that
encodes just the files that changed between the two plugin versions.

This is accomplished using the following algorithm.  For a given plugin P
in two versions V(n) and V(n+1):
   1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.
   2. For files that correspond to each other in the two plugins, MD5 hash
      them, and if the hashes are different, put the file from P(V(n+1))
      into F.
   3. Include new files from P(V(n+1)) in F.
   4. Create a text file manifest listing files in P(V(n)) that are no
      longer included in P(V(n+1)) and include that text file in F.
   5. Package all of the files in F in a zip file.
I believe that the algorithm for applying this function F to P(V(n)) to get
a P(V(n+1)) is self-evident.

This approach has advantages over binary-diffing the two plugin jars
P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin
changes between versions, a naive binary diff algorithm will not achieve
nearly the same amount of "compression" that we achieve.

So we have described a simple algorithm that is able to dramatically reduce
download bandwidth requirements over using update sites.  However, we have
not described how we achieved the "fail-fast" requirement.  If a flawed
update site is ever generated, we want to detect this automatically at
build time rather than after 50,000 clients have already downloaded it and
broken their installs.

Here is the algorithm we use:

After a build has completed, we have the following artifacts on our build
server:

P(V(n)) - the old version
P(V(n+1)) - the original new version generated by PDEBuild
F - the function (basically an intelligent binary diff) we generated that
we can apply to P(V(n)) to get P(V(n+1))

The approach we take to validate F is the following:
   1. Apply F to P(V(n)) on the build server using the same code that is
      running on the clients.
   2. Let's call the result of applying F to P(V(n)), P(V(n+1))'  (notice
      the prime there).  So formally, F(P(V(n))) = P(V(n+1))'
   3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the
      version originally generated by PDEBuild.
   4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary
      directories and perform an MD5 hash on all files, making sure that
      all files present in one are also present in the other and that their
      hashes are equal.
   5. If applying F to P(V(n)) on the build server using the same code as
      is running on the clients produces a P(V(n+1))' identical to
      P(V(n+1)) on the server, then it should work on the clients as well.
In our implementation, all update site building on the build server was
done in Ruby.  The effort to implement the server side of this algorithm in
Ruby was about three days.  The effort to implement the client-side (fully
unit-tested, pair-programmed, one pair programming team working on it
full-time) in Java was about a month.  This was due to the hassle of
working with Java input and output streams.  However, the result was that
the Java code worked entirely in memory, piping input streams into output
streams and so on until only the final results were written to disk.  Thus,
the Java solution would be immune to breakage resulting from something on
the file system being changed in a way we did not expect.

Let me know if you have any questions.


Regards,

Dave Orme
_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev


_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev

_______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev

-- 
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc.  --  http://www.eclipse.org/
Office: 613.224.9461 x224 (Eastern time)
Cell: 819.210.6481
AugMCAIJ9XSwp9BM@XzQPvII7mdsgt6xg
--------------070503070509090008050705-- From ZG0MqD2tXqzn621v@RgofA6Na+BoXv9wI Thu Apr 26 13:00:08 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mail.eclipse.org (Postfix) with SMTP id 4D9032CF30 for ; Thu, 26 Apr 2007 13:00:05 -0400 (EDT) Received: by an-out-0708.google.com with SMTP id c18so285758anc for ; Thu, 26 Apr 2007 09:58:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Ks4Vo76TKk5dRw543YDfuzc2HJJyWZQPNPx/XbwJEHp+yBCIwQa+taJHpzshSzzyjPmJEsQAtcYWCtpVUyyBoelaHu1BA1gN8jT3DwdnS1BQq0Wwj20t3KNtHAPM9MPWSavL9xjZyPNQrzrhtBphAoX2Pi6Il/Fs0YNTp75N1Gg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=MKcKUpkhFCtns9UYP7ryqeRc/4uLFOr9MSfrMAVhQL1/mI1LdBtUGX01/h1z3qrqBavonVNK1QwoN+mtVDT9Po6+CCHi62uAkbj+oeLkC5KbP//XMxMdK8Iex3RqxS6MZ/QMSHoU/P9dTZILmwA7SnxarJtbVc9ALuLqg130/xU= Received: by 10.100.91.6 with SMTP id o6mr1289395anb.1177606726793; Thu, 26 Apr 2007 09:58:46 -0700 (PDT) Received: by 10.100.92.19 with HTTP; Thu, 26 Apr 2007 09:58:46 -0700 (PDT) Message-ID: Date: Thu, 26 Apr 2007 12:58:46 -0400 From: "Nick Boldt" Sender: ZG0MqD2tXqzn621v@RgofA6Na+BoXv9wI To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] Improved update generation/distribution algorithm In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_87156_29437806.1177606726659" References: X-Google-Sender-Auth: ef01c1617d4ca647 X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 17:00:08 -0000 ------=_Part_87156_29437806.1177606726659 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What if the deltas between V(n) and V(n+1), V(n+2) ... V(n+latest) were precomputed and stored on download.eclipse.org for mirroring, rather than only in-memory? In this case, n would be a Milestone, and each I build that followed (+1, +2, ...) would ONLY consist of incremental deltas from its predecessor. Milestones, which tend to get picked up more than I builds, could be treated differently. I can see three possible ways to publish a milestone: a) Delta from last milestone (M7 vs. M6) b) Delta from last I build (M7-S20080428 vs. I-20080421) c) full build (because people often download a full milestone build in order to have a clean start) The same should probably be true for R builds: a) Delta from last R ( 3.4.0 vs. 3.3.0) b) Delta from last I/S build (R3.4.0-R20080528 vs. RC7-S20080521) c) full build For maintenance branches, I'd suggest that the first GA build on the branch (say, 3.4.0) would be the baseline, and all maintenance builds (M, S) would be delta-only updates. The final R build in a branch ( 3.4.1, 3.4.2) ought to be available either in both formats or just as a full build so that people who are coming to Eclipse for the first time don't have to download 3.4.0 and then wait as it updates to 3.4.2; instead, they can start with 3.4.2 directly. a) Delta from last R (3.4.1 vs. 3.4.0) b) Delta from last M/S build (R3.3.2-R20090228 vs. M-20090221) c) full build This approach takes all the benefits of the delta computation for space/bandwidth savings, but also allows the mirrors to participate, and lets us do the computation-heavy/memory-heavy work up front when first publishing the build from build server to production server @ eclipse.org. On the other hand, offering three ways to update (for stable and release builds) might be overkill. Would people be OK with downloading 3.4.0 and waiting to update it via delta-only updates to 3.4.2, if it was never offered as a full download? I suppose it would be no worse than installing a ubuntu or debian based linux distro and immediately running `apt-get update; apt-get upgrade` to get the updates not included in the .iso, or installing Windows and then running Windows Update & Microsoft Update to get the umpteen patches, fixes and drivers that weren't on the install CD. But is that such a great thing to emulate? ;-) On the issue of storing terrabytes of old builds, delta precomputation would get around that problem -- at any time you'd only ever need: this week's I (20070421, 20070414, ...) last week's I (20070428, 20070421, ...) last month's milestone S (M6, M5, ...) this month's milestone S (M7, M6, ...) last year's release R (x.y.0, x.y.1) this year's release R (x.y.1, x.y.2) With precomputed deltas, you'd only need to store those deltas, not the builds for which they were calculated, and could purge old builds cyclically so you'd only ever have 2 I builds, 2 milestone/RC builds, and all the releases. AFAIK, that's not so different from the current policy. Thoughts? -- Nick Boldt :: Release Engineer, IBM Toronto Lab Eclipse Modeling :: http://www.eclipse.org/modeling http://wiki.eclipse.org/index.php/User:Nickb On 4/26/07, Denis Roy wrote: > > A few thoughts... > > David J. Orme wrote: > > - Is the size of the update site ever an issue? > > For us, no. We use a separate physical build server and update site > server. For a project like Eclipse, this is a good question, since an > algorithm like this would be required to eventually keep terabytes of > information around in order to generate diffs. > > For those of us who maintain large update sites and can't afford terabytes > of disk space, the answer is yes, the size of the update site is an issue to > consider :) > > > - With a server that could run code, have you considered the generation of > the deltas on the fly given what the client has? > > Two considerations: > a) big update sites with lots of traffic can potentially require massive > server resources to generate deltas on-the-fly. > b) deltas on-the-fly means we can't use the free bandwidth provided by > mirror sites. Although sending deltas likely translates to a much smaller > transfer than what we send out now, static "dumb http" mirrors also allow > users to pick a server geographically close to them instead of one set of > servers in one physical location. > > Thanks, > > Denis > > - How do you see that fit with the concept of artifact repository > developed > in equinox and our attempt to use a mirroring metaphor instead of > download? > > This is a way to mirror new versions of plugins between repositories using > minimal bandwidth with reasonable assurances of correctness. > > > > > "David J. Orme" > > > -software.com> To > > Sent by: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > > provisioning-dev- cc > > B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM > > rg Subject > > [provisioning-dev] Improved update > > generation/distribution algorithm > > 04/25/2007 06:22 > > PM > > > > > > Please respond to > > "Developer > > discussions for > > provisioning > > \(Update > > Manager\) > > initiatives" > > > @eclipse.org> > > > > > > > > > > The current feature-based update sites can get huge quickly when small > numbers of changes are scattered across a large number of features. This > kind of situation happens easily when releasing a dot-level or a > patchlevel > upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed. > > The purpose of this email is to open a dialog and to outline our solution. > Apologies in advance for those who are less comfortable with expressing > algorithms in formal math. Time constraints have dictated communication > using the most compact and efficient means possible. > > The algorithm we developed worked as follows: > > The build server maintains copies of all production versions of the > application. In the general case, then, we need an algorithm to upgrade a > given user from a version V(n) to a version V(n+delta) where delta is the > number of versions that have elapsed since the user last upgraded. We > want > this algorithm to have the following properties: > Send a minimal number of bits across the wire > Be as simple as possible > Be verifiably correct. We couldn't afford to have 40k-70k of broken > clients if the algorithm malfunctioned. > Related to the previous: Have safeguards built-in so that if a bad > update site is ever generated, the whole thing fails fast--before > *any* bits are ever sent to clients. > You will notice some conflicts in the requirements above. In particular, > the requirement to send the fewest number of bits over the wire conflicts > with the requirements to be as simple as possible and to be verifiably > correct. The result was that our algorithm sacrifices some efficiency in > the number of bits it sends over the wire in order to be simpler and more > verifiably correct. > > The result: In our application, going from version 1.0.0 to version 1.0.1 > using update site features resulted in about a 10 meg download. After > applying our algorithm, the download size shrunk to about 3 megs. This is > still large for some of our users who utilize a dial-up connection, but it > is doable, whereas the 10 meg download would simply be prohibitive. > > Here is the algorithm: > > First, we simplify the problem. Instead of upgrading users from an > arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to > V(n+1). Going to V(n+delta) is simply an iteration of the algorithm over > delta steps. This simplification works fine for our user population. If > it would be acceptable for the general Eclipse population is an open > question. > > Second, we notice that sending JAR'd plugins is very expensive. Suppose > only two classes in a large plugin change: the whole plugin must still be > shipped. > > Our algorithm then is simple. We dynamically generate a function F where > F(P(V(n))) = P(V(n+1)). F is really just a zipped collection of files > that > encodes just the files that changed between the two plugin versions. > > This is accomplished using the following algorithm. For a given plugin P > in two versions V(n) and V(n+1): > 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories. > 2. For files that correspond to each other in the two plugins, MD5 hash > them, and if the hashes are different, put the file from P(V(n+1)) > into F. > 3. Include new files from P(V(n+1)) in F. > 4. Create a text file manifest listing files in P(V(n)) that are no > longer included in P(V(n+1)) and include that text file in F. > 5. Package all of the files in F in a zip file. > I believe that the algorithm for applying this function F to P(V(n)) to > get > a P(V(n+1)) is self-evident. > > This approach has advantages over binary-diffing the two plugin jars > P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin > changes between versions, a naive binary diff algorithm will not achieve > nearly the same amount of "compression" that we achieve. > > So we have described a simple algorithm that is able to dramatically > reduce > download bandwidth requirements over using update sites. However, we have > not described how we achieved the "fail-fast" requirement. If a flawed > update site is ever generated, we want to detect this automatically at > build time rather than after 50,000 clients have already downloaded it and > broken their installs. > > Here is the algorithm we use: > > After a build has completed, we have the following artifacts on our build > server: > > P(V(n)) - the old version > P(V(n+1)) - the original new version generated by PDEBuild > F - the function (basically an intelligent binary diff) we generated that > we can apply to P(V(n)) to get P(V(n+1)) > > The approach we take to validate F is the following: > 1. Apply F to P(V(n)) on the build server using the same code that is > running on the clients. > 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice > the prime there). So formally, F(P(V(n))) = P(V(n+1))' > 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the > version originally generated by PDEBuild. > 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary > directories and perform an MD5 hash on all files, making sure that > all files present in one are also present in the other and that > their > hashes are equal. > 5. If applying F to P(V(n)) on the build server using the same code as > is running on the clients produces a P(V(n+1))' identical to > P(V(n+1)) on the server, then it should work on the clients as well. > In our implementation, all update site building on the build server was > done in Ruby. The effort to implement the server side of this algorithm > in > Ruby was about three days. The effort to implement the client-side (fully > unit-tested, pair-programmed, one pair programming team working on it > full-time) in Java was about a month. This was due to the hassle of > working with Java input and output streams. However, the result was that > the Java code worked entirely in memory, piping input streams into output > streams and so on until only the final results were written to disk. > Thus, > the Java solution would be immune to breakage resulting from something on > the file system being changed in a way we did not expect. > > Let me know if you have any questions. > > > Regards, > > Dave Orme > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > ------------------------------ > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > > -- > Denis Roy > Manager, IT Infrastructure > Eclipse Foundation, Inc. -- http://www.eclipse.org/ > > Office: 613.224.9461 x224 (Eastern time) > Cell: OcTb/yAGkWpeqtmj@XzQPvII7mdsgt6xg > > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > ------=_Part_87156_29437806.1177606726659 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What if the deltas between V(n) and V(n+1), V(n+2) ... V(n+latest) were precomputed and stored on download.eclipse.org for mirroring, rather than only in-memory? In this case, n would be a Milestone, and each I build that followed (+1, +2, ...) would ONLY consist of incremental deltas from its predecessor.

Milestones, which tend to get picked up more than I builds, could be treated differently. I can see three possible ways to publish a milestone:

a) Delta from last milestone (M7 vs. M6)
b) Delta from last I build (M7-S20080428 vs. I-20080421)
c) full build (because people often download a full milestone build in order to have a clean start)

The same should probably be true for R builds:

a) Delta from last R ( 3.4.0 vs. 3.3.0)
b) Delta from last I/S build (R3.4.0-R20080528 vs. RC7-S20080521)
c) full build

For maintenance branches, I'd suggest that the first GA build on the branch (say, 3.4.0) would be the baseline, and all maintenance builds (M, S) would be delta-only updates. The final R build in a branch ( 3.4.1, 3.4.2) ought to be available either in both formats or just as a full build so that people who are coming to Eclipse for the first time don't have to download 3.4.0 and then wait as it updates to 3.4.2; instead, they can start with 3.4.2 directly.

a) Delta from last R (3.4.1 vs. 3.4.0)
b) Delta from last M/S build (R3.3.2-R20090228 vs. M-20090221)
c) full build

This approach takes all the benefits of the delta computation for space/bandwidth savings, but also allows the mirrors to participate, and lets us do the computation-heavy/memory-heavy work up front when first publishing the build from build server to production server @ eclipse.org.

On the other hand, offering three ways to update (for stable and release builds) might be overkill. Would people be OK with downloading 3.4.0 and waiting to update it via delta-only updates to 3.4.2, if it was never offered as a full download? I suppose it would be no worse than installing a ubuntu or debian based linux distro and immediately running `apt-get update; apt-get upgrade` to get the updates not included in the .iso, or installing Windows and then running Windows Update & Microsoft Update to get the umpteen patches, fixes and drivers that weren't on the install CD. But is that such a great thing to emulate? ;-)

On the issue of storing terrabytes of old builds, delta precomputation would get around that problem -- at any time you'd only ever need:

this week's I (20070421, 20070414, ...)
last week's I (20070428, 20070421, ...)
last month's milestone S (M6, M5, ...)
this month's milestone S (M7, M6, ...)
last year's release R (x.y.0, x.y.1)
this year's release R (x.y.1, x.y.2)

With precomputed deltas, you'd only need to store those deltas, not the builds for which they were calculated, and could purge old builds cyclically so you'd only ever have 2 I builds, 2 milestone/RC builds, and all the releases. AFAIK, that's not so different from the current policy.

Thoughts?

--
Nick Boldt :: Release Engineer, IBM Toronto Lab
Eclipse Modeling :: http://www.eclipse.org/modeling
http://wiki.eclipse.org/index.php/User:Nickb

On 4/26/07, Denis Roy <AugMCAIJ9XSwp9BM@XzQPvII7mdsgt6xg > wrote:
A few thoughts...

David J. Orme wrote:
- Is the size of the update site ever an issue?

For us, no.  We use a separate physical build server and update site server.  For a project like Eclipse, this is a good question, since an algorithm like this would be required to eventually keep terabytes of information around in order to generate diffs.
For those of us who maintain large update sites and can't afford terabytes of disk space, the answer is yes, the size of the update site is an issue to consider  :)

- With a server that could run code, have you considered the generation of
the deltas on the fly given what the client has?

Two considerations:
a) big update sites with lots of traffic can potentially require massive server resources to generate deltas on-the-fly.
b) deltas on-the-fly means we can't use the free bandwidth provided by mirror sites. Although sending deltas likely translates to a much smaller transfer than what we send out now, static "dumb http" mirrors also allow users to pick a server geographically close to them instead of one set of servers in one physical location.

Thanks,

Denis

- How do you see that fit with the concept of artifact repository developed
in equinox and our attempt to use a mirroring metaphor instead of download?

This is a way to mirror new versions of plugins between repositories using minimal bandwidth with reasonable assurances of correctness.


                                                                          
             "David J. Orme"                                              
             <djo@coconut-palm                                            
             -software.com>                                             To
             Sent by:                  bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg        
             provisioning-dev-                                          cc
             B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM                                            
             rg                                                    Subject
                                       [provisioning-dev] Improved update  
                                       generation/distribution algorithm  
             04/25/2007 06:22                                              
             PM                                                            
                                                                          
                                                                          
             Please respond to                                            
                "Developer                                                
              discussions for                                              
               provisioning                                                
                 \(Update                                                  
                 Manager\)                                                
               initiatives"                                                
             <provisioning-dev                                            
               @eclipse.org>                                              
                                                                          
                                                                          




The current feature-based update sites can get huge quickly when small
numbers of changes are scattered across a large number of features.  This
kind of situation happens easily when releasing a dot-level or a patchlevel
upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed.

The purpose of this email is to open a dialog and to outline our solution.
Apologies in advance for those who are less comfortable with expressing
algorithms in formal math.  Time constraints have dictated communication
using the most compact and efficient means possible.

The algorithm we developed worked as follows:

The build server maintains copies of all production versions of the
application.  In the general case, then, we need an algorithm to upgrade a
given user from a version V(n) to a version V(n+delta) where delta is the
number of versions that have elapsed since the user last upgraded.  We want
this algorithm to have the following properties:
      Send a minimal number of bits across the wire
      Be as simple as possible
      Be verifiably correct.  We couldn't afford to have 40k-70k of broken
      clients if the algorithm malfunctioned.
      Related to the previous: Have safeguards built-in so that if a bad
      update site is ever generated, the whole thing fails fast--before
      *any* bits are ever sent to clients.
You will notice some conflicts in the requirements above.  In particular,
the requirement to send the fewest number of bits over the wire conflicts
with the requirements to be as simple as possible and to be verifiably
correct.  The result was that our algorithm sacrifices some efficiency in
the number of bits it sends over the wire in order to be simpler and more
verifiably correct.

The result: In our application, going from version 1.0.0 to version 1.0.1
using update site features resulted in about a 10 meg download.  After
applying our algorithm, the download size shrunk to about 3 megs.  This is
still large for some of our users who utilize a dial-up connection, but it
is doable, whereas the 10 meg download would simply be prohibitive.

Here is the algorithm:

First, we simplify the problem.  Instead of upgrading users from an
arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to
V(n+1).  Going to V(n+delta) is simply an iteration of the algorithm over
delta steps.  This simplification works fine for our user population.  If
it would be acceptable for the general Eclipse population is an open
question.

Second, we notice that sending JAR'd plugins is very expensive.  Suppose
only two classes in a large plugin change: the whole plugin must still be
shipped.

Our algorithm then is simple.  We dynamically generate a function F where
F(P(V(n))) = P(V(n+1)).  F is really just a zipped collection of files that
encodes just the files that changed between the two plugin versions.

This is accomplished using the following algorithm.  For a given plugin P
in two versions V(n) and V(n+1):
   1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.
   2. For files that correspond to each other in the two plugins, MD5 hash
      them, and if the hashes are different, put the file from P(V(n+1))
      into F.
   3. Include new files from P(V(n+1)) in F.
   4. Create a text file manifest listing files in P(V(n)) that are no
      longer included in P(V(n+1)) and include that text file in F.
   5. Package all of the files in F in a zip file.
I believe that the algorithm for applying this function F to P(V(n)) to get
a P(V(n+1)) is self-evident.

This approach has advantages over binary-diffing the two plugin jars
P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin
changes between versions, a naive binary diff algorithm will not achieve
nearly the same amount of "compression" that we achieve.

So we have described a simple algorithm that is able to dramatically reduce
download bandwidth requirements over using update sites.  However, we have
not described how we achieved the "fail-fast" requirement.  If a flawed
update site is ever generated, we want to detect this automatically at
build time rather than after 50,000 clients have already downloaded it and
broken their installs.

Here is the algorithm we use:

After a build has completed, we have the following artifacts on our build
server:

P(V(n)) - the old version
P(V(n+1)) - the original new version generated by PDEBuild
F - the function (basically an intelligent binary diff) we generated that
we can apply to P(V(n)) to get P(V(n+1))

The approach we take to validate F is the following:
   1. Apply F to P(V(n)) on the build server using the same code that is
      running on the clients.
   2. Let's call the result of applying F to P(V(n)), P(V(n+1))'  (notice
      the prime there).  So formally, F(P(V(n))) = P(V(n+1))'
   3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the
      version originally generated by PDEBuild.
   4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary
      directories and perform an MD5 hash on all files, making sure that
      all files present in one are also present in the other and that their
      hashes are equal.
   5. If applying F to P(V(n)) on the build server using the same code as
      is running on the clients produces a P(V(n+1))' identical to
      P(V(n+1)) on the server, then it should work on the clients as well.
In our implementation, all update site building on the build server was
done in Ruby.  The effort to implement the server side of this algorithm in
Ruby was about three days.  The effort to implement the client-side (fully
unit-tested, pair-programmed, one pair programming team working on it
full-time) in Java was about a month.  This was due to the hassle of
working with Java input and output streams.  However, the result was that
the Java code worked entirely in memory, piping input streams into output
streams and so on until only the final results were written to disk.  Thus,
the Java solution would be immune to breakage resulting from something on
the file system being changed in a way we did not expect.

Let me know if you have any questions.


Regards,

Dave Orme
_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev


_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev

_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev

-- 
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc. -- http://www.eclipse.org/
Office: 613.224.9461 x224 (Eastern time) Cell: 819.210.6481 AugMCAIJ9XSwp9BM@XzQPvII7mdsgt6xg

_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev


------=_Part_87156_29437806.1177606726659-- From Jeff_TTczmgW07z/8fKPW@YHvLZjvCTR1Igv9U Thu Apr 26 21:05:38 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by mail.eclipse.org (Postfix) with SMTP id F383BEF791 for ; Thu, 26 Apr 2007 21:05:37 -0400 (EDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l3R034GZ012064 for ; Thu, 26 Apr 2007 20:03:04 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3R14GWs530888 for ; Thu, 26 Apr 2007 21:04:16 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3R14G0Y015138 for ; Thu, 26 Apr 2007 21:04:16 -0400 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3R14GdP015131 for ; Thu, 26 Apr 2007 21:04:16 -0400 In-Reply-To: To: "Developer discussions for provisioning \(Update Manager\) initiatives" Subject: Re: [provisioning-dev] Improved update generation/distribution algorithm MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Jeff McAffer Message-ID: Date: Thu, 26 Apr 2007 21:04:16 -0400 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 04/26/2007 21:04:16, Serialize complete at 04/26/2007 21:04:16 Content-Type: multipart/alternative; boundary="=_alternative 0005EBE7852572CA_=" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 01:05:38 -0000 This is a multipart message in MIME format. --=_alternative 0005EBE7852572CA_= Content-Type: text/plain; charset="US-ASCII" > - In your example, you say that 3M is still large? Why do you think so, are > the actual changes smaller? Why don't you ship the delta of each files > instead of each complete file? > > 3M is still a pretty long download for a modem, but it's not horrible. > > We could ship a delta of the individual classes (binary diff the > actual class files too) but we chose not to do that because we > decided that 3M was small enough and the extra complexity (and > possibility of bugs) was not worth the potential gain for our use-case. As a point of interest you could still use pack200 on the JAR that contains only the changed/added files. That would may well cut the required space in half. Jeff --=_alternative 0005EBE7852572CA_= Content-Type: text/html; charset="US-ASCII"

> - In your example, you say that 3M is still large? Why do you think so, are
> the actual changes smaller? Why don't you ship the delta of each files
> instead of each complete file?
>
> 3M is still a pretty long download for a modem, but it's not horrible.
>
> We could ship a delta of the individual classes (binary diff the
> actual class files too) but we chose not to do that because we
> decided that 3M was small enough and the extra complexity (and
> possibility of bugs) was not worth the potential gain for our use-case.

As a point of interest you could still use pack200 on the JAR that contains only the changed/added files.  That would may well cut the required space in half.

Jeff --=_alternative 0005EBE7852572CA_=-- From NGZw83RUgQCo5vRX@aTpS9YBRvPQjNiNX Fri Apr 27 01:39:01 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mis010.exch010.intermedia.net (mis010.exch010.intermedia.net [64.78.61.97]) by mail.eclipse.org (Postfix) with SMTP id 3E1CC235B3 for ; Fri, 27 Apr 2007 01:39:00 -0400 (EDT) Received: from ehost010-3.exch010.intermedia.net ([64.78.61.55]) by mis010.exch010.intermedia.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 22:33:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7888C.C6C363FE" Subject: AW: [provisioning-dev] Improved update generation/distributionalgorithm Date: Thu, 26 Apr 2007 22:27:41 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] Improved update generation/distributionalgorithm Thread-Index: AceIENA5r0smGcUjQsS3Y2OWY5wgowAebFMs References: From: "Liebig, Stefan " To: X-OriginalArrivalTime: 27 Apr 2007 05:33:35.0691 (UTC) FILETIME=[99E311B0:01C7888D] X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 05:39:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7888C.C6C363FE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, that depends on the changes you make between the two versions of a = resource. As we are able to update complete JREs, we have measured a patch data = size of about 24 MB when updating from from JRE 1.5.0.10 (~70 MB) to JRE 1.6.0 (~87 MB). =20 I can =B4calculate=B4 the patch size between two jars for you. You may = send them to me or you choose some =B4well known=B4 jars which are publicly available. =20 Stefan ________________________________ Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Do 26.04.2007 17:39 An: Developer discussions for provisioning Betreff: Re: [provisioning-dev] Improved update = generation/distributionalgorithm This is really interesting too. What kind of space reduction = measurements have you gotten? Regards, Dave ----- Original Message ----- From: Stefan Liebig To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Sent: Thursday, April 26, 2007 3:41:50 AM GMT-0800 Subject: Re: [provisioning-dev] Improved update generation/distribution = algorithm I think the approach taken by us = (http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#Smartup_s= oftware_update) is somehow similar. At least we have the same = requirements. Would be nice if we could join our efforts. For that I = will give you a brief outline of our mechanism/algorithm. First our alg. updates resources from V(n) to V(n+delta) with delta>0 in = a single step. Resources might be jars, zips, dlls, docs, ... Since our solution is not (yet) eclipse based we do not have plugin jars = like eclipse has. But this is not a general restriction for our = mechanism. =20 Our mechanism is based on delta encodings = (http://en.wikipedia.org/wiki/Delta_encoding). In our particular case we have decided to use the xdelta alg. = (http://en.wikipedia.org/wiki/Xdelta) which is pretty good usable for = many types of data. However, it performs very bad when =B4diffing=B4 = compressed data like zips and jars. Because of that we unpack zips (in memory) into somthing similar to a = tar and perfom the =B4binary diffing=B4 on the different version of = these =B4tars=B4. The resulting delta (or patch) is then zipped (it = really gets smaller!) and send of the wire. =B4Applying=B4 this delta on = the =B4old=B4 version creates the =B4new=B4 version of the =B4tared=B4 = resource. The resulting version is then converted back into a zip. For this mechanism to work properly it required that versions of = resources can be uniquely identified. For this identification we use a = combination of the resource name and the MD5 hash of the resource. The = resource name is similar to the artifactId in mavens project.xml, i.e. = the name of the resource without any version specific parts in it. =20 The simplified update flow is: - the client gets somehow the information that a resource should be = updated to a newer one - therefore it asks the update server for the delta between the old and = the new version - the update server generates the delta or has it already generated and = cached and sends it back - the client applies this delta to old version and gets the new version This happens for all required resources. =20 Our update server is an active server component realized as a servlet. = It manages all resources in their different versions. The server is = capable of generating deltas in advance and keeping them in a cache for = faster response times. If a requested delta is not available it = generates them on demand. In case that a delta is requested for a =B4very=B4 old version of a = resource which is no longer available on the server (has been removed by = an administrator) the server will respond with a zipped version of the = complete resource. Every delta/patch send to the client has a type that = tells the client how to handle the =B4delta=B4. The situation that the server does not have a base (old) version for = generating a delta may also be the result of the manipulation of a = resource on the client side. The identification for this manipulated = resource (resource name + md5 hash) will most likely not reference a = resource on the server. This case will also result in returning a = complete (zipped) resource. =20 As I already mentioned it seems that Dave and we have similar = requirements but we solve them differently. The challenge will be to = provide with the new provisioning a base where different mechanisms can = be plugged in. There might also be a generalized delta layer in which Daves and our = solution could be plugged in. =20 Comments, questions? Stefan ________________________________ Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Do 26.04.2007 00:22 An: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Betreff: [provisioning-dev] Improved update generation/distribution = algorithm The current feature-based update sites can get huge quickly when small = numbers of changes are scattered across a large number of features. = This kind of situation happens easily when releasing a dot-level or a = patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are = fixed. The purpose of this email is to open a dialog and to outline our = solution. Apologies in advance for those who are less comfortable with = expressing algorithms in formal math. Time constraints have dictated = communication using the most compact and efficient means possible. The algorithm we developed worked as follows: The build server maintains copies of all production versions of the = application. In the general case, then, we need an algorithm to upgrade = a given user from a version V(n) to a version V(n+delta) where delta is = the number of versions that have elapsed since the user last upgraded. = We want this algorithm to have the following properties: * Send a minimal number of bits across the wire=20 * Be as simple as possible=20 * Be verifiably correct. We couldn't afford to have 40k-70k of broken = clients if the algorithm malfunctioned.=20 * Related to the previous: Have safeguards built-in so that if a bad = update site is ever generated, the whole thing fails fast--before *any* = bits are ever sent to clients. You will notice some conflicts in the requirements above. In = particular, the requirement to send the fewest number of bits over the = wire conflicts with the requirements to be as simple as possible and to = be verifiably correct. The result was that our algorithm sacrifices = some efficiency in the number of bits it sends over the wire in order to = be simpler and more verifiably correct. The result: In our application, going from version 1.0.0 to version = 1.0.1 using update site features resulted in about a 10 meg download. = After applying our algorithm, the download size shrunk to about 3 megs. = This is still large for some of our users who utilize a dial-up = connection, but it is doable, whereas the 10 meg download would simply = be prohibitive. Here is the algorithm: First, we simplify the problem. Instead of upgrading users from an = arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to = V(n+1). Going to V(n+delta) is simply an iteration of the algorithm = over delta steps. This simplification works fine for our user = population. If it would be acceptable for the general Eclipse = population is an open question. Second, we notice that sending JAR'd plugins is very expensive. Suppose = only two classes in a large plugin change: the whole plugin must still = be shipped. Our algorithm then is simple. We dynamically generate a function F = where F(P(V(n))) =3D P(V(n+1)). F is really just a zipped collection of = files that encodes just the files that changed between the two plugin = versions. This is accomplished using the following algorithm. For a given plugin = P in two versions V(n) and V(n+1): 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.=20 2. For files that correspond to each other in the two plugins, MD5 hash = them, and if the hashes are different, put the file from P(V(n+1)) into = F.=20 3. Include new files from P(V(n+1)) in F.=20 4. Create a text file manifest listing files in P(V(n)) that are no = longer included in P(V(n+1)) and include that text file in F.=20 5. Package all of the files in F in a zip file. =09 I believe that the algorithm for applying this function F to P(V(n)) to = get a P(V(n+1)) is self-evident. This approach has advantages over binary-diffing the two plugin jars = P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin = changes between versions, a naive binary diff algorithm will not achieve = nearly the same amount of "compression" that we achieve. So we have described a simple algorithm that is able to dramatically = reduce download bandwidth requirements over using update sites. = However, we have not described how we achieved the "fail-fast" = requirement. If a flawed update site is ever generated, we want to = detect this automatically at build time rather than after 50,000 clients = have already downloaded it and broken their installs. Here is the algorithm we use: After a build has completed, we have the following artifacts on our = build server: P(V(n)) - the old version P(V(n+1)) - the original new version generated by PDEBuild F - the function (basically an intelligent binary diff) we generated = that we can apply to P(V(n)) to get P(V(n+1)) The approach we take to validate F is the following: 1. Apply F to P(V(n)) on the build server using the same code that is = running on the clients.=20 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice = the prime there). So formally, F(P(V(n))) =3D P(V(n+1))' =09 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the = version originally generated by PDEBuild.=20 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary = directories and perform an MD5 hash on all files, making sure that all = files present in one are also present in the other and that their hashes = are equal.=20 5. If applying F to P(V(n)) on the build server using the same code as = is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) = on the server, then it should work on the clients as well. =09 In our implementation, all update site building on the build server was = done in Ruby. The effort to implement the server side of this algorithm = in Ruby was about three days. The effort to implement the client-side = (fully unit-tested, pair-programmed, one pair programming team working = on it full-time) in Java was about a month. This was due to the hassle = of working with Java input and output streams. However, the result was = that the Java code worked entirely in memory, piping input streams into = output streams and so on until only the final results were written to = disk. Thus, the Java solution would be immune to breakage resulting = from something on the file system being changed in a way we did not = expect. Let me know if you have any questions. Regards, Dave Orme ------_=_NextPart_001_01C7888C.C6C363FE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Well, that = depends on the changes you make between the two versions of a = resource.
=0A=
As we are able to update = complete JREs, we have measured a patch data size of about 24 = MB
=0A=
when updating from from JRE = 1.5.0.10 (~70 MB) to JRE 1.6.0 (~87 MB).
=0A=
 
=0A=
I can =B4calculate=B4 the = patch size between two jars for you. You may send them to me = or
=0A=
you choose some =B4well = known=B4 jars which are publicly available.
=0A=
 
=0A=
Stefan
=0A=

=0A=
=0A= Von: = fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. = Orme
Gesendet: Do 26.04.2007 17:39
An: Developer = discussions for provisioning
Betreff: Re: [provisioning-dev] = Improved update generation/distributionalgorithm

=0A=
This is really interesting too.  What kind of space reduction = measurements have you gotten?


Regards,

Dave
----- = Original Message -----
From: Stefan Liebig = <NGZw83RUgQCo5vRX@aTpS9YBRvPQjNiNX>
To: = bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Sent: Thursday, April 26, 2007 3:41:50 = AM GMT-0800
Subject: Re: [provisioning-dev] Improved update = generation/distribution algorithm

=0A=
=0A=
I think the = approach taken by us (http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospec= tives#Smartup_software_update) is somehow similar. At least we have = the same requirements. Would be nice if we could join our efforts. For = that I will give you a brief outline of our = mechanism/algorithm.
=0A=
First our = alg. updates resources from V(n) to V(n+delta) with delta>0 in a = single step. Resources might be jars, zips, dlls, docs, ...
Since our = solution is not (yet) eclipse based we do not have plugin jars like = eclipse has. But this is not a general restriction for our = mechanism.
=0A=
 
=0A=
Our mechanism = is based on delta encodings (http://en.wikipedia.org/wiki/Delta_encoding).
In = our particular case we have decided to use the xdelta alg. (http://en.wikipedia.org/wiki/Xdelta) which is pretty = good usable for many types of data. However, it performs very bad when = =B4diffing=B4 compressed data like zips and jars.
Because of that we = unpack zips (in memory) into somthing similar to a tar and perfom the = =B4binary diffing=B4 on the different version of these =B4tars=B4. The = resulting delta (or patch) is then zipped (it really gets smaller!) and = send of the wire. =B4Applying=B4 this delta on the =B4old=B4 version = creates the =B4new=B4 version of the =B4tared=B4 resource. The resulting = version is then converted back into a zip.
For this mechanism to work = properly it required that versions of resources can be uniquely = identified. For this identification we use a combination of the resource = name and the MD5 hash of the resource. The resource name is similar to = the artifactId in mavens project.xml, i.e. the name of the resource = without any version specific parts in it.
=0A=
 
=0A=
The = simplified update flow is:
- the client gets somehow the information = that a resource should be updated to a newer one
- therefore it asks = the update server for the delta between the old and the new version
- = the update server generates the delta or has it already generated and = cached and sends it back
- the client applies this delta to old = version and gets the new version
=0A=
This happens = for all required resources.
=0A=
 
=0A=
Our update = server is an active server component realized as a servlet. It manages = all resources in their different versions. The server is capable of = generating deltas in advance and keeping them in a cache for faster = response times. If a requested delta is not available it generates them = on demand.
In case that a delta is requested for a =B4very=B4 old = version of a resource which is no longer available on the server (has = been removed by an administrator) the server will respond with a zipped = version of the complete resource. Every delta/patch send to the client = has a type that tells the client how to handle the =B4delta=B4.
The = situation that the server does not have a base (old) version for = generating a delta may also be the result of the manipulation of a = resource on the client side. The identification for this manipulated = resource (resource name + md5 hash) will most likely not reference a = resource on the server. This case will also result in returning a = complete (zipped) resource.
=0A=
 
=0A=
As I already = mentioned it seems that Dave and we have similar requirements but we = solve them differently. The challenge will be to provide with the new = provisioning a base where different mechanisms can be plugged = in.
There might also be a generalized delta layer in which Daves and = our solution could be plugged in.
=0A=
 
=0A=
Comments, = questions?
=0A=

Stefan
=0A=
=0A=
=0A=

=0A=
=0A= Von: = fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. = Orme
Gesendet: Do 26.04.2007 00:22
An: = bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Betreff: [provisioning-dev] = Improved update generation/distribution algorithm

=0A=
The current feature-based update sites can get huge quickly when = small numbers of changes are scattered across a large number of = features.  This kind of situation happens easily when releasing a = dot-level or a patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of = small bugs are fixed.

The purpose of this email is to open a = dialog and to outline our solution.  Apologies in advance for those = who are less comfortable with expressing algorithms in formal = math.  Time constraints have dictated communication using the most = compact and efficient means possible.

The algorithm we developed = worked as follows:

The build server maintains copies of all = production versions of the application.  In the general case, then, = we need an algorithm to upgrade a given user from a version V(n) to a = version V(n+delta) where delta is the number of versions that have = elapsed since the user last upgraded.  We want this algorithm to = have the following properties:
=0A=
    =0A=
  • Send a minimal number of bits across the wire =0A=
  • Be as simple as possible =0A=
  • Be verifiably correct.  We couldn't afford to have 40k-70k of = broken clients if the algorithm malfunctioned. =0A=
  • Related to the previous: Have safeguards built-in so that if a bad = update site is ever generated, the whole thing fails fast--before *any* = bits are ever sent to clients.
You will notice some conflicts = in the requirements above.  In particular, the requirement to send = the fewest number of bits over the wire conflicts with the requirements = to be as simple as possible and to be verifiably correct.  The = result was that our algorithm sacrifices some efficiency in the number = of bits it sends over the wire in order to be simpler and more = verifiably correct.

The result: In our application, going from = version 1.0.0 to version 1.0.1 using update site features resulted in = about a 10 meg download.  After applying our algorithm, the = download size shrunk to about 3 megs.  This is still large for some = of our users who utilize a dial-up connection, but it is doable, whereas = the 10 meg download would simply be prohibitive.

Here is the = algorithm:

First, we simplify the problem.  Instead of = upgrading users from an arbitrary version V(n) to V(n+delta), we only = upgrade them from V(n) to V(n+1).  Going to V(n+delta) is simply an = iteration of the algorithm over delta steps.  This simplification = works fine for our user population.  If it would be acceptable for = the general Eclipse population is an open question.

Second, we = notice that sending JAR'd plugins is very expensive.  Suppose only = two classes in a large plugin change: the whole plugin must still be = shipped.

Our algorithm then is simple.  We dynamically = generate a function F where F(P(V(n))) =3D P(V(n+1)).  F is really = just a zipped collection of files that encodes just the files that = changed between the two plugin versions.

This is accomplished = using the following algorithm.  For a given plugin P in two = versions V(n) and V(n+1):
=0A=
    =0A=
  1. Unpack P(V(n)) and P(V(n+1)) into temporary directories. =0A=
  2. For files that correspond to each other in the two plugins, MD5 hash = them, and if the hashes are different, put the file from P(V(n+1)) into = F. =0A=
  3. Include new files from P(V(n+1)) in F. =0A=
  4. Create a text file manifest listing files in P(V(n)) that are no = longer included in P(V(n+1)) and include that text file in F. =0A=
  5. Package all of the files in F in a zip file.
I believe = that the algorithm for applying this function F to P(V(n)) to get a = P(V(n+1)) is self-evident.

This approach has advantages over = binary-diffing the two plugin jars P(V(n)) and P(V(n+1)): If the order = of the files contained in the plugin changes between versions, a naive = binary diff algorithm will not achieve nearly the same amount of = "compression" that we achieve.

So we have described a simple = algorithm that is able to dramatically reduce download bandwidth = requirements over using update sites.  However, we have not = described how we achieved the "fail-fast" requirement.  If a flawed = update site is ever generated, we want to detect this automatically at = build time rather than after 50,000 clients have already downloaded it = and broken their installs.

Here is the algorithm we = use:

After a build has completed, we have the following artifacts = on our build server:

P(V(n)) - the old version
P(V(n+1)) - the = original new version generated by PDEBuild
F - the function = (basically an intelligent binary diff) we generated that we can apply to = P(V(n)) to get P(V(n+1))

The approach we take to validate F is = the following:
=0A=
    =0A=
  1. Apply F to P(V(n)) on the build server using the same code that is = running on the clients. =0A=
  2. Let's call the result of applying F to P(V(n)), P(V(n+1))'  = (notice the prime there).  So formally, F(P(V(n))) =3D = P(V(n+1))'
    =0A=
  3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the = version originally generated by PDEBuild. =0A=
  4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary = directories and perform an MD5 hash on all files, making sure that all = files present in one are also present in the other and that their hashes = are equal. =0A=
  5. If applying F to P(V(n)) on the build server using the same code as = is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) = on the server, then it should work on the clients as = well.
In our implementation, all update site building on = the build server was done in Ruby.  The effort to implement the = server side of this algorithm in Ruby was about three days.  The = effort to implement the client-side (fully unit-tested, pair-programmed, = one pair programming team working on it full-time) in Java was about a = month.  This was due to the hassle of working with Java input and = output streams.  However, the result was that the Java code worked = entirely in memory, piping input streams into output streams and so on = until only the final results were written to disk.  Thus, the Java = solution would be immune to breakage resulting from something on the = file system being changed in a way we did not expect.

Let me know = if you have any questions.


Regards,

Dave = Orme

------_=_NextPart_001_01C7888C.C6C363FE-- From L4z5JpgB9u8VG8O1@Yp5HW06labJ8PMwQ Fri Apr 27 10:49:12 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from peanut.coconut-palm-software.com (coconut-palm-software.com [64.81.137.6]) by mail.eclipse.org (Postfix) with SMTP id E338B2EDE5 for ; Fri, 27 Apr 2007 10:49:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by peanut.coconut-palm-software.com (Postfix) with ESMTP id CA6DE17B8EB0 for ; Fri, 27 Apr 2007 10:43:34 -0500 (CDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Apr 27 10:43:33 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 46321a25289311748359437 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1, HTML_10_20=1.351, HTML_MESSAGE=0.001] Received: from peanut.coconut-palm-software.com ([127.0.0.1]) by localhost (peanut.coconut-palm-software.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij-KGUI4o2ZU for ; Fri, 27 Apr 2007 10:43:32 -0500 (CDT) Received: from peanut.coconut-palm-software.com (peanut.coconut-palm-software.com [192.168.0.11]) by peanut.coconut-palm-software.com (Postfix) with ESMTP id 9E75A17B8E70 for ; Fri, 27 Apr 2007 10:43:32 -0500 (CDT) Message-ID: Date: Fri, 27 Apr 2007 10:43:32 -0500 (CDT) From: "David J. Orme" To: Developer discussions for provisioning Subject: Re: AW: [provisioning-dev] Improved update generation/distributionalgorithm In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1349_8691817.1177688612502" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 14:49:13 -0000 ------=_Part_1349_8691817.1177688612502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the data. What I was hoping you could do was give specific data = on the mailing list about a delta you ran: the size of the application; ver= sion numbers, size of the download, and so on. It's probably more important= to know the type of upgrade (a minor version, a patch, etc) and the size o= f the code base than exact numbers, although exact numbers are useful too.= =20 We have one use-case; you have another. The more use-cases we can discuss o= n the list, the better the solution we eventually evolve is likely to be.= =20 BTW, in the abstract, I *really* like your algorithm. It sounds simpler tha= n ours and as you point out it can deal with upgrading JREs, not just plugi= ns/bundles.=20 Regards,=20 Dave Orme=20 ----- Original Message -----=20 From: Stefan Liebig =20 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg=20 Sent: Friday, April 27, 2007 0:27:41 AM GMT-0800=20 Subject: AW: [provisioning-dev] Improved update generation/distributionalgo= rithm=20 Well, that depends on the changes you make between the two versions of a re= source.=20 As we are able to update complete JREs, we have measured a patch data size = of about 24 MB=20 when updating from from JRE 1.5.0.10 (~70 MB) to JRE 1.6.0 (~87 MB).=20 I can =C2=B4calculate=C2=B4 the patch size between two jars for you. You ma= y send them to me or=20 you choose some =C2=B4well known=C2=B4 jars which are publicly available.= =20 Stefan=20 Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme=20 Gesendet: Do 26.04.2007 17:39=20 An: Developer discussions for provisioning=20 Betreff: Re: [provisioning-dev] Improved update generation/distributionalgo= rithm=20 This is really interesting too. What kind of space reduction measurements h= ave you gotten?=20 Regards,=20 Dave=20 ----- Original Message -----=20 From: Stefan Liebig =20 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg=20 Sent: Thursday, April 26, 2007 3:41:50 AM GMT-0800=20 Subject: Re: [provisioning-dev] Improved update generation/distribution alg= orithm=20 I think the approach taken by us ( http://wiki.eclipse.org/index.php/GPW_Li= ghtning_Retrospectives#Smartup_software_update ) is somehow similar. At lea= st we have the same requirements. Would be nice if we could join our effort= s. For that I will give you a brief outline of our mechanism/algorithm.=20 First our alg. updates resources from V(n) to V(n+delta) with delta>0 in a = single step. Resources might be jars, zips, dlls, docs, ...=20 Since our solution is not (yet) eclipse based we do not have plugin jars li= ke eclipse has. But this is not a general restriction for our mechanism.=20 Our mechanism is based on delta encodings ( http://en.wikipedia.org/wiki/De= lta_encoding ).=20 In our particular case we have decided to use the xdelta alg. ( http://en.w= ikipedia.org/wiki/Xdelta ) which is pretty good usable for many types of da= ta. However, it performs very bad when =C2=B4diffing=C2=B4 compressed data = like zips and jars.=20 Because of that we unpack zips (in memory) into somthing similar to a tar a= nd perfom the =C2=B4binary diffing=C2=B4 on the different version of these = =C2=B4tars=C2=B4. The resulting delta (or patch) is then zipped (it really = gets smaller!) and send of the wire. =C2=B4Applying=C2=B4 this delta on the= =C2=B4old=C2=B4 version creates the =C2=B4new=C2=B4 version of the =C2=B4t= ared=C2=B4 resource. The resulting version is then converted back into a zi= p.=20 For this mechanism to work properly it required that versions of resources = can be uniquely identified. For this identification we use a combination of= the resource name and the MD5 hash of the resource. The resource name is s= imilar to the artifactId in mavens project.xml, i.e. the name of the resour= ce without any version specific parts in it.=20 The simplified update flow is:=20 - the client gets somehow the information that a resource should be updated= to a newer one=20 - therefore it asks the update server for the delta between the old and the= new version=20 - the update server generates the delta or has it already generated and cac= hed and sends it back=20 - the client applies this delta to old version and gets the new version=20 This happens for all required resources.=20 Our update server is an active server component realized as a servlet. It m= anages all resources in their different versions. The server is capable of = generating deltas in advance and keeping them in a cache for faster respons= e times. If a requested delta is not available it generates them on demand.= =20 In case that a delta is requested for a =C2=B4very=C2=B4 old version of a r= esource which is no longer available on the server (has been removed by an = administrator) the server will respond with a zipped version of the complet= e resource. Every delta/patch send to the client has a type that tells the = client how to handle the =C2=B4delta=C2=B4.=20 The situation that the server does not have a base (old) version for genera= ting a delta may also be the result of the manipulation of a resource on th= e client side. The identification for this manipulated resource (resource n= ame + md5 hash) will most likely not reference a resource on the server. Th= is case will also result in returning a complete (zipped) resource.=20 As I already mentioned it seems that Dave and we have similar requirements = but we solve them differently. The challenge will be to provide with the ne= w provisioning a base where different mechanisms can be plugged in.=20 There might also be a generalized delta layer in which Daves and our soluti= on could be plugged in.=20 Comments, questions?=20 Stefan=20 Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme=20 Gesendet: Do 26.04.2007 00:22=20 An: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg=20 Betreff: [provisioning-dev] Improved update generation/distribution algorit= hm=20 The current feature-based update sites can get huge quickly when small numb= ers of changes are scattered across a large number of features. This kind o= f situation happens easily when releasing a dot-level or a patchlevel upgra= de--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed.=20 The purpose of this email is to open a dialog and to outline our solution. = Apologies in advance for those who are less comfortable with expressing alg= orithms in formal math. Time constraints have dictated communication using = the most compact and efficient means possible.=20 The algorithm we developed worked as follows:=20 The build server maintains copies of all production versions of the applica= tion. In the general case, then, we need an algorithm to upgrade a given us= er from a version V(n) to a version V(n+delta) where delta is the number of= versions that have elapsed since the user last upgraded. We want this algo= rithm to have the following properties:=20 =E2=80=A2 Send a minimal number of bits across the wire=20 =E2=80=A2 Be as simple as possible=20 =E2=80=A2 Be verifiably correct. We couldn't afford to have 40k-70k of = broken clients if the algorithm malfunctioned.=20 =E2=80=A2 Related to the previous: Have safeguards built-in so that if = a bad update site is ever generated, the whole thing fails fast--before *an= y* bits are ever sent to clients.=20 You will notice some conflicts in the requirements above. In particular, th= e requirement to send the fewest number of bits over the wire conflicts wit= h the requirements to be as simple as possible and to be verifiably correct= . The result was that our algorithm sacrifices some efficiency in the numbe= r of bits it sends over the wire in order to be simpler and more verifiably= correct.=20 The result: In our application, going from version 1.0.0 to version 1.0.1 u= sing update site features resulted in about a 10 meg download. After applyi= ng our algorithm, the download size shrunk to about 3 megs. This is still l= arge for some of our users who utilize a dial-up connection, but it is doab= le, whereas the 10 meg download would simply be prohibitive.=20 Here is the algorithm:=20 First, we simplify the problem. Instead of upgrading users from an arbitrar= y version V(n) to V(n+delta), we only upgrade them from V(n) to V(n+1). Goi= ng to V(n+delta) is simply an iteration of the algorithm over delta steps. = This simplification works fine for our user population. If it would be acce= ptable for the general Eclipse population is an open question.=20 Second, we notice that sending JAR'd plugins is very expensive. Suppose onl= y two classes in a large plugin change: the whole plugin must still be ship= ped.=20 Our algorithm then is simple. We dynamically generate a function F where F(= P(V(n))) =3D P(V(n+1)). F is really just a zipped collection of files that = encodes just the files that changed between the two plugin versions.=20 This is accomplished using the following algorithm. For a given plugin P in= two versions V(n) and V(n+1):=20 2. Unpack P(V(n)) and P(V(n+1)) into temporary directories.=20 3. For files that correspond to each other in the two plugins, MD5 hash= them, and if the hashes are different, put the file from P(V(n+1)) into F.= =20 4. Include new files from P(V(n+1)) in F.=20 5. Create a text file manifest listing files in P(V(n)) that are no lon= ger included in P(V(n+1)) and include that text file in F.=20 6. Package all of the files in F in a zip file.=20 I believe that the algorithm for applying this function F to P(V(n)) to get= a P(V(n+1)) is self-evident.=20 This approach has advantages over binary-diffing the two plugin jars P(V(n)= ) and P(V(n+1)): If the order of the files contained in the plugin changes = between versions, a naive binary diff algorithm will not achieve nearly the= same amount of "compression" that we achieve.=20 So we have described a simple algorithm that is able to dramatically reduce= download bandwidth requirements over using update sites. However, we have = not described how we achieved the "fail-fast" requirement. If a flawed upda= te site is ever generated, we want to detect this automatically at build ti= me rather than after 50,000 clients have already downloaded it and broken t= heir installs.=20 Here is the algorithm we use:=20 After a build has completed, we have the following artifacts on our build s= erver:=20 P(V(n)) - the old version=20 P(V(n+1)) - the original new version generated by PDEBuild=20 F - the function (basically an intelligent binary diff) we generated that w= e can apply to P(V(n)) to get P(V(n+1))=20 The approach we take to validate F is the following:=20 2. Apply F to P(V(n)) on the build server using the same code that is r= unning on the clients.=20 3. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice t= he prime there). So formally, F(P(V(n))) =3D P(V(n+1))'=20 4. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the versi= on originally generated by PDEBuild.=20 5. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary= directories and perform an MD5 hash on all files, making sure that all fil= es present in one are also present in the other and that their hashes are e= qual.=20 6. If applying F to P(V(n)) on the build server using the same code as = is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on t= he server, then it should work on the clients as well.=20 In our implementation, all update site building on the build server was don= e in Ruby. The effort to implement the server side of this algorithm in Rub= y was about three days. The effort to implement the client-side (fully unit= -tested, pair-programmed, one pair programming team working on it full-time= ) in Java was about a month. This was due to the hassle of working with Jav= a input and output streams. However, the result was that the Java code work= ed entirely in memory, piping input streams into output streams and so on u= ntil only the final results were written to disk. Thus, the Java solution w= ould be immune to breakage resulting from something on the file system bein= g changed in a way we did not expect.=20 Let me know if you have any questions.=20 Regards,=20 Dave Orme=20 ------=_Part_1349_8691817.1177688612502 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the data.  What I was hoping you could do was g= ive specific data on the mailing list about a delta you ran: the size of th= e application; version numbers, size of the download, and so on.  It's= probably more important to know the type of upgrade (a minor version, a pa= tch, etc) and the size of the code base than exact numbers, although exact = numbers are useful too.

We have one use-case; you have another. = ; The more use-cases we can discuss on the list, the better the solution we= eventually evolve is likely to be.

BTW, in the abstract, I *really*= like your algorithm.  It sounds simpler than ours and as you point ou= t it can deal with upgrading JREs, not just plugins/bundles.


Reg= ards,

Dave Orme
----- Original Message -----
From: Stefan Lieb= ig <NGZw83RUgQCo5vRX@aTpS9YBRvPQjNiNX>
To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xgSent: Friday, April 27, 2007 0:27:41 AM GMT-0800
Subject: AW: [provisi= oning-dev] Improved update generation/distributionalgorithm

Well, th= at depends on the changes you make between the two versions of a resource.<= /font>
As we are able to upd= ate complete JREs, we have measured a patch data size of about 24 MB=
when updating from from JR= E 1.5.0.10 (~70 MB) to JRE 1.6.0 (~87 MB).
 
I can =C2=B4calculate=C2= =B4 the patch size between two jars for you. You may send them to me o= r
you choose some =C2=B4well= known=C2=B4 jars which are publicly available.
 
Stefan


Von: provisioning-dev-bounces@eclip= se.org im Auftrag von David J. Orme
Gesendet: Do 26.04.2007 17:39=
An: Developer discussions for provisioning
Betreff: Re= : [provisioning-dev] Improved update generation/distributionalgorithm

This is really interesting too.  What kind of space reduction mea= surements have you gotten?


Regards,

Dave
----- Origina= l Message -----
From: Stefan Liebig <NGZw83RUgQCo5vRX@aTpS9YBRvPQjNiNX>To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Sent: Thursday, April 26, 2007 3:41:5= 0 AM GMT-0800
Subject: Re: [provisioning-dev] Improved update generation= /distribution algorithm

I think = the approach taken by us (http://= wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#Smartup_software_up= date) is somehow similar. At least we have the same requirements. Would= be nice if we could join our efforts. For that I will give you a brief out= line of our mechanism/algorithm.
First ou= r alg. updates resources from V(n) to V(n+delta) with delta>0 in a singl= e step. Resources might be jars, zips, dlls, docs, ...
Since our solutio= n is not (yet) eclipse based we do not have plugin jars like eclipse has. B= ut this is not a general restriction for our mechanism.
 
Our mech= anism is based on delta encodings (http://en.wikipedia.org/wiki/Delta_encodi= ng).
In our particular case we have decided to use the xdelta alg. (= http://en= .wikipedia.org/wiki/Xdelta) which is pretty good usable for many types = of data. However, it performs very bad when =C2=B4diffing=C2=B4 compressed = data like zips and jars.
Because of that we unpack zips (in memory) into= somthing similar to a tar and perfom the =C2=B4binary diffing=C2=B4 on the= different version of these =C2=B4tars=C2=B4. The resulting delta (or patch= ) is then zipped (it really gets smaller!) and send of the wire. =C2=B4Appl= ying=C2=B4 this delta on the =C2=B4old=C2=B4 version creates the =C2=B4new= =C2=B4 version of the =C2=B4tared=C2=B4 resource. The resulting version is = then converted back into a zip.
For this mechanism to work properly it r= equired that versions of resources can be uniquely identified. For this ide= ntification we use a combination of the resource name and the MD5 hash of t= he resource. The resource name is similar to the artifactId in mavens proje= ct.xml, i.e. the name of the resource without any version specific parts in= it.
 
The simp= lified update flow is:
- the client gets somehow the information that a = resource should be updated to a newer one
- therefore it asks the update= server for the delta between the old and the new version
- the update s= erver generates the delta or has it already generated and cached and sends = it back
- the client applies this delta to old version and gets the new = version
This hap= pens for all required resources.
 
Our upda= te server is an active server component realized as a servlet. It manages a= ll resources in their different versions. The server is capable of generati= ng deltas in advance and keeping them in a cache for faster response times.= If a requested delta is not available it generates them on demand.
In c= ase that a delta is requested for a =C2=B4very=C2=B4 old version of a resou= rce which is no longer available on the server (has been removed by an admi= nistrator) the server will respond with a zipped version of the complete re= source. Every delta/patch send to the client has a type that tells the clie= nt how to handle the =C2=B4delta=C2=B4.
The situation that the server do= es not have a base (old) version for generating a delta may also be the res= ult of the manipulation of a resource on the client side. The identificatio= n for this manipulated resource (resource name + md5 hash) will most likely= not reference a resource on the server. This case will also result in retu= rning a complete (zipped) resource.
&= nbsp;
As I alr= eady mentioned it seems that Dave and we have similar requirements but we s= olve them differently. The challenge will be to provide with the new provis= ioning a base where different mechanisms can be plugged in.
There might = also be a generalized delta layer in which Daves and our solution could be = plugged in.
&= nbsp;
Comments= , questions?

Stef= an


Von: provisioning-dev-bounces@eclip= se.org im Auftrag von David J. Orme
Gesendet: Do 26.04.2007 00:22=
An: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Betreff: [provisionin= g-dev] Improved update generation/distribution algorithm

The current feature-based update sites can get huge quickly when small= numbers of changes are scattered across a large number of features.  = This kind of situation happens easily when releasing a dot-level or a patch= level upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed.
<= br>The purpose of this email is to open a dialog and to outline our solutio= n.  Apologies in advance for those who are less comfortable with expre= ssing algorithms in formal math.  Time constraints have dictated commu= nication using the most compact and efficient means possible.

The al= gorithm we developed worked as follows:

The build server maintains c= opies of all production versions of the application.  In the general c= ase, then, we need an algorithm to upgrade a given user from a version V(n)= to a version V(n+delta) where delta is the number of versions that have el= apsed since the user last upgraded.  We want this algorithm to have th= e following properties:
  • Send a minimal number of bits across the wire=20
  • Be as simple as possible=20
  • Be verifiably correct.  We couldn't afford to have 40k-70k of= broken clients if the algorithm malfunctioned.=20
  • Related to the previous: Have safeguards built-in so that if a bad= update site is ever generated, the whole thing fails fast--before *any* bi= ts are ever sent to clients.
You will notice some conflicts in the= requirements above.  In particular, the requirement to send the fewes= t number of bits over the wire conflicts with the requirements to be as sim= ple as possible and to be verifiably correct.  The result was that our= algorithm sacrifices some efficiency in the number of bits it sends over t= he wire in order to be simpler and more verifiably correct.

The resu= lt: In our application, going from version 1.0.0 to version 1.0.1 using upd= ate site features resulted in about a 10 meg download.  After applying= our algorithm, the download size shrunk to about 3 megs.  This is sti= ll large for some of our users who utilize a dial-up connection, but it is = doable, whereas the 10 meg download would simply be prohibitive.

Her= e is the algorithm:

First, we simplify the problem.  Instead of= upgrading users from an arbitrary version V(n) to V(n+delta), we only upgr= ade them from V(n) to V(n+1).  Going to V(n+delta) is simply an iterat= ion of the algorithm over delta steps.  This simplification works fine= for our user population.  If it would be acceptable for the general E= clipse population is an open question.

Second, we notice that sendin= g JAR'd plugins is very expensive.  Suppose only two classes in a larg= e plugin change: the whole plugin must still be shipped.

Our algorit= hm then is simple.  We dynamically generate a function F where F(P(V(n= ))) =3D P(V(n+1)).  F is really just a zipped collection of files that= encodes just the files that changed between the two plugin versions.
This is accomplished using the following algorithm.  For a given plu= gin P in two versions V(n) and V(n+1):
  1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.=20
  2. For files that correspond to each other in the two plugins, MD5 ha= sh them, and if the hashes are different, put the file from P(V(n+1)) into = F.=20
  3. Include new files from P(V(n+1)) in F.=20
  4. Create a text file manifest listing files in P(V(n)) that are no l= onger included in P(V(n+1)) and include that text file in F.=20
  5. Package all of the files in F in a zip file.
I believ= e that the algorithm for applying this function F to P(V(n)) to get a P(V(n= +1)) is self-evident.

This approach has advantages over binary-diffi= ng the two plugin jars P(V(n)) and P(V(n+1)): If the order of the files con= tained in the plugin changes between versions, a naive binary diff algorith= m will not achieve nearly the same amount of "compression" that we achieve.=

So we have described a simple algorithm that is able to dramaticall= y reduce download bandwidth requirements over using update sites.  How= ever, we have not described how we achieved the "fail-fast" requirement.&nb= sp; If a flawed update site is ever generated, we want to detect this autom= atically at build time rather than after 50,000 clients have already downlo= aded it and broken their installs.

Here is the algorithm we use:
=
After a build has completed, we have the following artifacts on our bui= ld server:

P(V(n)) - the old version
P(V(n+1)) - the original new= version generated by PDEBuild
F - the function (basically an intelligen= t binary diff) we generated that we can apply to P(V(n)) to get P(V(n+1))
The approach we take to validate F is the following:
  1. Apply F to P(V(n)) on the build server using the same code that is runn= ing on the clients.=20
  2. Let's call the result of applying F to P(V(n)), P(V(n+1))'  (= notice the prime there).  So formally, F(P(V(n))) =3D P(V(n+1))'
  3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the ver= sion originally generated by PDEBuild.=20
  4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into tempora= ry directories and perform an MD5 hash on all files, making sure that all f= iles present in one are also present in the other and that their hashes are= equal.=20
  5. If applying F to P(V(n)) on the build server using the same code a= s is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on= the server, then it should work on the clients as well.
In ou= r implementation, all update site building on the build server was done in = Ruby.  The effort to implement the server side of this algorithm in Ru= by was about three days.  The effort to implement the client-side (ful= ly unit-tested, pair-programmed, one pair programming team working on it fu= ll-time) in Java was about a month.  This was due to the hassle of wor= king with Java input and output streams.  However, the result was that= the Java code worked entirely in memory, piping input streams into output = streams and so on until only the final results were written to disk.  = Thus, the Java solution would be immune to breakage resulting from somethin= g on the file system being changed in a way we did not expect.

Let m= e know if you have any questions.


Regards,

Dave Orme
<= br>
------=_Part_1349_8691817.1177688612502-- From FkJqwWsCkGROpO8g@b0C/ARcn5yziq/5u Fri Apr 27 19:54:34 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from hotelroom3.mainloop.net (hotelroom3.mainloop.net [192.71.58.59]) by mail.eclipse.org (Postfix) with SMTP id 64ED823FD9 for ; Fri, 27 Apr 2007 19:54:34 -0400 (EDT) Received: (qmail 28079 invoked from network); 28 Apr 2007 01:53:13 +0200 Received: from nat-sloane.pilsfree.net (HELO ?10.109.233.159?) (62.240.183.254) by www-hotelroom3.mainloop.net with SMTP; 28 Apr 2007 01:53:13 +0200 Message-ID: Date: Sat, 28 Apr 2007 01:53:31 +0200 From: Filip Hrbek Organization: Cloudsmith Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [provisioning-dev] Project intersections X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 23:54:35 -0000 Hi, I added some comments to the project intersection page http://wiki.eclipse.org/index.php/Provisioning_Project_Intersections#Project_Intersections Our comments describe how the Buckminster projects currently solves intersecting issues. Could you please post a few sentences like this (what you've solved/plan to solve) for other projects as well to clarify where the real intersections are? Regards Filip From MYT0nPY83jCveYQt@EOCq6JOAWVtjPI0r Mon Apr 30 15:04:38 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mail.eclipse.org (Postfix) with SMTP id 15E07F3988 for ; Mon, 30 Apr 2007 15:04:37 -0400 (EDT) Received: from [212.227.126.200] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Hib9T-0000pB-00 for bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg; Mon, 30 Apr 2007 21:03:11 +0200 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1Hib9S-0000l8-02 for bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg; Mon, 30 Apr 2007 21:03:10 +0200 Received: from mapibe10.exchange.xchg ([172.23.1.38]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 21:03:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Apr 2007 21:03:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Common Bugzilla Query Thread-Index: AceLWi7MQoyAi/NoQvqah9MI/AA3ew== From: "Volanakis, Elias" To: X-OriginalArrivalTime: 30 Apr 2007 19:03:09.0409 (UTC) FILETIME=[31517D10:01C78B5A] X-Provags-ID: kundenserver.de mFit/2ULPjzYnh9d@uAVsZ3wjdw/a/1s6 ident:@172.23.1.26 Subject: [provisioning-dev] Common Bugzilla Query X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2007 19:04:38 -0000 Hi *, as discussed in the workshop, there is now a common bugzilla query that can be used to show all provisioning related bugs.=20 http://wiki.eclipse.org/index.php/Bugzilla_Query_%28Provisioning%29 "All" is a bit of an overstatement, since it currently shows only Equinox provisioning bugs :), but I expect it to include more projects over time. If you wish to be added to the query you can either follow the instructions on the page or contact me by sending a mail to this list. Regards, Elias. --- Elias Volanakis Eclipse-Consultant +49 721 664 733 0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Legal Disclaimer = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D According to Section 80 of the German Corporation Act Innoopract=20 Informationssysteme GmbH must indicate the following information: Address: Stephanienstrasse 20, 76133 Karlsruhe Germany=20 General Manager: Jochen Krause, Eric von der Heyden=20 Registered Office: Karlsruhe, Commercial Register Karlsruhe HRB 7883=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From NGZw83RUgQCo5vRX@aTpS9YBRvPQjNiNX Wed May 2 05:28:42 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mis010.exch010.intermedia.net (mis010.exch010.intermedia.net [64.78.61.97]) by mail.eclipse.org (Postfix) with SMTP id CE2C22B2BB for ; Wed, 2 May 2007 05:28:40 -0400 (EDT) Received: from ehost010-3.exch010.intermedia.net ([64.78.61.55]) by mis010.exch010.intermedia.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 02:23:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78C9B.7BDB32FE" Subject: AW: AW: [provisioning-dev] Improved updategeneration/distributionalgorithm Date: Wed, 2 May 2007 02:23:02 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [provisioning-dev] Improved updategeneration/distributionalgorithm Thread-Index: AceI2pMq/dsZiW/XQf+GtFUILvhTrgDv7JeA References: From: "Liebig, Stefan " To: X-OriginalArrivalTime: 02 May 2007 09:23:04.0305 (UTC) FILETIME=[7CAF9610:01C78C9B] X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 09:28:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C78C9B.7BDB32FE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dave, =20 To be more specific I took the sources of junit 3.8.1. Created an Eclipse project for it and let Eclipse create the jar(s) for me. =20 =B4Original=B4 size of the jar: 119.959 byte =20 Than I made some modifications and generated the deltas=20 between the jars: =20 - fixed an unneccessary cast in junit.swingui.TestTreeModel Size of changed TestTreeModel.class: 4959 byte Resulting delta to original: 1534 byte =20 - added a simple bean with 4 properties (setters/getters) Jar size: 120.604 Bean.class size: 1204 Resulting delta to original: 1173 byte =20 - changed the name of a interface method from junit.framework.Test.run() to junit.framework.Test.lauf() Jar size: 120.020 byte this affects 7 classes Jar size: 120.020 byte Resulting delta to original: 7889 byte =20 We transmit (download) each delta of a *changed* resource with a single HTTP/S request/response. The above deltas are the raw data. You have to add some bytes for the http protocol stuff and a few bytes for some type information, so that the client can distinguish between different patch types. If the server has been requested for a delta (patch), but the server is = no=20 longer able to generate the delta because the original version is no = longer=20 available (removed by an admin to save space,..) the server responses = with=20 a compressed version of the latest version. This type information tells = the=20 client how to handle the =B4patch=B4 (not neccessarily a delta!). I hope that this information is helpful. =20 Stefan =20 ________________________________ Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Fr 27.04.2007 17:43 An: Developer discussions for provisioning Betreff: Re: AW: [provisioning-dev] Improved = updategeneration/distributionalgorithm Thanks for the data. What I was hoping you could do was give specific = data on the mailing list about a delta you ran: the size of the = application; version numbers, size of the download, and so on. It's = probably more important to know the type of upgrade (a minor version, a = patch, etc) and the size of the code base than exact numbers, although = exact numbers are useful too. We have one use-case; you have another. The more use-cases we can = discuss on the list, the better the solution we eventually evolve is = likely to be. BTW, in the abstract, I *really* like your algorithm. It sounds simpler = than ours and as you point out it can deal with upgrading JREs, not just = plugins/bundles. Regards, Dave Orme ----- Original Message ----- From: Stefan Liebig To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Sent: Friday, April 27, 2007 0:27:41 AM GMT-0800 Subject: AW: [provisioning-dev] Improved update = generation/distributionalgorithm Well, that depends on the changes you make between the two versions of a = resource. As we are able to update complete JREs, we have measured a patch data = size of about 24 MB when updating from from JRE 1.5.0.10 (~70 MB) to JRE 1.6.0 (~87 MB). =20 I can =B4calculate=B4 the patch size between two jars for you. You may = send them to me or you choose some =B4well known=B4 jars which are publicly available. =20 Stefan ________________________________ Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Do 26.04.2007 17:39 An: Developer discussions for provisioning Betreff: Re: [provisioning-dev] Improved update = generation/distributionalgorithm This is really interesting too. What kind of space reduction = measurements have you gotten? Regards, Dave ----- Original Message ----- From: Stefan Liebig To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Sent: Thursday, April 26, 2007 3:41:50 AM GMT-0800 Subject: Re: [provisioning-dev] Improved update generation/distribution = algorithm I think the approach taken by us = (http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#Smartup_s= oftware_update) is somehow similar. At least we have the same = requirements. Would be nice if we could join our efforts. For that I = will give you a brief outline of our mechanism/algorithm. First our alg. updates resources from V(n) to V(n+delta) with delta>0 in = a single step. Resources might be jars, zips, dlls, docs, ... Since our solution is not (yet) eclipse based we do not have plugin jars = like eclipse has. But this is not a general restriction for our = mechanism. =20 Our mechanism is based on delta encodings = (http://en.wikipedia.org/wiki/Delta_encoding). In our particular case we have decided to use the xdelta alg. = (http://en.wikipedia.org/wiki/Xdelta) which is pretty good usable for = many types of data. However, it performs very bad when =B4diffing=B4 = compressed data like zips and jars. Because of that we unpack zips (in memory) into somthing similar to a = tar and perfom the =B4binary diffing=B4 on the different version of = these =B4tars=B4. The resulting delta (or patch) is then zipped (it = really gets smaller!) and send of the wire. =B4Applying=B4 this delta on = the =B4old=B4 version creates the =B4new=B4 version of the =B4tared=B4 = resource. The resulting version is then converted back into a zip. For this mechanism to work properly it required that versions of = resources can be uniquely identified. For this identification we use a = combination of the resource name and the MD5 hash of the resource. The = resource name is similar to the artifactId in mavens project.xml, i.e. = the name of the resource without any version specific parts in it. =20 The simplified update flow is: - the client gets somehow the information that a resource should be = updated to a newer one - therefore it asks the update server for the delta between the old and = the new version - the update server generates the delta or has it already generated and = cached and sends it back - the client applies this delta to old version and gets the new version This happens for all required resources. =20 Our update server is an active server component realized as a servlet. = It manages all resources in their different versions. The server is = capable of generating deltas in advance and keeping them in a cache for = faster response times. If a requested delta is not available it = generates them on demand. In case that a delta is requested for a =B4very=B4 old version of a = resource which is no longer available on the server (has been removed by = an administrator) the server will respond with a zipped version of the = complete resource. Every delta/patch send to the client has a type that = tells the client how to handle the =B4delta=B4. The situation that the server does not have a base (old) version for = generating a delta may also be the result of the manipulation of a = resource on the client side. The identification for this manipulated = resource (resource name + md5 hash) will most likely not reference a = resource on the server. This case will also result in returning a = complete (zipped) resource. =20 As I already mentioned it seems that Dave and we have similar = requirements but we solve them differently. The challenge will be to = provide with the new provisioning a base where different mechanisms can = be plugged in. There might also be a generalized delta layer in which Daves and our = solution could be plugged in. =20 Comments, questions? Stefan ________________________________ Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Do 26.04.2007 00:22 An: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Betreff: [provisioning-dev] Improved update generation/distribution = algorithm The current feature-based update sites can get huge quickly when small = numbers of changes are scattered across a large number of features. = This kind of situation happens easily when releasing a dot-level or a = patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are = fixed. The purpose of this email is to open a dialog and to outline our = solution. Apologies in advance for those who are less comfortable with = expressing algorithms in formal math. Time constraints have dictated = communication using the most compact and efficient means possible. The algorithm we developed worked as follows: The build server maintains copies of all production versions of the = application. In the general case, then, we need an algorithm to upgrade = a given user from a version V(n) to a version V(n+delta) where delta is = the number of versions that have elapsed since the user last upgraded. = We want this algorithm to have the following properties: * Send a minimal number of bits across the wire=20 * Be as simple as possible=20 * Be verifiably correct. We couldn't afford to have 40k-70k of broken = clients if the algorithm malfunctioned.=20 * Related to the previous: Have safeguards built-in so that if a bad = update site is ever generated, the whole thing fails fast--before *any* = bits are ever sent to clients. You will notice some conflicts in the requirements above. In = particular, the requirement to send the fewest number of bits over the = wire conflicts with the requirements to be as simple as possible and to = be verifiably correct. The result was that our algorithm sacrifices = some efficiency in the number of bits it sends over the wire in order to = be simpler and more verifiably correct. The result: In our application, going from version 1.0.0 to version = 1.0.1 using update site features resulted in about a 10 meg download. = After applying our algorithm, the download size shrunk to about 3 megs. = This is still large for some of our users who utilize a dial-up = connection, but it is doable, whereas the 10 meg download would simply = be prohibitive. Here is the algorithm: First, we simplify the problem. Instead of upgrading users from an = arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to = V(n+1). Going to V(n+delta) is simply an iteration of the algorithm = over delta steps. This simplification works fine for our user = population. If it would be acceptable for the general Eclipse = population is an open question. Second, we notice that sending JAR'd plugins is very expensive. Suppose = only two classes in a large plugin change: the whole plugin must still = be shipped. Our algorithm then is simple. We dynamically generate a function F = where F(P(V(n))) =3D P(V(n+1)). F is really just a zipped collection of = files that encodes just the files that changed between the two plugin = versions. This is accomplished using the following algorithm. For a given plugin = P in two versions V(n) and V(n+1): 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories.=20 2. For files that correspond to each other in the two plugins, MD5 hash = them, and if the hashes are different, put the file from P(V(n+1)) into = F.=20 3. Include new files from P(V(n+1)) in F.=20 4. Create a text file manifest listing files in P(V(n)) that are no = longer included in P(V(n+1)) and include that text file in F.=20 5. Package all of the files in F in a zip file. =09 I believe that the algorithm for applying this function F to P(V(n)) to = get a P(V(n+1)) is self-evident. This approach has advantages over binary-diffing the two plugin jars = P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin = changes between versions, a naive binary diff algorithm will not achieve = nearly the same amount of "compression" that we achieve. So we have described a simple algorithm that is able to dramatically = reduce download bandwidth requirements over using update sites. = However, we have not described how we achieved the "fail-fast" = requirement. If a flawed update site is ever generated, we want to = detect this automatically at build time rather than after 50,000 clients = have already downloaded it and broken their installs. Here is the algorithm we use: After a build has completed, we have the following artifacts on our = build server: P(V(n)) - the old version P(V(n+1)) - the original new version generated by PDEBuild F - the function (basically an intelligent binary diff) we generated = that we can apply to P(V(n)) to get P(V(n+1)) The approach we take to validate F is the following: 1. Apply F to P(V(n)) on the build server using the same code that is = running on the clients.=20 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' (notice = the prime there). So formally, F(P(V(n))) =3D P(V(n+1))' =09 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the = version originally generated by PDEBuild.=20 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary = directories and perform an MD5 hash on all files, making sure that all = files present in one are also present in the other and that their hashes = are equal.=20 5. If applying F to P(V(n)) on the build server using the same code as = is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) = on the server, then it should work on the clients as well. =09 In our implementation, all update site building on the build server was = done in Ruby. The effort to implement the server side of this algorithm = in Ruby was about three days. The effort to implement the client-side = (fully unit-tested, pair-programmed, one pair programming team working = on it full-time) in Java was about a month. This was due to the hassle = of working with Java input and output streams. However, the result was = that the Java code worked entirely in memory, piping input streams into = output streams and so on until only the final results were written to = disk. Thus, the Java solution would be immune to breakage resulting = from something on the file system being changed in a way we did not = expect. Let me know if you have any questions. Regards, Dave Orme ------_=_NextPart_001_01C78C9B.7BDB32FE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Dave,
=0A=
 
=0A=
To be = more specific I took the sources of junit 3.8.1. Created an
Eclipse = project for it and let Eclipse create the jar(s) for me.
=0A=
 
=0A=
=B4Original=B4 size of the jar: 119.959 byte
=0A=
 
=0A=
Than = I made some modifications and generated the deltas
between the = jars:
=0A=
 
=0A=
- = fixed an unneccessary cast in junit.swingui.TestTreeModel
  Size = of changed TestTreeModel.class: 4959 byte
  Resulting delta to = original: 1534 byte
 
- added a simple bean with 4 = properties (setters/getters)
  Jar size: 120.604
  = Bean.class size: 1204
  Resulting delta to original: 1173 = byte
 
- changed the name of a interface method = from
  junit.framework.Test.run() to = junit.framework.Test.lauf()
  Jar size: 120.020 byte
  = this affects 7 classes
  Jar size: 120.020 byte
  = Resulting delta to original: 7889 byte
 
=0A=
We = transmit (download) each delta of a *changed* resource with a = single
HTTP/S request/response. The above deltas are the raw data. = You have to
add some bytes for the http protocol stuff and a few = bytes for some type
information, so that the client can distinguish = between different patch
types.
If the server has been requested = for a delta (patch), but the server is no
longer able to generate = the delta because the original version is no longer
available = (removed by an admin to save space,..) the server responses with
a = compressed version of the latest version. This type information tells = the
client how to handle the =B4patch=B4 (not neccessarily a = delta!).
=0A=

I hope that this = information is helpful.
=0A=
 
=0A=
Stefan
=0A=
 
=0A=

=0A=
=0A= Von: = fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. = Orme
Gesendet: Fr 27.04.2007 17:43
An: Developer = discussions for provisioning
Betreff: Re: AW: = [provisioning-dev] Improved = updategeneration/distributionalgorithm

=0A=
Thanks for the data.  What I was hoping you could do was give = specific data on the mailing list about a delta you ran: the size of the = application; version numbers, size of the download, and so on.  = It's probably more important to know the type of upgrade (a minor = version, a patch, etc) and the size of the code base than exact numbers, = although exact numbers are useful too.

We have one use-case; you = have another.  The more use-cases we can discuss on the list, the = better the solution we eventually evolve is likely to be.

BTW, in = the abstract, I *really* like your algorithm.  It sounds simpler = than ours and as you point out it can deal with upgrading JREs, not just = plugins/bundles.


Regards,

Dave Orme
----- Original = Message -----
From: Stefan Liebig = <NGZw83RUgQCo5vRX@aTpS9YBRvPQjNiNX>
To: = bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Sent: Friday, April 27, 2007 0:27:41 AM = GMT-0800
Subject: AW: [provisioning-dev] Improved update = generation/distributionalgorithm

=0A=
=0A=
Well, that = depends on the changes you make between the two versions of a = resource.
=0A=
As we are able to update = complete JREs, we have measured a patch data size of about 24 = MB
=0A=
when updating from from JRE = 1.5.0.10 (~70 MB) to JRE 1.6.0 (~87 MB).
=0A=
 
=0A=
I can =B4calculate=B4 the = patch size between two jars for you. You may send them to me = or
=0A=
you choose some =B4well = known=B4 jars which are publicly available.
=0A=
 
=0A=
Stefan
=0A=

=0A=
=0A= Von: = fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. = Orme
Gesendet: Do 26.04.2007 17:39
An: Developer = discussions for provisioning
Betreff: Re: [provisioning-dev] = Improved update generation/distributionalgorithm

=0A=
This is really interesting too.  What kind of space reduction = measurements have you gotten?


Regards,

Dave
----- = Original Message -----
From: Stefan Liebig = <NGZw83RUgQCo5vRX@aTpS9YBRvPQjNiNX>
To: = bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Sent: Thursday, April 26, 2007 3:41:50 = AM GMT-0800
Subject: Re: [provisioning-dev] Improved update = generation/distribution algorithm

=0A=
=0A=
I think the = approach taken by us (http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospec= tives#Smartup_software_update) is somehow similar. At least we have = the same requirements. Would be nice if we could join our efforts. For = that I will give you a brief outline of our = mechanism/algorithm.
=0A=
First our = alg. updates resources from V(n) to V(n+delta) with delta>0 in a = single step. Resources might be jars, zips, dlls, docs, ...
Since our = solution is not (yet) eclipse based we do not have plugin jars like = eclipse has. But this is not a general restriction for our = mechanism.
=0A=
 
=0A=
Our mechanism = is based on delta encodings (http://en.wikipedia.org/wiki/Delta_encoding).
In = our particular case we have decided to use the xdelta alg. (http://en.wikipedia.org/wiki/Xdelta) which is pretty = good usable for many types of data. However, it performs very bad when = =B4diffing=B4 compressed data like zips and jars.
Because of that we = unpack zips (in memory) into somthing similar to a tar and perfom the = =B4binary diffing=B4 on the different version of these =B4tars=B4. The = resulting delta (or patch) is then zipped (it really gets smaller!) and = send of the wire. =B4Applying=B4 this delta on the =B4old=B4 version = creates the =B4new=B4 version of the =B4tared=B4 resource. The resulting = version is then converted back into a zip.
For this mechanism to work = properly it required that versions of resources can be uniquely = identified. For this identification we use a combination of the resource = name and the MD5 hash of the resource. The resource name is similar to = the artifactId in mavens project.xml, i.e. the name of the resource = without any version specific parts in it.
=0A=
 
=0A=
The = simplified update flow is:
- the client gets somehow the information = that a resource should be updated to a newer one
- therefore it asks = the update server for the delta between the old and the new version
- = the update server generates the delta or has it already generated and = cached and sends it back
- the client applies this delta to old = version and gets the new version
=0A=
This happens = for all required resources.
=0A=
 
=0A=
Our update = server is an active server component realized as a servlet. It manages = all resources in their different versions. The server is capable of = generating deltas in advance and keeping them in a cache for faster = response times. If a requested delta is not available it generates them = on demand.
In case that a delta is requested for a =B4very=B4 old = version of a resource which is no longer available on the server (has = been removed by an administrator) the server will respond with a zipped = version of the complete resource. Every delta/patch send to the client = has a type that tells the client how to handle the =B4delta=B4.
The = situation that the server does not have a base (old) version for = generating a delta may also be the result of the manipulation of a = resource on the client side. The identification for this manipulated = resource (resource name + md5 hash) will most likely not reference a = resource on the server. This case will also result in returning a = complete (zipped) resource.
=0A=
 
=0A=
As I already = mentioned it seems that Dave and we have similar requirements but we = solve them differently. The challenge will be to provide with the new = provisioning a base where different mechanisms can be plugged = in.
There might also be a generalized delta layer in which Daves and = our solution could be plugged in.
=0A=
 
=0A=
Comments, = questions?
=0A=

Stefan
=0A=
=0A=
=0A=

=0A=
=0A= Von: = fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. = Orme
Gesendet: Do 26.04.2007 00:22
An: = bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Betreff: [provisioning-dev] = Improved update generation/distribution algorithm

=0A=
The current feature-based update sites can get huge quickly when = small numbers of changes are scattered across a large number of = features.  This kind of situation happens easily when releasing a = dot-level or a patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of = small bugs are fixed.

The purpose of this email is to open a = dialog and to outline our solution.  Apologies in advance for those = who are less comfortable with expressing algorithms in formal = math.  Time constraints have dictated communication using the most = compact and efficient means possible.

The algorithm we developed = worked as follows:

The build server maintains copies of all = production versions of the application.  In the general case, then, = we need an algorithm to upgrade a given user from a version V(n) to a = version V(n+delta) where delta is the number of versions that have = elapsed since the user last upgraded.  We want this algorithm to = have the following properties:
=0A=
    =0A=
  • Send a minimal number of bits across the wire =0A=
  • Be as simple as possible =0A=
  • Be verifiably correct.  We couldn't afford to have 40k-70k of = broken clients if the algorithm malfunctioned. =0A=
  • Related to the previous: Have safeguards built-in so that if a bad = update site is ever generated, the whole thing fails fast--before *any* = bits are ever sent to clients.
You will notice some conflicts = in the requirements above.  In particular, the requirement to send = the fewest number of bits over the wire conflicts with the requirements = to be as simple as possible and to be verifiably correct.  The = result was that our algorithm sacrifices some efficiency in the number = of bits it sends over the wire in order to be simpler and more = verifiably correct.

The result: In our application, going from = version 1.0.0 to version 1.0.1 using update site features resulted in = about a 10 meg download.  After applying our algorithm, the = download size shrunk to about 3 megs.  This is still large for some = of our users who utilize a dial-up connection, but it is doable, whereas = the 10 meg download would simply be prohibitive.

Here is the = algorithm:

First, we simplify the problem.  Instead of = upgrading users from an arbitrary version V(n) to V(n+delta), we only = upgrade them from V(n) to V(n+1).  Going to V(n+delta) is simply an = iteration of the algorithm over delta steps.  This simplification = works fine for our user population.  If it would be acceptable for = the general Eclipse population is an open question.

Second, we = notice that sending JAR'd plugins is very expensive.  Suppose only = two classes in a large plugin change: the whole plugin must still be = shipped.

Our algorithm then is simple.  We dynamically = generate a function F where F(P(V(n))) =3D P(V(n+1)).  F is really = just a zipped collection of files that encodes just the files that = changed between the two plugin versions.

This is accomplished = using the following algorithm.  For a given plugin P in two = versions V(n) and V(n+1):
=0A=
    =0A=
  1. Unpack P(V(n)) and P(V(n+1)) into temporary directories. =0A=
  2. For files that correspond to each other in the two plugins, MD5 hash = them, and if the hashes are different, put the file from P(V(n+1)) into = F. =0A=
  3. Include new files from P(V(n+1)) in F. =0A=
  4. Create a text file manifest listing files in P(V(n)) that are no = longer included in P(V(n+1)) and include that text file in F. =0A=
  5. Package all of the files in F in a zip file.
I believe = that the algorithm for applying this function F to P(V(n)) to get a = P(V(n+1)) is self-evident.

This approach has advantages over = binary-diffing the two plugin jars P(V(n)) and P(V(n+1)): If the order = of the files contained in the plugin changes between versions, a naive = binary diff algorithm will not achieve nearly the same amount of = "compression" that we achieve.

So we have described a simple = algorithm that is able to dramatically reduce download bandwidth = requirements over using update sites.  However, we have not = described how we achieved the "fail-fast" requirement.  If a flawed = update site is ever generated, we want to detect this automatically at = build time rather than after 50,000 clients have already downloaded it = and broken their installs.

Here is the algorithm we = use:

After a build has completed, we have the following artifacts = on our build server:

P(V(n)) - the old version
P(V(n+1)) - the = original new version generated by PDEBuild
F - the function = (basically an intelligent binary diff) we generated that we can apply to = P(V(n)) to get P(V(n+1))

The approach we take to validate F is = the following:
=0A=
    =0A=
  1. Apply F to P(V(n)) on the build server using the same code that is = running on the clients. =0A=
  2. Let's call the result of applying F to P(V(n)), P(V(n+1))'  = (notice the prime there).  So formally, F(P(V(n))) =3D = P(V(n+1))'
    =0A=
  3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the = version originally generated by PDEBuild. =0A=
  4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into temporary = directories and perform an MD5 hash on all files, making sure that all = files present in one are also present in the other and that their hashes = are equal. =0A=
  5. If applying F to P(V(n)) on the build server using the same code as = is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) = on the server, then it should work on the clients as = well.
In our implementation, all update site building on = the build server was done in Ruby.  The effort to implement the = server side of this algorithm in Ruby was about three days.  The = effort to implement the client-side (fully unit-tested, pair-programmed, = one pair programming team working on it full-time) in Java was about a = month.  This was due to the hassle of working with Java input and = output streams.  However, the result was that the Java code worked = entirely in memory, piping input streams into output streams and so on = until only the final results were written to disk.  Thus, the Java = solution would be immune to breakage resulting from something on the = file system being changed in a way we did not expect.

Let me know = if you have any questions.


Regards,

Dave = Orme

------_=_NextPart_001_01C78C9B.7BDB32FE-- From Pascal_nZARQQd5G+POZmzf@YHvLZjvCTR1Igv9U Wed May 2 14:53:02 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by mail.eclipse.org (Postfix) with SMTP id 310E22DB80; Wed, 2 May 2007 14:53:01 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l42IpV5u022572; Wed, 2 May 2007 14:51:31 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l42IpVLg549680; Wed, 2 May 2007 14:51:31 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l42IpV6H029353; Wed, 2 May 2007 14:51:31 -0400 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l42IpVFC029331; Wed, 2 May 2007 14:51:31 -0400 In-Reply-To: References: Subject: Re: AW: AW: [provisioning-dev] Improved updategeneration/distributionalgorithm To: "Developer discussions for provisioning \(Update Manager\) initiatives" Cc: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg, fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg X-Mailer: Lotus Notes Build V80_M4_03042007NP March 04, 2007 Message-ID: From: Pascal Rapicault Date: Wed, 2 May 2007 14:51:28 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 05/02/2007 14:51:30 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 18:53:04 -0000 Stefan, Does your delta mechanism only works with http/https or is it transport= agnostic? Thx PaScaL = "Liebig, Stefan " = = To Sent by: = provisioning-dev- = cc B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM = rg Subj= ect AW: AW: [provisioning-dev] Impro= ved updategeneration/distributionalg= ori 05/02/2007 05:23 thm = AM = = = Please respond to = "Developer = discussions for = provisioning = \(Update = Manager\) = initiatives" = = = = Dave, To be more specific I took the sources of junit 3.8.1. Created an Eclipse project for it and let Eclipse create the jar(s) for me. =B4Original=B4 size of the jar: 119.959 byte Than I made some modifications and generated the deltas between the jars: - fixed an unneccessary cast in junit.swingui.TestTreeModel Size of changed TestTreeModel.class: 4959 byte Resulting delta to original: 1534 byte - added a simple bean with 4 properties (setters/getters) Jar size: 120.604 Bean.class size: 1204 Resulting delta to original: 1173 byte - changed the name of a interface method from junit.framework.Test.run() to junit.framework.Test.lauf() Jar size: 120.020 byte this affects 7 classes Jar size: 120.020 byte Resulting delta to original: 7889 byte We transmit (download) each delta of a *changed* resource with a single= HTTP/S request/response. The above deltas are the raw data. You have to= add some bytes for the http protocol stuff and a few bytes for some typ= e information, so that the client can distinguish between different patch= types. If the server has been requested for a delta (patch), but the server is= no longer able to generate the delta because the original version is no lo= nger available (removed by an admin to save space,..) the server responses w= ith a compressed version of the latest version. This type information tells= the client how to handle the =B4patch=B4 (not neccessarily a delta!). I hope that this information is helpful. Stefan Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Fr 27.04.2007 17:43 An: Developer discussions for provisioning Betreff: Re: AW: [provisioning-dev] Improved updategeneration/distributionalgorithm Thanks for the data. What I was hoping you could do was give specific = data on the mailing list about a delta you ran: the size of the application;= version numbers, size of the download, and so on. It's probably more important to know the type of upgrade (a minor version, a patch, etc) a= nd the size of the code base than exact numbers, although exact numbers ar= e useful too. We have one use-case; you have another. The more use-cases we can disc= uss on the list, the better the solution we eventually evolve is likely to = be. BTW, in the abstract, I *really* like your algorithm. It sounds simple= r than ours and as you point out it can deal with upgrading JREs, not jus= t plugins/bundles. Regards, Dave Orme ----- Original Message ----- From: Stefan Liebig To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Sent: Friday, April 27, 2007 0:27:41 AM GMT-0800 Subject: AW: [provisioning-dev] Improved update generation/distributionalgorithm Well, that depends on the changes you make between the two versions of = a resource. As we are able to update complete JREs, we have measured a patch data s= ize of about 24 MB when updating from from JRE 1.5.0.10 (~70 MB) to JRE 1.6.0 (~87 MB). I can =B4calculate=B4 the patch size between two jars for you. You may = send them to me or you choose some =B4well known=B4 jars which are publicly available. Stefan Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Do 26.04.2007 17:39 An: Developer discussions for provisioning Betreff: Re: [provisioning-dev] Improved update generation/distributionalgorithm This is really interesting too. What kind of space reduction measureme= nts have you gotten? Regards, Dave ----- Original Message ----- From: Stefan Liebig To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Sent: Thursday, April 26, 2007 3:41:50 AM GMT-0800 Subject: Re: [provisioning-dev] Improved update generation/distribution= algorithm I think the approach taken by us ( http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#Smartup_= software_update ) is somehow similar. At least we have the same requirements. Would be = nice if we could join our efforts. For that I will give you a brief outline = of our mechanism/algorithm. First our alg. updates resources from V(n) to V(n+delta) with delta>0 i= n a single step. Resources might be jars, zips, dlls, docs, ... Since our solution is not (yet) eclipse based we do not have plugin jar= s like eclipse has. But this is not a general restriction for our mechani= sm. Our mechanism is based on delta encodings ( http://en.wikipedia.org/wiki/Delta_encoding). In our particular case we have decided to use the xdelta alg. ( http://en.wikipedia.org/wiki/Xdelta) which is pretty good usable for ma= ny types of data. However, it performs very bad when =B4diffing=B4 compres= sed data like zips and jars. Because of that we unpack zips (in memory) into somthing similar to a t= ar and perfom the =B4binary diffing=B4 on the different version of these =B4= tars=B4. The resulting delta (or patch) is then zipped (it really gets smaller!)= and send of the wire. =B4Applying=B4 this delta on the =B4old=B4 version cr= eates the =B4new=B4 version of the =B4tared=B4 resource. The resulting version is= then converted back into a zip. For this mechanism to work properly it required that versions of resour= ces can be uniquely identified. For this identification we use a combinatio= n of the resource name and the MD5 hash of the resource. The resource name i= s similar to the artifactId in mavens project.xml, i.e. the name of the resource without any version specific parts in it. The simplified update flow is: - the client gets somehow the information that a resource should be upd= ated to a newer one - therefore it asks the update server for the delta between the old and= the new version - the update server generates the delta or has it already generated and= cached and sends it back - the client applies this delta to old version and gets the new version= This happens for all required resources. Our update server is an active server component realized as a servlet. = It manages all resources in their different versions. The server is capabl= e of generating deltas in advance and keeping them in a cache for faster response times. If a requested delta is not available it generates them= on demand. In case that a delta is requested for a =B4very=B4 old version of a res= ource which is no longer available on the server (has been removed by an administrator) the server will respond with a zipped version of the complete resource. Every delta/patch send to the client has a type that= tells the client how to handle the =B4delta=B4. The situation that the server does not have a base (old) version for generating a delta may also be the result of the manipulation of a reso= urce on the client side. The identification for this manipulated resource (resource name + md5 hash) will most likely not reference a resource on= the server. This case will also result in returning a complete (zipped) resource. As I already mentioned it seems that Dave and we have similar requireme= nts but we solve them differently. The challenge will be to provide with th= e new provisioning a base where different mechanisms can be plugged in. There might also be a generalized delta layer in which Daves and our solution could be plugged in. Comments, questions? Stefan Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Do 26.04.2007 00:22 An: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Betreff: [provisioning-dev] Improved update generation/distribution algorithm The current feature-based update sites can get huge quickly when small numbers of changes are scattered across a large number of features. Th= is kind of situation happens easily when releasing a dot-level or a patchl= evel upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed. The purpose of this email is to open a dialog and to outline our soluti= on. Apologies in advance for those who are less comfortable with expressing= algorithms in formal math. Time constraints have dictated communicatio= n using the most compact and efficient means possible. The algorithm we developed worked as follows: The build server maintains copies of all production versions of the application. In the general case, then, we need an algorithm to upgrad= e a given user from a version V(n) to a version V(n+delta) where delta is t= he number of versions that have elapsed since the user last upgraded. We = want this algorithm to have the following properties: Send a minimal number of bits across the wire Be as simple as possible Be verifiably correct. We couldn't afford to have 40k-70k of bro= ken clients if the algorithm malfunctioned. Related to the previous: Have safeguards built-in so that if a ba= d update site is ever generated, the whole thing fails fast--before= *any* bits are ever sent to clients. You will notice some conflicts in the requirements above. In particula= r, the requirement to send the fewest number of bits over the wire conflic= ts with the requirements to be as simple as possible and to be verifiably correct. The result was that our algorithm sacrifices some efficiency = in the number of bits it sends over the wire in order to be simpler and mo= re verifiably correct. The result: In our application, going from version 1.0.0 to version 1.0= .1 using update site features resulted in about a 10 meg download. After applying our algorithm, the download size shrunk to about 3 megs. This= is still large for some of our users who utilize a dial-up connection, but= it is doable, whereas the 10 meg download would simply be prohibitive. Here is the algorithm: First, we simplify the problem. Instead of upgrading users from an arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to= V(n+1). Going to V(n+delta) is simply an iteration of the algorithm ov= er delta steps. This simplification works fine for our user population. = If it would be acceptable for the general Eclipse population is an open question. Second, we notice that sending JAR'd plugins is very expensive. Suppos= e only two classes in a large plugin change: the whole plugin must still = be shipped. Our algorithm then is simple. We dynamically generate a function F whe= re F(P(V(n))) =3D P(V(n+1)). F is really just a zipped collection of file= s that encodes just the files that changed between the two plugin versions. This is accomplished using the following algorithm. For a given plugin= P in two versions V(n) and V(n+1): 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories. 2. For files that correspond to each other in the two plugins, MD5 h= ash them, and if the hashes are different, put the file from P(V(n+1)= ) into F. 3. Include new files from P(V(n+1)) in F. 4. Create a text file manifest listing files in P(V(n)) that are no longer included in P(V(n+1)) and include that text file in F. 5. Package all of the files in F in a zip file. I believe that the algorithm for applying this function F to P(V(n)) to= get a P(V(n+1)) is self-evident. This approach has advantages over binary-diffing the two plugin jars P(V(n)) and P(V(n+1)): If the order of the files contained in the plugi= n changes between versions, a naive binary diff algorithm will not achiev= e nearly the same amount of "compression" that we achieve. So we have described a simple algorithm that is able to dramatically re= duce download bandwidth requirements over using update sites. However, we h= ave not described how we achieved the "fail-fast" requirement. If a flawed= update site is ever generated, we want to detect this automatically at build time rather than after 50,000 clients have already downloaded it = and broken their installs. Here is the algorithm we use: After a build has completed, we have the following artifacts on our bui= ld server: P(V(n)) - the old version P(V(n+1)) - the original new version generated by PDEBuild F - the function (basically an intelligent binary diff) we generated th= at we can apply to P(V(n)) to get P(V(n+1)) The approach we take to validate F is the following: 1. Apply F to P(V(n)) on the build server using the same code that i= s running on the clients. 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' (noti= ce the prime there). So formally, F(P(V(n))) =3D P(V(n+1))' 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the version originally generated by PDEBuild. 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into tempor= ary directories and perform an MD5 hash on all files, making sure tha= t all files present in one are also present in the other and that t= heir hashes are equal. 5. If applying F to P(V(n)) on the build server using the same code = as is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on the server, then it should work on the clients as we= ll. In our implementation, all update site building on the build server was= done in Ruby. The effort to implement the server side of this algorith= m in Ruby was about three days. The effort to implement the client-side (fu= lly unit-tested, pair-programmed, one pair programming team working on it full-time) in Java was about a month. This was due to the hassle of working with Java input and output streams. However, the result was th= at the Java code worked entirely in memory, piping input streams into outp= ut streams and so on until only the final results were written to disk. T= hus, the Java solution would be immune to breakage resulting from something = on the file system being changed in a way we did not expect. Let me know if you have any questions. Regards, Dave Orme _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev = From NGZw83RUgQCo5vRX@aTpS9YBRvPQjNiNX Thu May 3 00:59:52 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mis010.exch010.intermedia.net (mis010.exch010.intermedia.net [64.78.61.97]) by mail.eclipse.org (Postfix) with SMTP id 02A8324347 for ; Thu, 3 May 2007 00:59:51 -0400 (EDT) Received: from ehost010-3.exch010.intermedia.net ([64.78.61.55]) by mis010.exch010.intermedia.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 21:54:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C78D3F.172B7A33" Subject: AW: AW: AW: [provisioning-dev]Improved updategeneration/distributionalgorithm Date: Wed, 2 May 2007 21:49:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [provisioning-dev]Improved updategeneration/distributionalgorithm Thread-Index: AceM6m/2K9QqJlUgQxerMv9AwWBebgAU/roz References: From: "Liebig, Stefan " To: "Developer discussions for provisioning \(Update Manager\) initiatives" X-OriginalArrivalTime: 03 May 2007 04:54:12.0381 (UTC) FILETIME=[17B914D0:01C78D3F] X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2007 04:59:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C78D3F.172B7A33 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pascal, =20 The delta mechanism is independent of the transport layer. But we = currently only use HTTP/S. =20 Stefan ________________________________ Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von Pascal = Rapicault Gesendet: Mi 02.05.2007 20:51 An: Developer discussions for provisioning (Update Manager) initiatives Cc: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg; fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg Betreff: Re: AW: AW: [provisioning-dev]Improved = updategeneration/distributionalgorithm Stefan, Does your delta mechanism only works with http/https or is it transport agnostic? Thx PaScaL = =20 "Liebig, Stefan " = =20 = To Sent by: = =20 provisioning-dev- = cc B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM = =20 rg = Subject AW: AW: [provisioning-dev] = Improved = updategeneration/distributionalgori 05/02/2007 05:23 thm = =20 AM = =20 = =20 = =20 Please respond to = =20 "Developer = =20 discussions for = =20 provisioning = =20 \(Update = =20 Manager\) = =20 initiatives" = =20 = =20 = =20 = =20 Dave, To be more specific I took the sources of junit 3.8.1. Created an Eclipse project for it and let Eclipse create the jar(s) for me. =B4Original=B4 size of the jar: 119.959 byte Than I made some modifications and generated the deltas between the jars: - fixed an unneccessary cast in junit.swingui.TestTreeModel Size of changed TestTreeModel.class: 4959 byte Resulting delta to original: 1534 byte - added a simple bean with 4 properties (setters/getters) Jar size: 120.604 Bean.class size: 1204 Resulting delta to original: 1173 byte - changed the name of a interface method from junit.framework.Test.run() to junit.framework.Test.lauf() Jar size: 120.020 byte this affects 7 classes Jar size: 120.020 byte Resulting delta to original: 7889 byte We transmit (download) each delta of a *changed* resource with a single HTTP/S request/response. The above deltas are the raw data. You have to add some bytes for the http protocol stuff and a few bytes for some type information, so that the client can distinguish between different patch types. If the server has been requested for a delta (patch), but the server is = no longer able to generate the delta because the original version is no = longer available (removed by an admin to save space,..) the server responses = with a compressed version of the latest version. This type information tells = the client how to handle the =B4patch=B4 (not neccessarily a delta!). I hope that this information is helpful. Stefan Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Fr 27.04.2007 17:43 An: Developer discussions for provisioning Betreff: Re: AW: [provisioning-dev] Improved updategeneration/distributionalgorithm Thanks for the data. What I was hoping you could do was give specific = data on the mailing list about a delta you ran: the size of the application; version numbers, size of the download, and so on. It's probably more important to know the type of upgrade (a minor version, a patch, etc) = and the size of the code base than exact numbers, although exact numbers are useful too. We have one use-case; you have another. The more use-cases we can = discuss on the list, the better the solution we eventually evolve is likely to = be. BTW, in the abstract, I *really* like your algorithm. It sounds simpler than ours and as you point out it can deal with upgrading JREs, not just plugins/bundles. Regards, Dave Orme ----- Original Message ----- From: Stefan Liebig To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Sent: Friday, April 27, 2007 0:27:41 AM GMT-0800 Subject: AW: [provisioning-dev] Improved update generation/distributionalgorithm Well, that depends on the changes you make between the two versions of a resource. As we are able to update complete JREs, we have measured a patch data = size of about 24 MB when updating from from JRE 1.5.0.10 (~70 MB) to JRE 1.6.0 (~87 MB). I can =B4calculate=B4 the patch size between two jars for you. You may = send them to me or you choose some =B4well known=B4 jars which are publicly available. Stefan Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Do 26.04.2007 17:39 An: Developer discussions for provisioning Betreff: Re: [provisioning-dev] Improved update generation/distributionalgorithm This is really interesting too. What kind of space reduction = measurements have you gotten? Regards, Dave ----- Original Message ----- From: Stefan Liebig To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Sent: Thursday, April 26, 2007 3:41:50 AM GMT-0800 Subject: Re: [provisioning-dev] Improved update generation/distribution algorithm I think the approach taken by us ( http://wiki.eclipse.org/index.php/GPW_Lightning_Retrospectives#Smartup_so= ftware_update ) is somehow similar. At least we have the same requirements. Would be = nice if we could join our efforts. For that I will give you a brief outline = of our mechanism/algorithm. First our alg. updates resources from V(n) to V(n+delta) with delta>0 in = a single step. Resources might be jars, zips, dlls, docs, ... Since our solution is not (yet) eclipse based we do not have plugin jars like eclipse has. But this is not a general restriction for our = mechanism. Our mechanism is based on delta encodings ( http://en.wikipedia.org/wiki/Delta_encoding). In our particular case we have decided to use the xdelta alg. ( http://en.wikipedia.org/wiki/Xdelta) which is pretty good usable for = many types of data. However, it performs very bad when =B4diffing=B4 = compressed data like zips and jars. Because of that we unpack zips (in memory) into somthing similar to a = tar and perfom the =B4binary diffing=B4 on the different version of these = =B4tars=B4. The resulting delta (or patch) is then zipped (it really gets smaller!) = and send of the wire. =B4Applying=B4 this delta on the =B4old=B4 version = creates the =B4new=B4 version of the =B4tared=B4 resource. The resulting version is = then converted back into a zip. For this mechanism to work properly it required that versions of = resources can be uniquely identified. For this identification we use a combination = of the resource name and the MD5 hash of the resource. The resource name is similar to the artifactId in mavens project.xml, i.e. the name of the resource without any version specific parts in it. The simplified update flow is: - the client gets somehow the information that a resource should be = updated to a newer one - therefore it asks the update server for the delta between the old and = the new version - the update server generates the delta or has it already generated and cached and sends it back - the client applies this delta to old version and gets the new version This happens for all required resources. Our update server is an active server component realized as a servlet. = It manages all resources in their different versions. The server is capable = of generating deltas in advance and keeping them in a cache for faster response times. If a requested delta is not available it generates them = on demand. In case that a delta is requested for a =B4very=B4 old version of a = resource which is no longer available on the server (has been removed by an administrator) the server will respond with a zipped version of the complete resource. Every delta/patch send to the client has a type that tells the client how to handle the =B4delta=B4. The situation that the server does not have a base (old) version for generating a delta may also be the result of the manipulation of a = resource on the client side. The identification for this manipulated resource (resource name + md5 hash) will most likely not reference a resource on = the server. This case will also result in returning a complete (zipped) resource. As I already mentioned it seems that Dave and we have similar = requirements but we solve them differently. The challenge will be to provide with the new provisioning a base where different mechanisms can be plugged in. There might also be a generalized delta layer in which Daves and our solution could be plugged in. Comments, questions? Stefan Von: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg im Auftrag von David J. Orme Gesendet: Do 26.04.2007 00:22 An: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Betreff: [provisioning-dev] Improved update generation/distribution algorithm The current feature-based update sites can get huge quickly when small numbers of changes are scattered across a large number of features. = This kind of situation happens easily when releasing a dot-level or a = patchlevel upgrade--ie: 1.0.0 to 1.0.1--where lots of small bugs are fixed. The purpose of this email is to open a dialog and to outline our = solution. Apologies in advance for those who are less comfortable with expressing algorithms in formal math. Time constraints have dictated communication using the most compact and efficient means possible. The algorithm we developed worked as follows: The build server maintains copies of all production versions of the application. In the general case, then, we need an algorithm to upgrade = a given user from a version V(n) to a version V(n+delta) where delta is = the number of versions that have elapsed since the user last upgraded. We = want this algorithm to have the following properties: Send a minimal number of bits across the wire Be as simple as possible Be verifiably correct. We couldn't afford to have 40k-70k of = broken clients if the algorithm malfunctioned. Related to the previous: Have safeguards built-in so that if a bad update site is ever generated, the whole thing fails fast--before *any* bits are ever sent to clients. You will notice some conflicts in the requirements above. In = particular, the requirement to send the fewest number of bits over the wire = conflicts with the requirements to be as simple as possible and to be verifiably correct. The result was that our algorithm sacrifices some efficiency = in the number of bits it sends over the wire in order to be simpler and = more verifiably correct. The result: In our application, going from version 1.0.0 to version = 1.0.1 using update site features resulted in about a 10 meg download. After applying our algorithm, the download size shrunk to about 3 megs. This = is still large for some of our users who utilize a dial-up connection, but = it is doable, whereas the 10 meg download would simply be prohibitive. Here is the algorithm: First, we simplify the problem. Instead of upgrading users from an arbitrary version V(n) to V(n+delta), we only upgrade them from V(n) to V(n+1). Going to V(n+delta) is simply an iteration of the algorithm = over delta steps. This simplification works fine for our user population. = If it would be acceptable for the general Eclipse population is an open question. Second, we notice that sending JAR'd plugins is very expensive. Suppose only two classes in a large plugin change: the whole plugin must still = be shipped. Our algorithm then is simple. We dynamically generate a function F = where F(P(V(n))) =3D P(V(n+1)). F is really just a zipped collection of files = that encodes just the files that changed between the two plugin versions. This is accomplished using the following algorithm. For a given plugin = P in two versions V(n) and V(n+1): 1. Unpack P(V(n)) and P(V(n+1)) into temporary directories. 2. For files that correspond to each other in the two plugins, MD5 = hash them, and if the hashes are different, put the file from P(V(n+1)) into F. 3. Include new files from P(V(n+1)) in F. 4. Create a text file manifest listing files in P(V(n)) that are no longer included in P(V(n+1)) and include that text file in F. 5. Package all of the files in F in a zip file. I believe that the algorithm for applying this function F to P(V(n)) to = get a P(V(n+1)) is self-evident. This approach has advantages over binary-diffing the two plugin jars P(V(n)) and P(V(n+1)): If the order of the files contained in the plugin changes between versions, a naive binary diff algorithm will not achieve nearly the same amount of "compression" that we achieve. So we have described a simple algorithm that is able to dramatically = reduce download bandwidth requirements over using update sites. However, we = have not described how we achieved the "fail-fast" requirement. If a flawed update site is ever generated, we want to detect this automatically at build time rather than after 50,000 clients have already downloaded it = and broken their installs. Here is the algorithm we use: After a build has completed, we have the following artifacts on our = build server: P(V(n)) - the old version P(V(n+1)) - the original new version generated by PDEBuild F - the function (basically an intelligent binary diff) we generated = that we can apply to P(V(n)) to get P(V(n+1)) The approach we take to validate F is the following: 1. Apply F to P(V(n)) on the build server using the same code that is running on the clients. 2. Let's call the result of applying F to P(V(n)), P(V(n+1))' = (notice the prime there). So formally, F(P(V(n))) =3D P(V(n+1))' 3. We need to prove that P(V(n+1))' is the same as P(V(n+1)), the version originally generated by PDEBuild. 4. To do this, we simply unpack P(V(n+1))' and P(V(n+1)) into = temporary directories and perform an MD5 hash on all files, making sure that all files present in one are also present in the other and that = their hashes are equal. 5. If applying F to P(V(n)) on the build server using the same code = as is running on the clients produces a P(V(n+1))' identical to P(V(n+1)) on the server, then it should work on the clients as = well. In our implementation, all update site building on the build server was done in Ruby. The effort to implement the server side of this algorithm = in Ruby was about three days. The effort to implement the client-side = (fully unit-tested, pair-programmed, one pair programming team working on it full-time) in Java was about a month. This was due to the hassle of working with Java input and output streams. However, the result was = that the Java code worked entirely in memory, piping input streams into = output streams and so on until only the final results were written to disk. = Thus, the Java solution would be immune to breakage resulting from something = on the file system being changed in a way we did not expect. Let me know if you have any questions. Regards, Dave Orme _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev ------_=_NextPart_001_01C78D3F.172B7A33 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ig0EAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEATgAAAEFXOiBBVzogQVc6IFtwcm92 aXNpb25pbmctZGV2XUltcHJvdmVkCXVwZGF0ZWdlbmVyYXRpb24vZGlzdHJpYnV0aW9uYWxnb3Jp dGhtADUdAQWAAwAOAAAA1wcFAAIAFQAxABYAAwBEAQEggAMADgAAANcHBQACABUANgALAAMAPgEB CYABACEAAAAwNUYwRDk2ODE4RkFDRTRDQTQ1MjM2MzFENTA4N0ExRQAtBwEDkAYAUF0AADkAAAAD ADYAAAAAAEAAOQCPUuBqPo3HAR4APQABAAAABQAAAEFXOiAAAAAAAgFHAAEAAAA2AAAAYz11czth PSA7cD1vZXhjaDAxMDtsPUVIT1NUMDEwLTMtMDcwNTAzMDQ1NDExWi0yMTgxODMAAAAeAEkAAQAA AE4AAABSZTogQVc6IEFXOiBbcHJvdmlzaW9uaW5nLWRldl1JbXByb3ZlZAl1cGRhdGVnZW5lcmF0 aW9uL2Rpc3RyaWJ1dGlvbmFsZ29yaXRobQAAAEAATgAAeBLk6ozHAR4AWgABAAAAJQAAAHByb3Zp c2lvbmluZy1kZXYtYm91bmNlc0BlY2xpcHNlLm9yZwAAAAACAVsAAQAAAGcAAAAAAAAAgSsfpL6j EBmdbgDdAQ9UAgAAAABwcm92aXNpb25pbmctZGV2LWJvdW5jZXNAZWNsaXBzZS5vcmcAU01UUABw cm92aXNpb25pbmctZGV2LWJvdW5jZXNAZWNsaXBzZS5vcmcAAAIBXAABAAAAKgAAAFNNVFA6UFJP VklTSU9OSU5HLURFVi1CT1VOQ0VTQEVDTElQU0UuT1JHAAAAHgBdAAEAAAARAAAAUGFzY2FsIFJh cGljYXVsdAAAAAACAV4AAQAAAEoAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABQYXNjYWwgUmFw aWNhdWx0AFNNVFAAUGFzY2FsX1JhcGljYXVsdEBjYS5pYm0uY29tAAAAAgFfAAEAAAAhAAAAU01U UDpQQVNDQUxfUkFQSUNBVUxUQENBLklCTS5DT00AAAAAHgBmAAEAAAAFAAAAU01UUAAAAAAeAGcA AQAAACUAAABwcm92aXNpb25pbmctZGV2LWJvdW5jZXNAZWNsaXBzZS5vcmcAAAAAHgBoAAEAAAAF AAAAU01UUAAAAAAeAGkAAQAAABwAAABQYXNjYWxfUmFwaWNhdWx0QGNhLmlibS5jb20AHgBwAAEA AABKAAAAQVc6IEFXOiBbcHJvdmlzaW9uaW5nLWRldl1JbXByb3ZlZAl1cGRhdGVnZW5lcmF0aW9u L2Rpc3RyaWJ1dGlvbmFsZ29yaXRobQAAAAIBcQABAAAAGwAAAAHHjOpv9ivUKiZVIEMXqzL/QMFg Xm4AFP66MwAeAHMAAQAAAEMAAABwcm92aXNpb25pbmctZGV2QGVjbGlwc2Uub3JnOyBwcm92aXNp b25pbmctZGV2LWJvdW5jZXNAZWNsaXBzZS5vcmcAAB4AdAABAAAARAAAAERldmVsb3BlciBkaXNj dXNzaW9ucyBmb3IgcHJvdmlzaW9uaW5nIChVcGRhdGUgTWFuYWdlcikgaW5pdGlhdGl2ZXMAHgAa DAEAAAAQAAAATGllYmlnLCBTdGVmYW4gAB4AHQ4BAAAASgAAAEFXOiBBVzogW3Byb3Zpc2lvbmlu Zy1kZXZdSW1wcm92ZWQJdXBkYXRlZ2VuZXJhdGlvbi9kaXN0cmlidXRpb25hbGdvcml0aG0AAAAC AQkQAQAAAKNTAACfUwAArbcBAExaRnXj01KDAwAKAHJjcGcxMjWCMgNDaHRtbDEDMD8BAwH3CoAC pAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDXMgYABsMR1TMERhDZWRLvZjQD xhGKNQPGVHxhaANxAoAR4wjvCfc7ext/DjA1HJ8ccRHhDGBjZwBQCwkBZDM2EWALpTRyIBACKlwO sgGQDhA5ACA8SFRNTCBkiGlyPSIQcj59IdPnACEDMCMhZG8A4CMhCrH8XHEbYCMhEPADMCOFEWCN IYszIWAigEVBRCNQCSGMNzcicFRJVEyORSd9IVAO8FJlOhFwUlcqVFtwA2B2BABpEwIgC4BnLQEA dl1JBm0rAgmAIHVwZGF4dGVnCfAEkCzQK2EvxSLgcyMwaWJ1LWIHQEJnBbBpdGhtJ404ujUicC8o vyIiCuMgMK8LMb8OEDYO8DxNRVQcQSAFoAIwCfB0PSIDBeAikzYuMDAuMoo4NeExDkA4IiAuYAEH gD1HRU5FUkH4VE9SJ30qATAgJz8p0Qsy7yIhNRFgPEJPRI5ZJ30g0TpPZzk2InCARElWIGlkPT6g GE9XQSowC1B5VGXgeHQ2Mzg2ECLfI+D/AAAkhSUjJOElfzxvPX8+gM9AH0EvQjohqTY0RhpCbwUi BDQ/8DxGT05UfCBmANA28AcTNLEbET1WIzXgTSIgAJB6NvAy90YLGDADMGMT8AOyAdBCSaxQYQTw B0AsIYw1PjH+L0uyI1kjZ0hbAcAjZwqi11LYCoAhjDAnAS8+YVIv/0pPQ79Ez0XfRu9TD0kPWC// Sy9MNk2fTqRPXVC/Uc9X/wUh5TghYCZuYnNw8wKAI3gnYQFAXZ9UD1Uf/1YvVz9nP1lfWm9bf1yP ae8/Xq9vD2DPYd9i7097VGjqZXIgZSIRIAeAEPEDALxzbT6QBCALgAEAcAnw8wEAAjAgbyPgLtB7 0CMwVQBxcBshIAtgeQSQLqQgQi4gIHd70GMIcK8eAAIwP1B90G6AQXURMIIgIpBUUC9TLmTP/2Xf Ut9q32vvbP9uD3a/cC//cT9yT3NfdG91f3aPd594r/95v2PfgZ+Cr5T/aB9pL4QP/4Ufhi+HP5c/ iV+Kb4t/jI//jZ+Or4+/oB+R35Lvk/+ndvZTLOBMAG6Vj5afg5+bn/+cr52/ns+nf7Kfs6+gT6Ff 76Jvo3+kj7dPMQ4gO4E3kT8jeAqxCoG8f7gPuRtIUgt+AAGgSX0xeD0tMUuqfABQcQDgcWoMYGzE ZGIDMH4gX8USxNH7JAALgGWxA78/wE6l36bv/6f/qQkaJKoPTpIwAJSPmG2vO5C6m8TBzmdWAiA6 wUytvfEv0Aqu+SArDi0G4GR1bkwgc0AFkMWgcDURMC4FsGc+kHzQQXV3AYAtQNawdgIgUDUH8GHq cA3gYcSQdL0NPjG+LN/FosY/z0/QX9uCRweQfXIOdNHf0u/T901pIDB6MjXQNTYANeAogAHQOvw1 MdjP2d/a79v/3Q/ldG5B0c/f/9PoRCvgfABv/31gBcAtsX/QBBArYQQgAhDjBcArCiAoVSyzBdAA cPsiMASQKX0RLsAHMC1gLGB+c+Lf4+/k/+YP5x/yJEO+Y+iv6b/T/yuG1go79///1Y/Wke+P8J/x r/K/88/+xP5CEUAeAA9A9V/2b/d3Kj//K08sXy1vLnf8L/0//k+tD/+uHwxPCl8Lb69fsG+xf7VP /w5vxt/A7z4HupsXLxg/yGn9InBQvk8bCBpvD2+o18yf/8Phq5+soVCtEH8RjyUPJh/JJyxEb+9g IHn7AOvRq3wNgHN3LqBr7JB3LsHiIJnQdHAvLaLskOzBf3zyftB+VygPKR8nLDnwbvZvCJDYYD8v fzCPJyx7sP54Mw80HycvNm83fziJUED6U1BwTDk/Ok84XzzPPd//Pu8//0EPQh9DL0Q/RU9GX/9H b/8PmU+aXEufTK9Nv07P/0/fUO9R/1MPVB9VL1Y/V0//WF9Zb1p/W49cn12vXr9fz/9g32HvYv9k D2UfZi9nP2hP/2lfam9rf2yPbZ9ur2+/cM//cd9y73P/dQ92H3cveD95T/96X3tvfH99j36ff6+A v4HP/4Lfg++E/4YPhx+IL4k/ik//i1+Mb41/jo+Pn5Cvkb+Sz/+T35Tvlf+XD5gfmS+aP5tP/5xf nW+ef5+PoJ+hr6K/o8//pN+l76b/qA+pH6ovqz+sT/+tX65vr3+wj7Gfsq+zv7TP/7Xftu+3/7kP uh+7L7w/vU//vl+/b8B/wY/Cn8OvxL/Fz//G38fvyP/KD8sfzC/NP85P/89f0G/Rf9KP05/Ur9W/ 1s//19/Y79n/2w/cH90v3j/fT//gX+Fv4n/jj+Sf5a/mv+fP/+jf6e/q/+wP7R/uL+8/8E//8V/y b/N/9I/1n/av97/4z//53/rv+//9D/4f/y8APwFP/wJfA28EfwWPBp8Hrwi/Cc//Ct8L7wz/Dg8P HxAvET8ST/8TXxRvFX8WjxefGK8ZvxrP/xvfHO9JH0ovH/8eLx8/I0//JF8lbyZ/J48onymvKr8r z/8s3y3vLv8wDzEfMi8zPzRP/zVfNm83fziPOZ86rzu/PM8fPd8+7z//QQ9CHCAiTABpZWJpZywg U+B0ZWZhbkXQQv9ED/9CP0dPSF9Jb0p/S49Mn02v/06/T89Q31HvUv9UD1UfVi//Vz9YT1lfWm9b f1yPXZ9er/9fv2DPYd9i72P/ZQ9mH2cv/2g/aU9qX2tvbH9tj26fb6//cL9xz3Lfc+90/3YPdx94 L/95P3pPe198b31/fo9/n4Cv/4G/gs+D34Tvhf+HD4gfiS//ij+LT4xfjW+Of4+PkJ+Rr/+Sv5PP lN+V75b/mA+ZH5ov/5s/nE+dX55vn3+gj6Gfoq//o7+kz6Xfpu+n/6kPqh+rL/+sP61Prl+vb7B/ sY+yn7Ov/7S/tc+237fvuP+6D7sfvC//vT++T79fwG/BfyBPIV8ib//Cv8PPx9/I78n/yw/MH80v /84/z0/QX9Fv0n/Tj9Sf1a//1r/Xz9jf2e/a/9wP3R/eL//fP+BP4V/ib+N/5I/ln+avb0V16B/o oOlpPOd4RnQu8UX0QGNv6w/pL+df7u//7//xD/If8y/0P/VP9l/3b//4f/mP+p/7r/y//c/+3//v /wD/Ag8DHwQvBT8GTwdfCG//CX8KjwufDK8Nvw7PD98Q7/8R/xMPFB8VLxY/F08YXxlv/xp/G48c nx2vHr8fzyDfIe//Iv8kDyUfJi8nPyhPKV8qb/8rfyyPLZ8ury+/MM8x3zLv/zP/NQ82HzcvOD85 TzpfO2//PH89jz6fP69Av0HPQt9D7/9E/0YPRx9IL0k/Sk9LX0xv/01/To9Pn1CvUb9Sz1PfVO// Vf9XD1gfWS9aP1tPXF9db/9ef1+PYJ9hr2K/Y89k32Xv/2b/aA9pH8Vvxn/Hj2pfa2//b39wj3Gf cq9zv3TPdd927/93/3kPeh97L3w/fU9+X39v/4B/gY+Cn4OvhL+Fz4bfh+9/iP+KD4sfjC+NP45P 6pVtAHBlb3BsZS5k629Bj91n7Co+jx+QL5E//5WPlp+Xr5i/mc+a35vvnP//ng+fH6AvoT+iT6Nf pG+lf/+mj6efqK+pv6rPq9+s763//68PsB+xL7I/s0+0X7Vvtn//t4+4n7mvur+7z7zfve++///A D8Efwi/DP8RPxV/Gb8d//8iPyZ/Kr8u/zM/N387vz///0Q/SH9Mv1D/VT9Zf12/Yf//Zj9qf26/c v93P3t/f7+D//+IP4x/kL+U/5k/nX+hv6X//6o/rn+yv7b/uz+/f8O/x///zD/Qf9S/2P/dP+F/5 b/p///uP/J/9r/6//88A3wHvAv//BA8FHwYvBz8ITwlfCm8Lf/8Mjw2fDq8PvxDPEd8S7xP/nxUP Fh8XLxg/kcxUb20f/24vbz8aTxtfH58gryG/Is//I98k7yX/Jw8oHykvKj8rT/8sXy1vLn8vjzCf Ma8yvzPP/zTfNe82/zgPOR86Lzs/PE8HPV8+b5JEU2VudCD4Ynk6P89A3z8PQ49En/9Fr0a/R89I 30nvSv9MD00f/04vTz9QT1FfUm9Tf1SPVZ//Vq9Xv1jPWd9a71v/XQ9eH/9fL2A/YU9iX2NvZH9l j2af/2evaL9pz2rfa+9s/24Pbx9bcC9xLyZxwHKJPHCYcAByb3Zpc2lvbgkfMGctkyB2QGVjiR8g cHOTAG9yZ3Qv/5RfcM9x33Lveu97/30Pfh//fy+AP4FPgl+Db4R/hY8dP/8eTx9fhs+H34vvjP+O D48f/5AvkT+ST5NflG+Vf5aPl5//mK+Zv5rPm9+c753/nw+gH/+hL6I/o0+kX6Vvpn+nj6if76mv qr8cs3a+LawPrR+rT/+wX7Fvsn+zj7Sfta+2v7fP/7jfue+6/7wPvR++L78/wE//wV/Cb8N/xI/F n8avx7/Iz//J38rvy//ND84fzy/QP9FP/9Jf02/Uf9WP1p/Xr9i/2c//2t/b79z/3g/fH+Av4T/i T//jX+Rv5X/mj+ef6K/pv+rP/+vf7O/t/+8P8B/xL/I/80//9F/1b/Z/94/4n/mv+r/7z//83/3v /v8ADwEfAi8DPwRP/wVfBm8HfwiPCZ8Krwu/DM//Dd8O7w//EQ8SHxMvFD8VT/8WXxdvGH8Zjxqf G68cvx3Pzx7fH+8g/63vY2OJb4p//4uPIz8kTyiPKZ8qryu/LM//Ld8u7y//MQ8yHzMvND81T/82 XzdvOH85jzqfO688vz3P/z7fP+9A/0IPQx9EL0U/Rk8DR1+ulGJvdW5jZf5zd7hIv0nPR/9ND04f Ty//UD9RT1JfU29Uf1WPVp9Xr/9Yv1nPWt9b71z/Xg9fH2Av/2E/Yk9jX2RvZX9mj2efaK//ab9q z2vfbO9t/28PcB9xL/9yP3NPdF91b3Z/d494n3mv/3q/e898333vfv+AD4Efgi//gz+ET4Vfhm+H f4iPiZ+Kr/+Lv4zPjd+O74//kQ+SH5Mv/5Q/lU+WX5dvmH+Zj5qfm6//nL+dz57fn++g/6IPox+k L/+lP6ZPp1+ob6l/qo+rn6yv/62/rs+v37Dvsf+zD7QftS//tj+3T7hfuW+6f7uPvJ+9r/++v7/P wN/B78L/xA/FH8Yv/8c/yEwm7yf/yE/JX8pvzn//z4/Qn9Gv0r/Tz9Tf1e/W///YD9kf2i/bP9xP 3V/eb99//+CP4Z/ir+O/5M/l3+bv5/+f6Q/qH+sv7D8lWHJn7d//7u/tH/E/8k/zX/Rv9X/2j//3 n/iv+b/6z/vf/O/9//8P/wAfAS8CPwNPBF8FbwZ/B4//CJ8Jrwq/C88M3w3vDv8QD/8RHxIvEz8U TxVfFm8XfxiP/xmfGq8bvxzPHd8e7x//IQ//Ih8jLyQ/JU8mXydvKH8pj/8qnyuvLL8tzy7fL+8w /zIP/zMfNC81PzZPN184bzl/Oo//O588rz2/Ps8/30DvQf9DD/9EH0UvRj9HT0hfSW9Kf0uP/0yf Ta9Ov0/PUN9R71L/VA//VR9WL1c/WE9ZX1pvW39cj/9dn16vX79gz2HfYu9j/2UP/2YfZy9oP2lP al9rb2x/bY//bp9vr3C/cc9y33PvdP92D/93H3gveT96T3tffG99f36PAX+fIFN1YmplY/50yz/M T81fgN+B74Z/h4//iJ+Jr4q/i8+M343vjv+QD/+RH5Ivkz+UT5Vflm+Xf5iP/5mfmq+bv5zPnd+e 75//oQ//oh+jL6Q/pU+mX6dvqH+pj/+qn6uvrL+tz67fr++w/7IP/7MftC+1P7ZPt1+4b7l/uo// u5+8r72/vs+/38Dvwf/DD//EH8Uvxj/HT8hfyW/Kf8uP/8yfza/Ov8/P0N/R79L/1A//1R/WL9c/ 2E/ZX9pv23/cj//dn96v37/gz+Hf4u/j/+UP/+Yf5y/oP+lP6l/rb+x/7Y9H7p/vr4LaQVc69ENb AHByb3Zpc2lvAm6GEGctZGV2XcggSW304mVkhA+FH/+GL/Gf8q/4//oP+x/8L/0///5P/18AbwF/ Ao8DnwSvBb//Bs8H3wjvCf8LDwwfDS8OP/8PTxBfEW8SfxOPFJ8Vrxa//xfPGN8Z7xr/HA8dHx4v Hz//IE8hXyJvI38kjyWfJq8nv/8ozynfKu8r/y0PLh8vLzA//zFPMl8zbzR/NY82nzevOL//Oc86 3zvvPP8+Dz8fQC9BP/9CT0NfRG9Ff0aPR59Ir0m//0rPS99M703/Tw9QH1EvUj//U09UX1VvVn9X j1ifWa9av/9bz1zfXe9e/2APYR9iL4LaAHVwZGF0ZWdlTfigcmcA9UEvZPUgdBByaWJ1Z5JhbGf+ b2gg9o/3n/ivZB9lL2t//2yPbZ9ur2+/cM9x33Lvc///dQ92H3cveD95T3pfe298f/99j36ff6+A v4HPgt+D74T/P4YPhx+IL4k/ik9mdDA1AC8wMi8yMDA38Y6BOjIzi6+Mv4rvj+//kP+SD5MflC+V P5ZPl1+Yb/+Zf5qPm5+cr52/ns+f36DvH6H/ow+kH6UvZmV0aG3/pp+nr6Xfqg+rH6wvrT+uT/+v X7BvsX+yj7OftK+1v7bP/7ffuO+5/7sPvB+9L74/v0//wF/Bb8J/w4/En8Wvxr/Hz//I38nvyv/M D80fzi/PP9BP/9Ff0m/Tf9SP1Z/Wr9e/2M//2d/a79v/3Q/eH98v4D/hT//iX+Nv5H/lj+af56/o v+nP/+rf6+/s/+4P7x/wL/E/8k//81/0b/V/9o/3n/iv+b/6z//73/zv/f//DwAfAS8CP2l//2qP BU8DfwSPCJ8Jrwq/C8//DN8N7w7/EA8RHxIvEz8UT/8VXxZvF38YjxmfGq8bvxzP/x3fHu8f/yEP Ih8jLyQ/JU/zJl9l3kFNKF8pbyefK7//LM8t3y7vL/8xDzIfMy80P/81TzZfN284fzmPOp87rzy/ /z3PPt8/70D/Qg9DH0QvRT//Rk9HX0hvSX9Kj0ufTK9Nv/9Oz0/fUO9R/1MPVB9VL1Y//1dPWF9Z b1p/W49cn12vXr//X89g32HvYv9kD2UfZi9nP/9oT2lfam9rf2yPbZ9ur2+//3DPcd9y73P/dQ92 H3cveD//eU96X3tvfH99j36ff6+Av/+Bz4Lfg++E/4YPhx+IL4k//4pPi1+Mb41/jo+Pn5Cvkb// ks+T35Tvlf+XD5gfmS+aP/+bT5xfnW+ef5+PoJ+hr6K//6PPpN+l76b/qA+pH6ovqz//rE+tX65v r3+wj7Gfsq+zv/+0z7Xftu+3/7kPuh+7L7w//71Pvl+/b8B/wY/Cn8OvxL//xc/G38fvyP/KD8sf zC/NP//OT89f0G/RfwYfBy/Uj9K//9PP19/Y79n/2w/cH90v3j//30/gX+Fv4n/jj+Sf5a/mv//n z+jf6e/q/+wP7R/uL+8///BP8V/yb/N/9I/1n/av97//+M/53/rv+//9D/4f/y8AP/8BTwJfA28E fwWPBp8Hrwi//wnPCt8L7wz/Dg8PHxAvET//Ek8TXxRvFX8WjxefGK8Zv/8azxvfHO8d/x8PIB8h LyI//yNPJF8lbyZ/J48onymvKr//K88s3y3vLv8wDzEfMi8zP/80TzVfNm83fziPOZ86rzu//zzP Pd8+7z//QQ9CH0MvRD//RU9GX0dvSH9Jj0qfS69Mv/9Nz07fT+9Q/1IPUx9UL1U//1ZPV19Yb1l/ Wo9bn1yvXb//Xs9f32DvYf9jD2QfZS9mP/9nT2hfaW9qf2uPbJ9tr26//2/PcN9x73L/dA91H3Yv dz//eE95X3pve398j32ffq9/v/+Az4Hfgu+D/4UPhh+HL4g//4lPil+Lb4x/jY+On4+vkL//kc+S 35PvlP+WD5cfmC+ZP/+aT5tfnG+df56Pn5+gr6G//6LPo9+k76X/pw+oH6kv1V//1m+sP6pvq3+v j7Cfsa+yv/+zz7Tfte+2/7gPuR+6L7s//7xPvV++b79/wI/Bn8Kvw7//xM/F38bvx//JD8ofyy/M P//NT85fz2/Qf9GP0p/Tr9S//9XP1t/X79j/2g/bH9wv3T//3k/fX+Bv4X/ij+Of5K/lv//mz+ff 6O/p/+sP7B/tL+4//+9P8F/xb/J/84/0n/Wv9r//98/43/nv+v/8D/0f/i//P/8ATwFfAm8DfwSP BZ8Grwe//wjPCd8K7wv/DQ8OHw8vED//EU8SXxNvFH8VjxafF68Yv/8ZzxrfG+8c/x4PHx8gLyE/ /yJPI18kbyV/Jo8nnyivKb//Ks8r3yzvLf8vDzAfMS8yP/8zTzRfNW82fzePOJ85rzq//zvPPN89 7z7/QA9BH0IvQz//RE9FX0ZvR39Ij0mfSq9Lv/9Mz03fTu9P/1EPUh9TL1Q//1VPVl9Xb1h/WY9a n1uvXL//Xc9e31/vYP9iD2MfZC9lP/9mT2dfaG9pf2qPa59sr22//27Pb99w73H/cw90H3Uvdj// d094X3lven97j3yffa9+v/9/z4DfrQ+uH4Pvgh+DL4c//4hPiV+Kb4t/jI+Nn46vj7//kM+R35Lv k/+VD5Yfly+YP/+ZT5pfm2+cf52Pnp+fr6C/H6HPot+j76T/pg8gIFAAbGVhc2UgcmWBqFBvbmQg dG+nL/+oP6Zvq3+sj62frq+vv7DP/7Hfsu+z/7UPth+3L7g/uU//ul+7b7x/vY++n7+vwL/Bz//C 38PvxP/GD8cfyC/JP8pP/8tfzG/Nf86Pz5/Qr9G/0s//09/U79X/1w/YH9kv2j/bT//cX91v3n/f j+Cf4a/iv+PP/+Tf5e/m/+gP6R/qL+s/7E//7V/ub+9/8I/xn/Kv87/0z//13/bv9//5D/of+y/8 P/1P//5f/28AfwGPAp8DrwS/Bc//Bt8H7wj/Cg8LHwwvDT8OT/8PXxBvEX8SjxOfFK8VvxbP/xff GO8Z/xsPHB8dLx4/H0//IF8hbyJ/I48knyWvhH+Fj/+GnybvJ/8sDy0fLi8vPzBP/zFfMm8zfzSP NZ82rze/OM//Od867zv/PQ8+Hz8vQD9BT/9CX0NvRH9Fj0afR69Iv0nP/0rfS+9M/04PTx9QL1E/ Uk8DU1+phyJEZXZlbPBvcGVyVO9V/1QvWM//Wd9a71v/XQ9eH18vYD9hT/9iX2NvZH9lj2afZ69o v2nP/2rfa+9s/24Pbx9wL3E/ck//c190b3V/do93n3iveb96z/9733zvff9/D4AfgS+CP4NP/4Rf hW+Gf4ePiJ+Jr4q/i8//jN+N747/kA+RH5Ivkz+UT/+VX5Zvl3+Yj5mfmq+bv5zP/53fnu+f/6EP oh+jL6Q/pU//pl+nb6h/qY+qn6uvrL+tz/+u36/vsP+yD7MftC+1P7ZP/7dfuG+5f7qPu5+8r72/ vs//v9/A78H/ww/EH8Uvxj/HT//IX8lvyn/Lj8yfza/Ov8/P/9Df0e/S/9QP1R/WL9c/2E//2V/a b9t/3I/dn96vKc8q3/8r79/v4P/lD+Yf5y/oP+lP/+pf62/sf+2P7p/vr/C/8c//8t/z7/T/9g/3 H/gv+T/6T//7X/xv/X/+j/+fAK8BvwLPDwPfBO8F/1beZGlzYwB1c3Npb25zIPxmb1hvCP8HLwwf DS8OP/8PTxBfEW8SfxOPFJ8Vrxa//xfPGN8Z7xr/HA8dHx4vHz//IE8hXyJvI38kjyWfJq8nv/8o zynfKu8r/y0PLh8vLzA//zFPMl8zbzR/NY82nzevOL//Oc863zvvPP8+Dz8fQC9BP/9CT0NfRG9F f0aPR59Ir0m//0rPS99M703/Tw9QH1EvUj//U09UX1VvVn9Xj1ifWa9av/9bz1zfXe9e/2APYR9i L2M//2RPZV9mb2d/aI9pn2qva7//bM9t327vb/9xD3Ifcy90P/91T3Zfd294f3mPep97r3y//33P ft9/74D/gg+DH4QvhT//hk+HX4hviX/ir+O/5M+Kv/+Lz4/fkO+R/5MPlB+VL5Y//5dPmF+Zb5p/ m4+cn52vnr//n8+g36Hvov+kD6Ufpi+nP/+oT6lfqm+rf6yPrZ+ur6+/H7DPsd+y77P/Ckhwcm/u dgrwC1GPQGe1n7avtN//uZ+6r7u/vM+9377vv//BD//CH8MvxD/FT8Zfx2/If8mP/8qfy6/Mv83P zt/P79D/0g//0x/UL9U/1k/XX9hv2X/aj//bn9yv3b/ez9/f4O/h/+MP/+Qf5S/mP+dP6F/pb+p/ 64//7J/tr+6/78/w3/Hv8v/0D//1H/Yv9z/4T/lf+m/7f/yP//2f/q//vwDPAd8C7wP/BQ//Bh8H Lwg/CU8KXwtvDH8Nj/8Onw+vEL8RzxLfE+8U/xYP/xcfGC8ZPxpPG18cbx1/Ho//H58gryG/Is8j 3yTvJf8nD/8oHykvKj8rTyxfLW8ufy+P/zCfMa8yvzPPNN817zb/OA//OR86Lzs/PE+ND44fjy89 j/8+nz+vQ79Ez0XfRu9H/0kP/0ofSy9MP01PTl9Pb1B/UY//Up9Tr1S/Vc9W31fvWP9aD/9bH1wv XT9eT19fYG9hf2KP/2OfZK9lv2bPZ99o72n/aw8HbB9tL7gkXFwoVXD4ZGF0QpFur2+/be9yf/9z j3Sfda92v3fPeN9573r//3wPfR9+L38/gE+BX4Jvg3//hI+Fn4avh7+Iz4nfiu+L//+ND44fjy+Q P5FPkl+Tb5R//5WPlp+Xr5i/mc+a35vvnP//ng+fH6AvoT+iT6NfpG+lf/+mj6efqK+pv6rPq9+s 763//68PsB+xL7I/s0+0X7Vvtn//t4+4n7mvur+7z7zfve++///AD8Efwi/DP8RPxV/Gb8d//8iP yZ/Kr8u/zM/N387vz///0Q/SH9Mv1D/VT9Zf12/Yf//Zj9qf26/cv93P3t/f7+D//+IP4x/kL+U/ 5k/nX+hv6X//6o/rn+yv7b/uz+/f8O/x///zD/Qf9S/2P/dP+F/5b/p///uPQP9CD/6f/M/93wHv Av//BA8FHwYvBz8ITwlfCm8Lf/8Mjw2fDq8PvxDPEd8S7xP//xUPFh8XLxg/GU8aXxtvHH//HY8e nx+vIL8hzyLfI+8k/38mDycfKC8pPypPK19wyU2kYW7/kGVycXApLQ//Lh8sTzDvMf8zDzQfNS82 P/83TzhfOW86fzuPPJ89rz6//z/PQN9B70L/RA9FH0YvRz//SE9JX0pvS39Mj02fTq9Pv/9Qz1Hf Uu9T/1UPVh9XL1g//1lPWl9bb1x/XY9en1+vYL//Yc9i32PvZP9mD2cfaC9pP/9qT2tfbG9tf26P b59wr3G//3LPc99073X/dw94H3kvej//e098X31vfn9/j4Cfga+Cv/+Dz4Tfhe+G/4gPiR+KL4s/ /4xPjV+Ob49/kI+Rn5Kvk7//lM+V35bvl/+ZD5ofmy+cP/+dT55fn2+gf6GPop+jr6S//6XPpt+n 76j/qg+rH6wvrT//rk+vX7BvsX+yj7OftK+1v/+2z/8PAB8BL7gPuR+9L74//79PwF/Bb8J/w4/E n8Wvxr//x8/I38nvyv/MD80fzi/PP//QT9Ff0m/Tf9SP1Z/Wr9e//9jP2d/a79v/3Q/eH98v4D+H 4U8vSbygaXRpYeYQ8HZlcyLi/+QP4j/m///oD+kf6i/rP+xP7V/ub+9///CP8Z/yr/O/9M/13/bv 9///+Q/6H/sv/D/9T/5f/28Af/8BjwKfA68EvwXPBt8H7wj//woPCx8MLw0/Dk8PXxBvEX//Eo8T nxSvFb8WzxffGO8Z//8bDxwfHS8ePx9PIF8hbyJ//yOPJJ8lrya/J88o3ynvKv//LA8tHy4vLz8w TzFfMm8zf/80jzWfNq83vzjPOd867zv//z0PPh8/L0A/QU9CX0NvRH//RY9Gn0evSL9Jz0rfS+9M //9OD08fUC9RP1JPU19Ub1V//1aPV59Yr1m/Ws9b31zvXf//Xw9gH2EvYj9jT2RfZW9mf/9nj2if aa+6b7t/vI9q72v//20PcR9yL3M/dE91X3Zvd3//eI95n3qve798z33ffu9///+BD4Ifgy+EP4VP hl+Hb4h//4mPip+Lr4y/jc+O3+VXkG8LkPCRuTyPyHByb3YQaXNpb+Xwbmct+GRldpNfkX+Pr5c/ mE//mV+ab5t/nI+dn56vn7+gz/+h36Lvo/+lD6Yfpy+oP6lP/6pfq2+sf62Prp+vr7C/sc//st+z 77T/tg+3H7gvuT+6T/+7X7xvvX++j7+fwK/Bv8LP/8PfxO/F/8cPyB/JL8o/y0//zF/Nb85/z4/Q n9Gv0r/Tz//U39Xv1v/YD9kf2i/bP9xP/91f3m/ff+CP4Z/ir+O/5M//5d/m7+f/6Q/qH+sv7D/t T//uX+9v8H/xj/Kf86/0v/XP//bf9+/4//oP+x/8L/0//k///18AbwF/Ao8DnwSvBb8Gz/8H3wjv Cf8LDwwfDS8OPw9P/xBfEW9tv27Pb98SrxO/F8//GN8Z7xr/HA8dHx4vHz8gT/8hXyJvI38kjyWf Jq8nvyjP/ynfKu8r/y0PLh8vLzA/MU//Ml8zbzR/NY82nzevOL85z0c63zvvknxAZWMXYHBAc2Uu b3JnPc9n/ZR6Pj0vPj8/T0O/RM9F3/9G70f/SQ9KH0svTD9NT05f/09vUH9Rj1KfU69Uv1XPVt// V+9Y/1oPWx9cL10/Xk9fX/9gb2F/Yo9jn2SvZb9mz2ff/2jvaf9rD2wfbS9uP29PcF//cW9yf3OP dJ91r3a/d8943/9573r/fA99H34vfz+AT4Ff/4Jvg3+Ej4Wfhq+Hv4jPid//iu+L/40Pjh+PL5A/ kU+SX/+Tb5R/lY+Wn5evmL+Zz5rf/5vvnP+eD58foC+hP6JPo1//pG+lf6aPp5+or6m/qs+r3/+s 763/rw+wH7Evsj+zT7Rf/7Vvtn+3j7ifua+6v7vPvN//ve++/8APwR/CL8M/xE8VX/8Wbxd/xY/G n8qvy7/Mz83f/87vz//RD9If0y/UP9VP1l//12/Yf9mP2p/br9y/3c/e3//f7+D/4g/jH+Qv5T/m T+df/+hv6X/qj+uf7K/tv+7P79//8O/x//MP9B/1L/Y/90/4X//5b/p/+4/8n/2v/r//zwDf/wHv Av8EDwUfBi8HPwhPCV//Cm8LfwyPDZ8Orw+/EM8R3/8S7xP/FQ8WHxcvGD8ZTxpf/xtvHH8djx6f H68gvyHPIt//I+8k/yYPJx8oLyk/Kk8rX/8sby1/Lo8vnzCvMb8yzzPf/zTvNf83DzgfOS86PztP PF//PW8+fz+PQJ9Br0K/Q89E3/9F70b/SA9JH0ovSz9MT01f/05vT39Qj1GfUq9Tv1TPVd//Vu9X /1kPWh9bL1w/XU9eX/9fb2B/YY9in2OvZL9lz2bf/2fvaP9qD2sfbC9tP25Pb1//cG9xf3KPc590 r3W/ds933/9473n/ew98H30vfj9/T4Bf/4Fvgn+Dj4Sfha+Gv4fPiN//ie+K/4wPjR+OL48/kE+R X/+Sb5N/lI+Vn5avl7+Yz5nf/5rvm//IL8k/yk+dP55Pn1//o2+kf6WPpp+nr6i/qc+q3/+r76z/ rg+vH7AvsT+yT7Nf/7RvtX+2j7efuK+5v7rPu9//vO+9/78PwB/BL8I/w0/EX//Fb8Z/x4/In8mv yr/Lz8zf/83vzv/QD9Ef0i/TP9RP1V//1m/Xf9iP2Z/ar9u/3M/d3//e79//4Q/iH+Mv5D/lT+Zf /+dv6H/pj+qf66/sv+3P7t//7+/w//IP8x/0L/U/9k/3X//4b/l/+o/7n/yv/b/+z//f/wDvAf8D DwQfBS8GPwdPCF//CW8KfwuPDJ8Nrw6/D88Q3/8R7xL/FA8VHxYvFz8YTxlf/xpvG38cjx2fHq8f vyDPId//Iu8j/yUPJh8nLyg/KU8qX/8rbyx/LY8uny+vML8xzzLf/zPvNP82DzcfOC85PzpPO1// PG89fz6PP59Ar0G/Qs9D3/9E70X/Rw9IH0kvSj9LT0xf/01vTn9Pj1CfUa9Sv1PPVN//Ve9W/1gP WR9aL1s/XE9dX/9eb19/YI9hn2KvY79kz2Xf/2bvZ/9pD2ofay9sP21Pbl//b29wf3GPcp9zr5/f oO+h//93z3jfee96/3wPfR9+L38/D4BPgV+Cb4NzRGF2ZX4sg8+E34Lvh0+IX4lpVABvIGJlIG1v cgONUHYQZWNpZmljgCBJIHRvb2uOYAJojaFvdXJjZXMEIG92wGp1bml0ACAzLjguMS4gAkONkGF0 ZWQgYU5uih+LL4k8RWOJEHDCc41QcHJvao3gj/A6Zo2AII/hkQCQ4GxlG4/wlCZjkJOOs2phcogo cymVE21lLpEvP5I/iT+YX5lvmnl24GI0kE9yaWeaMGFsniI5jbBpeo1Qj4GXBTogQZvwOS45NTmN MHl/kMCbL5w/mk+hP6JPjGpo45EAjkFtYWSO4pfwjWHGZI4CkLBpb26PYJWS9GdloyBykLOOwqeQ dXEec6QPpR+jLI1AdHdl86lAlvZzOqp/q4+jL66/S6/PsNktlRBpeJDTIKuPwLCgY49Bc5dQeZaA j6pQj/CwkI+kLnN3sJAgZ3VpLlSPUHRU+Y2QZU2oIKogsY+yn7Cvp3Ufdi+6pyBTn0VjpxF3qTCQ 4LdrLpQwqlCuYCB+NKCPuM+537rvu/+9DyD6Uo9QdcSQtwGqBI5hj3DznnWgITUzxODAz8Hfwu9/ sX/KX7Ofp4CnkJDhnyFt/nCV0I0xpyG28I7AwGCUkvuN0MXAaY9Rl3CV4JDArlD2L6kw0gMpzF/N b8t/xD87xU+9iEqXUJ8joCEyMPAuNjA00u/T/9UP1h/71y+9iELQcb/02QjZ39rvP9v/3Q/eH8ZP x1/IZTE3/jPJD+Hv4v/MP+pvzl++l3+Owp6wp+GPgcfQ64DSEWZ+YY9Al+GOwKgglRCUsG3/7H/t j+uf5F/lb72ItoTyAJXwYXeNgGu3Uy5yj8A+KJeQx/H4P/lCwBB1Zv/5sPJP81/0b/V/9o/YP9lF /jDZgOkv/I/9n/6v/7+9PWWOwGmo0WZmlOGPYDf/loDAEo9QAx8ELwU/Bk8HX/8BHwIvCo8Lnwyv Db8Oz+af4+evyJE3ODjArxJvE3937E8a7xv/V5bhqXCowG0Bj+EoZG93bmxvv6eAl5CQoL6gGDXw oyq+pfwqII2QjwTQpM/StxCV0AcdDx4fHCxIVFRQL1JTIwFxdbdxLyMRcI+osZgApvGNUGFib4bg 36oFkPCNkY7CqXB3qgCQsOphkGBZjxAgpxApcY5w/yR/JY8cLM9xp7QZwo9glSIzjsIWMHRwlJKO cGNv+myNsHT7gPCxlaHH0Alw5yqwL3inw3R5jdAr7yz/3xwsHBCVIadwqJIsjvGOsf+QsI6zlDGp QI/wqHCnMKgw+7YgtwNz0OCtdqgxCXCNkP04MXCQsL6gM280fxwsMyJuc5gfO98cHUmflJRwcv+G 4JVApxCPYI1ArcEn5ZDRV5Uix9AYRCg6gyk3EGLudTeUQaUJIW4r3z8/HB33IRC+0UNhYtAxx/Gp NqnIu40xqHB1lHGOwsgmIEHR/58wqLBFdEjFRd9G7xwvTb9jTs8uOnZhacAQSVIo/42QjXCG4JDg GcC08qeAIIA/rdGNILWwKXEV4PFRLC7+LvnBQXgoZo9g0LJQj1Gf/y4NloCn0JSgtZGQ0UxGn4X/ wBAvkY/wTEUo4gkhMyI2WvuOYKogbF4RjtBYL1k/T6//YA9hH2IpN/XxwCqwx/GnEb5kSWKO0Z4i OoOe4yhFsJ+P8LVXU7BUwaoEISk+L/9j32Hvai9rP0B7ZjFeUTdljwkhXooJIY7QbHBmF9C/af9u D2wfcq9zv3TKU5DA//FAkR92j3SfeQ96H3svfD+7fU9+V1aosKAglKF2CSDLqKG3AS2nkHYtKVCP wO2PQUCN4JRDLo2AGCDQANwgQfuAIDEYIHZMkYbB+mmQ4EqQYJ5gl/B+73//XX4MR49QqUCnkHSg IEZJlUAyNxEgNC7ZgDDjCdDo8Do0M4ZPh19+DHpBggFEgxCqINFCOJJj/0swTHIvtII6ix+ML34M 39A7IDB4oGagIBegoCBBV/WgIFuCPl1BIFthVGKQv9ORz34MdXAq0WWpNaihvi84op5wRJGooZ7A Z8ghfwkA8j+Xf33/m/+dD6ZOa98vuCrTFL8Vz98LVzdycADudynhcCEYAnkrQTDwF9B/tOAg0KZj yFBVw4PAOfBp/mMqw57fn++d/F8SrgFxYP9TsBgCndC2ISlBRKFDhqcinyBBENBBY741XKJhcNAg e6jgNsM7qV+qb538TEZu/HVt0GBMYDcRr1kg1kRwPzGSNzFdoaMfpC/fC0l09ifgYNEhYklBaUBU UCog/7DPsd81jdAQhEC7gDgxx/F+a0WwZmFcsV4zXHGZcGf/hPDPkNHAx9BVMY/BTEW2Efc6dERw iaBjVnBmwbrvu/9/PP2vHTDwwBG6QEtD0IFlPnjxUGhxtFabQPGxdWf/0ODHayoCwn/Dj5idS0By Qf0YkW9yf8r/ne/Nz87fH01vK3OPcPAwSzEtOGBLQDvfpxMrc3jAMMByAHK2z7ff/6UsKQK6otRX V8E30Th0jyL/0K/Rv6t/XKM4sURwXKI5YX/xEUFUMQCa89oijmHxAHV/m0BpMYMQMQApcQkhz6Br /ymwaUAYoUrwzZ/cH8+/4t/z4++S+1RXRHBVQikTmqH3x4FEcHAAKiog4PIi8OHi/6cSQ2GbVtYP 1x+47jLB+iD+ZF+AEJBbYGbwTX/mv8SP/zhxI0Ep8TGiX4CnIiiQ5MD/OECtsiCROGPqUSOUv8QY AvhKUkXIIWhS+hBdIPAPn/Ef5NywIMig5MBzL0SQ/2bSPh/4f+S/+5/8r/2//s+3/98A6BegZyoQ 72AsAY//Ap8ArwU/Bk8HWYVxr3CGD3MI3wnvIC0OkgtBS9VN/2jSmdAOhAufDK8HLIngMuDTGVB4 hCBMOBBiS9AH/Ffs0uyQ7Vk8d+4uFCRAbVtCZXAwZvAuQ6AUn2e9Fbo+B28QzxHfoWZvgh/+doO6 G18cb3etOCGJwoWg9GF5RHBBMKBTsIoBRHBZinMwOooQiuAxhKBNwYkwTVQtMDiKgCBf4yFvd611 YmqDwImxlI//lZyZZSZfJ28HLJnfmu8sb/8tfwdPMZ8yr9MZX2DewqYh/0OgPfDvUqxVOrB4wC9A 8/S/cWDq4d8h2jBCcb8Dd0mg/0xFOFHt4KlPNU8zXVdB81H/g4D7fzzPjS7aE8nBSTeZdP9bM2bw SiH2pNox09MLcKaA//NgVIHBZaKzrzM/X0Bv3T3LO5GtozLs4E1CRv9ID70zbHdyAFTwmXOtAmYT YSdOpPahirAuNYowLjHx7sAofjfuwEqwVnFmkO1PVDaKMFAROIqgUHE/T/9L3zNfUj9TT29M2mJn YtSg/mza0FziZ/NcokYEr0M59706wWppAI+UpyGF4Fk5c/9pQIliVR9WL8SfhJBDQQtwv7+A7/9d 71QtpyNwIG/G4b+2cGBhZ2LaMOEAvqNuZ/PfW0NN0KjgRkBCsnApYLAx/WkydqzRQvJSD2G/VC9o L/9pP3fPeN9sD2ofbo9vn4Ev/4I/g0+EX4VvcZ9yr4ifiaKaRFsgMlFBilgzOXjP/3nfjT+OT49f kG9+X39vk53/Ki8rP4M/hE8uby9/MI+Jf/+Kj3Dfjq+Pv6F24bHhsepE/+jx31E5ME5jzW/s3+3v pgP+a5Awp6C/kZdAyQCvcEWh/nXHkLQCRVV4oODA2w+SL5+QPdVDpyKNsN9Bbj+bn/+cr5BPn8+g 36Hvov+kDwQP/6Wvpr+kz6lfqm8KbKwfrS//Db8Ozw/fr++w/xMPFB8VL/8WPxdPGF8Zbxp/tE+1 Xx2v/x6/H8+/n8CvIvrZAPNhI+rKNiS1MyVhOjWAcSW//8SPxZ8o7obPh99Dk4wvjTT/yj/LT6s8 jZ/SL9M/vr/V76/W/1fj1QDXQGvpJHCIUd/pwEZA2NDq4PVAYmdAgbCfUBDYP9lP11+WSzxBRPAJ hmE9IpeQdHA6L1Yv9bCZUC52SS+ZYWUAeC5waHAvR1C0V1+34GeXkILyX83AH+mgZCA4EJpxiIBz I1O3XGCX0E4gX2Rgd1B3QrFaX4jEIt6Z3XBmt/BsGmTdcmboUPrBdHtIAFlQRVJMSU5LfiDh3+Lv 4//lD+Yf5yF9Hn3oAehQOxCWoFxjZvwxXFjw3zCeCOn/6w/sH3/tL+4/l4eXd5jQ9o/YDjnyMt5Q L0HekN1f3m/ffK9QkJRxZGJkAHdGoW1nkfpyeGBBmTBDEEVwmTBE1o9ZkrNwYGGUoHF1aZsl3Xhg V0pA6FA54SCC8JoA9/pf+2/ffGmX8EKBu8ABUtxqb99gO3DHkCCGcXbA/QDyRoJBN6NYEPGQZRGy 4LuetUXgYtTgbiAGAXTfUv87cQIPAx9JHQYheKA44ozg/G0v1Kdn/wqfti4AkP8R/wYS1KF4YIjE lII+5IIRTsLYVihuUJMTcSs38Jah/1CQ8ZDVADfhlqG8j72f+JX/BOGasDu/Dx/fbYLAORBDEf+V cDgAeGDNwBKm/kDzoQGC21tCN4B6dnE3gGSU0B3C9G9jRKEuHrAYPxlPbS3v32CaAQYSZGBsjUOU YmVQ+ZkwKHlEMFCQdkU54EVwv4iRQoEeUCMzRQO8IHWy4f9bMx7vH//ffN9QOcEj5jjw/QEBQkpR 21GUUyNCReDQNP+zIJVS1OCadIIyDJse3ydv799vLi8vPzBKTwyqlGIkZK84cRQzBkB18G/o0Wfd L98x7zL/4F/hbdBALvGSu/BtgXBh8lPxki+A0JahX/82BudP6F/pbTu/PM890e9f//BvQO9B/zZC 98/3nzlf+bj/Uf83r9o/BfRZ0JfQZlBY8d+CUFiwZDH/RnwQY3ggiJH3YDGBsP+keDWkEbM2r0zP zzjPOd8670XfL1gUMz3//z8PQB9X31joQ19Eb1xvWKv/SR9I71VfSwn/MNtg3FGUcXuIUIZAdJTw 1MA2MN0BYc5iG3GCMvUgbnlSv1PPf1TcZxC78IIQmaGI4UZAIPZI/fCA4XIdcNTwgmDQYP2CMW2C EGyxlPA1ECSh/9DzmrCYEGI0gXCGgEeibrH/BVGIQbNRiJFsEmiPaZ8oj/8iIB2S2+CZcR0yS79x n4VPn0/gUWKZoQcjBTF1bpnhW9uQc+MoBeEAIG3yYHn//VHHMCUA/aHbUpWw/iUTsvsIcHVgcnTP dd/TzZlxbTP/NMD/wm6iuBCNgG3hbuo1cf//wm7ilUHHMG2ywqJ4NPTg+4AkfCFzbqJ0v31fkz+a Em+bAJaglZI1pCgG8ZngdP80YP1T/8GasB2RRgF5oZkwf5Sl0DCbcP2Q9SCU0NBgIf8ToHQxhK+F vxpd0ECZg//Cv/GQlKAb4G6iyBC8IHlvJt8qwzWkgbVuoiKQZG9Tgsb+Y4rBEkL/wYxfjW9U3G9S /VTQd5Mbj6WD1c+Qb1MShv8b4IesgsaJlZSfla9U3LvA/m5ssbeAAXF5InpzCHAdkX+En52fti4G 8/1xNEhRMXf/8mDbkM9RbTGLAYqTAHNREf94goLFa8MSh6E/ok+evbex+wGRePBpAHAVAKZRwyDH MPsFALfwZAbGKuKs5U/gIsP/eMJRcQhwu8GAgiLDCX+pz39qj4e0ErMBsAASdDL/wk38RDUqIhTQ j6WaL7P5wpC/sI+xnxpee3fbs09RZtxA/HRJj4B5wiVxp+HPUc1i/C54uZBs4fHQG+D/wrRT/4NE uA+5H1Tcs8cUogjxdCH/3PCCxvRyrnJPIyrxIvG9oP+/X8BvVN/Fr8a/hv3+ISWw360jz7Za4P3x zlA6yH/Jj/3HnC3bo/HxgoKLNP21/8L/x4BtYq60ByMIcLPHtYABRv/m5IxPzl9qnnvil9GCYDVh /79P1g/Pb//BVvHyYLfBK2Hcc2uJo8xW8jBybLEs0++B4zWzAZDmgGWJ4f/CkuH/tJbY79n/x5yX 0YK24J/hr//bD90/K6SUJZHGImAqMdyT++Xg/vBkixLopOAD5E/lX/+q/jRg61SPQ+oToDLrv+zP ++Zv0IhhkMGtQImikadRMf/f4oLGdDKLM75j46/wr/G//4c3/XE0cIoxp+Es4orhppj/EofFb/iv x4/9T/5fM07dbP+cIavhvEEH8t3Vb6LYsYKR+YrCaXrrUnQR3cOLwL2g/U6wdAAvAT//TGhBCGAS 8f/7tBKmF/HnYREggh9bIJqk/wPYT+B5EGfCsG8Ir/8u6IX3iEfE824gdqvgtCF0MimA/xvAexLn YTTBGAHupCzTvDD/G6F8TxBvwW/EIKfRUYHLwP/88U6wGGDTQqxxFlFwMYiT/ysWE9B7gWfCbQHo izTA94//F4//LlCwaEGtYB4/H09N7/9P49L1G4ca6PtzkGNtwoFk//V5eEHTSCGvIr//TGZHHBB/ c4Cn0Isw+5EcZ4G13dUo/+nyrBCJ4VbwehC88NRBw4Bvq+Apjyqffn1ke3ClEXT/6yFGYGYgLolG oAtEBbFuMf/C8aDEikKCzDCvMb+evsvR24tAtgpFbcNiAy+JI49E/7uF0LXp8nwBa5HS4zffOO/7 sq2IkGzdBD3m0cL1QKTx/mRn0YAGYgSEb0AfQS/LZcx0ddKZLolkbwvhHBL/UGPfASTiiODUMGYg gsZtYf9FX0ZvEY8SliV20oAwYUJw//VArBGzhYgRj5ZoQWDw1CD/sAYo30z/Tg//poG10LWnsP+I gLakri3eRKSSUrb8WVRPq1Vf/0wos8wrpLBktUT/ZiE1UnoQFlBzg4sBHBLcMf+CYhQCs7iBtFuP XJ+Oft3y/7aiDpNLUWAzUQNRxbyh3DBdSLByrFBQEzrXKIoUKf9jP2RPGL+aVGpva3//T24v628/ cElB+tBJ6lekwK5Rb9ixvIFYAS+QbYmieJFE/0rTNeKzoErDe1ampXTCt/+7cf9wDWLDMa8R0XBs BOH/FPMMp5DgtqSk4YuxLWFgJPdRUvVAvUF2riE2BGMPeX//eo/28n8Tp7JQBEszLIAM4Z8MmaTH DqKr88vgdWeLML+8gm3vgR9Hb4SyuyBniNC/UPevgOrkBlTexLtAeQQS/67xLJN2QgRSj4EDMIdv iH//ui2S4MMwk6PUFoa/jw+QH+9wf5QPlR+WI0OvsHhDvfD7GwOnwj+Wf5ePlZ+a75v//Z0JUxZg vDAwn56/nM+hP6uiT6NaVh4QOoNLLd7AmHYtYtQQE/FzQL2A9aMQcD0gLtJgaRDLwHPg7HVmNBFp EHawMXZBriD0IEq2oE/ScIAPpR+jLV5HWxA9MdEwp0BE9UAyCDYuMEUwMjAwN+Igr7A6MjKrf6yP cx2/pz+oQKjqsE+xX6M8QtEw1dwxZrNgW6duXXQQy9BvfyHMOBJmHhAvDKA0AWnfe5H3f7Yvtz8G QGfSYMLxfm28f72Poz/AP8FPR61j3wMwDPMM0DzQAzBlqGAk4f/MR0iRC+GGQtEhX8CS4DtA/3fx 8BBhEYSRU1CGAPuxww/zxB+CPXVt1GD3UDdihbK7CvPccXNZQRZh61JjfyD+cwbCd5F+Mc1kN2LG xf0Nojgn0CZuYjWwO8u5+CdhMMJo+pPKb8t/wiz+a8IQjlHWkEiY+vbqkA1wv8mW3DAHQNlxUBQc IC0HQP8u8PvQJtM8w9sj1M/V38IszbqQZ+sgG4AtLfOwrvDeMa9gr2BDguBCMd/ghJTfLUD2gdgS yiJ7gWfOdFkg/njPQJNv3X/CH+Of5K9Hnv1agHI1wEtRN3Mb4SFBHICvG9L1MvshJWJpBkBvaRH/ PUSogH0w5YGOYpGX42/nf/9zDjXA7BH0QhOJWbTp8tnQ//VAzpIHQM+xaVFMYe6wHLL5NhNleLog 85EUse4f7y//vp+/pAvzTGHKIVCxDEDRj//Sn9OtGjGSIQ2gNBHlgOHB30rDDKAEsFqzaVFtqJBZ Nf/1j/af3p3ac1JjYJJpUs9w/4sBFEG4gY2QPgOFkArAE2D/6eENcByx7g8A3+WPBj8HT/9Hnr93 dsKoMdxQ63E18VnAPxRwz1ETYExgNWBDYHM6/wkfCi8IPw8fEC9HrXuQHIC/jlA01erBxpD9wfOy cPFy51NyNWG6IWR1/pBI8kvl/83Df+8SzxPf2PEQ4FlE+h//+y/TrCShPaKLxSTDmfB8Yf5umfB2 0REAz0LroQxnQ5Hf33UtoBkfGi9OvWku8FNQewLQjRFmfyB8kGkwS+ZW3ChuNHHzISeaK4yDYBH/ hKSMk+sSGP8kf8xv0HcYJ/9JM0rD3FDY8Mdi2nFioT2ifybjWqBgod91410drx6/V/9/cfIQPz8s H0Fe6nIiK0rD/z2iDmSD4rohPtA3QPFxDt//Np8Q/zJfM289/z8PQB9BL/9CP0NPRF9Fb0Z/R49I n9QGflOuoVORd3CF4PmS0Ghi/3VgjhHPhFdyYDDaIDufPK//Pb9KT0tfUk9TX1RvVX9Wj/9Xn1iv Wb9az1vfXO/UFbhA/w4id1FpgQ4iBYZP31DvUf//Xo9fn2U/Zk9nX2hvaX9qj/9rn2yvbb9uz2/f YNgVsYUA/+vw9FDZsP1gxmH+kDIvck/zNE+SM24niwF80PJw7HPB/iM0MGstN3pATlP/fyAN8P/P Y89k33W/ds99r/9+v3/PgN+B74L/hA+FH4Yv/4c/iE/UBqkBmbKpoBjDDEn9yiFmqJH/kuNPfC99 P4nP/4rfiQ+Sf5OPlJ+Vr5a/l8/fmN+Z75r/nA/T6FIv4f7CPzmBOgL1AarAqIA7cCBI5f4yc3lA ZWfYcHmA8ZD/FSLbAPGx7YAvNI0x68DHQP5kjy+QP5FPnd+e76cvqD//qU+qX6tvrH+tj66fr6+w v/+xz9QVx6nrAtsx8oC7Bc9A3yDz8vL0Yeph2pFm6tEOQf8xYd/g0JDyYWK/pb+mz7Nf/7RvvJ+9 r76/v8/A38Hvwv9fxA/FH8Yvxz/UBiryEHn+Kk6F4uG3EybwBPE5gYy1d48fuz+8TVntQPSB4lFu 39rw/2C2cf8Q/UNmHEGNAvsf1NogcRUw2iD9MP3i9EB+bxWwdY/Jvx7v29A7MWP7eNDi0CzN787/ N77TKzly98zh7HE6EmUhcDFxTf3UMf/ygk900ijYT9lfvFz0k9MP/zmBudBhbwWz7EbkYXRo399/ 4O+8XHUf1Q/WH/zT21Nz/3jQMYA1UC8lodAnEI2oonC/TvB0kfIw5KHR8gSGY3Tw/7xA5z/oT9pv Te7i4Nxj3k7/+TF5cd6C5EPkxO8BBFEDcP+6H/KPvD50b+qd+f/7DxHf//5fE//txqIAH8Hu4xwo IPCPjcC40ydCJ6YxLjAGkPs5cgYKMQBfAW//fKHguNL/tiqikLZQ7vAW0e3kIcH3MX3UEXV5IQZw FMDwkLjwZH06gG46cDHg6q/rv3esQfpmtrByB+8I/xs/5xC40i/u67f0DkYwUXq2cWhy746AepAo cg1jMw3yzc0Pr/8Qv+2gOLE4sBIfEy//fDFw/9Ey2AG3YDoxzMHR8k5h7uJ/JuLSsLhRthAfkRdy KpBk+fxwbC22IN8y/3COo7fw/6MgpBE1jx2P/204sQ5A5vH+ZbfwKfPuY7ZwDd24QHjCv+S0/LDk YTrhuMBOkWnUTt8k/yYPAE8sXy1tSCfxttJ/jWs7jy9fLW8y3zPvNPpGf0+guZAnsfgF/FD8sKFE b/1ikW0ZHxov1o65kAwQF0D7TmG2IGe3oCKACxIhUwWzb/igNb82zxQ9cirht6Byw/ywBgZWKG4p 3DJD0fYr94BAQSk5AyOA/KE+RP+4ktvgBaRD1T+/QM803ERS3DEpOp87r3esRwVjRCv/ttIp9fig I/G3kgZC9UGNbD/eYkcvSD803ESTH3FlcH8ZD0uPGy9OxvACT9QpkHK+a7lRNMEgMyEGYjFw1/Hv BPJVP1ZP1o1mUY9SnyZN1+4xKaPkYmPRsHBfUOWy7yBC9JK3ZNFQRYyxVRChYf9bB7bST2FbAHsv X680vtugf90xW29mz2ffNa9qj2udU//9ECOAt+E5IdF1o+PccrjSMEpBUicXQBUwdWfPa5AcQuaC /LBleGXBC7D31E9cj1c+U7Yg5WH5H22P+2udRUN0KZCMoeUwIVDSs7+kYB/kcdSMoKPwuOBlogD7 uBh7lW2h4PXRH5O50Hbf/3fvHq24wBUgjv9/T4Bfge/7gv+EDE/u+/SRZTPkxHNvC3R/tUxXFrF5 bmFt3wTB0UD8sLdmpFFmF+AjUx84oCfEhO+F/zfdKFAo40PSkrAgPSCSY0pRSn+/iq+1PY7QJyEo AY1San2i/aRgeoGD3zHRQCNE9TLm0L/4YO50j0+QX4QM8SFv94B/0rCXY9zDmTd79WIieiBl/4jh 9JJ6InuVBgXNz5q/g+//oR+iLwKNHDNiYgXQBKEXsP8M8Qrk3MOYURbguNJQp5Ov/5S/lc0gUSJg cgDMoNdxe6T+UKQPpR8mTdLhejGgdkPE//iiSiQyr69vox+qX6tvtc+Ptt+373YEBoAgVW7XkP5j GACSZfiTkxf3IdxBC4D/5OD3YEMSIoD9AlDR3TCg//+0b7V/uW+6f8JPw1/Eb3YE/jK8QK0indr8 4sbwb7HcMn8MEHwA91D0kfUg0tWfyHPhb+BNRDUg7qAXsL/v/8D/wg/F/8cPz5/Qr9G/0s//09/U 79X/1w/YH9kv2j919f9GEsyA+KL8UPSDzOIMYb7g/xax/FAMAOOwvkDMgFsQnXj/BaSTF80vzj/P T9vf3O/lL//mP+dP6F/pb+p/64/sn+2v7+6/78919b4zRr/f47/kz7/xX/Jv9v/4D/kfdgQzvEDb PZBkMHVF4fawd5kV4dz/y1L0f/WP9p/6j/uf+c8DX+sEb3X1NLxAQygBjfMLgPZ4YcDhg218IFjQ aREf0P8nIGkwFXGZJK4ivOVwo+AS/3Aw//8BDwIfBg8HHw9vEH//EY8SnxOvFL8VzxbfF+8Y//8a D3X1KUB8MctC/bPfEQul/73j3vP9pXCjCYj/rw2/Ds+/G18cbxqfJW8mf3XINbxA/lC8kSLgUIJk AFA1CzeWob968pfRmRMiLyM/JE1JfjG9JDBlQ1Ag5VB7YyJhl/D/TzCodKchjkm+UQvHvmBjoD+Z vy7/Qc69iokhVJBmLf0xUGmdAL5ALe82ryRPOo9/O5+mTzMBRnDKwszhQqBk/nZ8ID4BmVFRQn4w PHC+4a4t4FKodp/JauAQcz1v/z5/PIy835NifGBekJ9zv4D/nQBaQSwKb6FFQDxxH0Ofgv9x1ESv Rb88jHwEpzCfBrHW/97RcCBK8DFhQoTgQ4gZqUD/fhFwMWJhgXAxUUwvTT88jG88gOAQefKfkXON AI4BbXdaYL5AmOIip6LKAbICIv9wlHABUzU6X1SvPH9aT1tfv27LvmBwAXCwMWGdAWOIYH+fAMpg CWCJRIgbcMFlUmL74aG+UWS+0AogcFGNQ+CgvGR1cHBdL14/XExkqTDfeeBA8J7hvVGpQGSIgJbh /HF1vzFXcL5AQhWoVHZwfmSN4nMgvoC/zSjvKf9I+6kwMVFyb+NggmTfZe9VzX9TAWDYfND+MFl4 ymGfkSLyZkrwbC10cH3gWQBpCX9rT2xfi8xJEY4hezCfMGR/b09wX1xMaomWsm5yjYdkfW6zd0Gx Y2M1gJiBM4Rhv+EQp7Bj55mven9cLmJpMP5symGJUCDQjdHLIpmBLSGGZr6ArUA1MCwwheD/mDAx MWmSYIMyIAkBjNBnx38fMpeRvWCA74H/gw3h4Gv/n1S/MMtRCtCXEb/PiX9cL/eM/44PjxtI4JGW sjHsWXH9qFBls1+Q747/lN+V75b6/kGFYwlgg+RBQqejfzF+RP9gg6i9mWDfMKeAaaLLcFfAv0Jh g/KXv5jPltw5kHKx0X+Ur6BPls+i36PvRu+9IS3/STSEEbHVpb+mz6ffvcWpNf9hEEQhMiD+A7HV fbgxAL8A8FBERUKfD6sfrC8s4fupNDPnKGhgajCAZctwvjH/MSCksH3BCpBRSTUgWXGvmP8MQrDv sf+k3FlxZBAtITMS/zSPCpDiL7j/ug+lX76vv7//QDMJQUDGWXHBkIuwynJBoP+/8HyjLPGTRJ1H oq/B/8APv3YPdx/Jn8qvy7/zxDH9cP5Bu/M0ezRB4UKD5KJEahX/VxdKsCDGOWDHP8hPyV/NT//O X9bP19/Y79n/2w/cH90v394/30/gX+Fv87VyM/AKQP9DQdFlhiWM39Vf1m/i/+QPr+mf6q/rv/PE Mv1wTDWA3idKkSuyShJYkXXnwEnS7zMHNHpQoL1nJ+0f7i8dm/9H0FMAZABvP+g/6U/z//UP//mf +q/7v/zP/d/+7///AQ//Ah8DLwQ/HeZLg2EQV3GEsvxlKXXfBr8djGAhMsGAILNkMVCgRiiotTUg PfMv//ef+K8FPwpPC18RvxLPHW76M/AQVyDQEQBz8kPRQOD/MWYOSJMmV1SeYL1nUKCL8f8O7w// EQ8U/xYPHj8fTyBf/yFvIn8jjySfJa8mvyfPKN//5VWvFq5GZEGvn7Ci5y8cz38d3ypvK38yLzM/ NE/lZDT98BBUY4FgMH+SbrNhk4dQ9eXQcEEAaxk6SCu1wjkB/XWAcK5AQrEvzzDfMe813/827z9/ QI9Bn0KvQ79Ez0Xf/0bvR/9JD0of5VVRsHUgnkB3rkFrIDszcH2QDNK1kk28RDWbgmjgr2HwomZS sPdrIBtwgCBr8hLxQJMBuD//Pd8+70t/TI9Kv1XfVu9X//9ZD1ofWy9cP11PXl9fb+UZ/1DnCNFr ILZSVKCecXNxkwH9k6BzGHJkx6lThLM7QtPj/4vzUp9Tr1S/YU9iX2rPa9//bO9t/28PcB9xL3I/ c090Xx91b+VVUGJPApMBZXF1/5OgL79pX2pvdv94D30/fk/rf1/lZDXwEEnxr9D/0g//0xu1EHrf e+98/4Dvgf+Kf/+Lj4yfja+Ov4/PkN+R75L/f5QPlR/lVcYh5c/m0xiCZP519xBPERk707Dm8LUy vOH/iA+JH4ovlr+Xz5+voL+hz/+i36PvpP+mD6cfqC+pP6pP/+VVO4iFZYY0G3O1sfFwUID2b/FQ T1B3LbA6cJotGrHfu3DGsHrPnj+fTUktkVIQ/2UQOdE8gGThUnAtcRtw8KL8dXDFsy1gxdGF05np hdt+d4fvs9+fPjjwZWFlIVI+dS8ACa+sv+Tsw/JlZv8M0WfhDLC2V69pOaHTsfGR+zkiY/FnLbFS UE/Qn0C6X9+7b59cvdK6EofQYrDQZ+L3ZLAJILeweecdvv/AD8Efy8Ip5rQtw0MoZvFQOfBfxN/F 759cmbCwgC0uwHOvLsEbcDpAToAtmxFnLqD+bRqA0uFlUtMSGILTk4bD/mUacLETmeWwgM9P0F+f XA/O8tKACQE8AiBKYXb3m6DIKJugbVCwUlDJb8p//8uOGfHIIptACSE5AgkgUGF+c1FA8YHWn9ev n1zVxnf3xGHaZJ9AcNsyO1HIgeTiP9KwZLAacMlf3N8HvUhv/zmAr+bxFsgiUl/hf+KPZsP/2nOH k7EiLtGckmSwOfFlIe8agNuAPODS8WnwkIRh5MT/5dU8FOVk6w/sH59c8WY7Qv9l8VCxmbDZ4Jzw ULA58WbS32RALgHqBbJyUiF3xFEuwPe48TjRGfBr5k/nX8uOhqC+LPKf86/tL9pkZfBsyJD3LXKx ILDiYr2B08CZsN+DumLl8Wv9wOn28MJmmyD/T9Bl8BqAOSGZ8/0f/i//P79kMzmgyUA8cQGB8MJj UGD/hGAu0WUh2qLIAckBzqAYAPtnEHpgeE9wTrCy3wWvn083C18Mbw16TAQQ8AEga+0KgHdlEBAA ebDQUFEYwf9P8C5AeoDSoS1x5j0PDxAfPw4vFJ8Vrxa/F8/HG2Vn/TzQZPz/Go8Ynx0vHj8fS/pE EnJPT8AfQSA/IU8fWv5fJq8nvyiKI68kvx88mxGudt7wtwHwwS2cgHZRgf/24PDCHxDSsCmfKq8r vyzLVkBOoB8QcIYwLsRAZ88uby9/Hz/6CzxBUFBksBhmPSI0kOWAczovai8tYS4yeS8tolGQbq4v LiI1ME+gLyyeIjRp1zNAZECyoGQzQma4gtKwAHtIWVBFUkxJeE5LIDevOL85zzrWfRZ9PAGGAHLg QHRcY/hmMVzqQDUANZc97z7/f0APLTQ0hzR3NgBG7zX+OfIyNCAvQTRgMy80PzVP/0rvS/9ND04f Ty8mL1Q/VU//KV9Rj1KfMV8tn1bvV/9ZD/8x3zLvXE9dXzYfNy9D30Tv/zpfO288fz2PZX9mj0C/ Qc//Qt9rj2yfRg9IX3P/ST9KTydg32Hvdj8xNXixL0a4T05UeQl0j3mAXNMQfnJ86HoIeaB+IXoP eBY3FXdSUHeuMGQRL0RJRlZ8P4BfZzU4d2FCSE9EWXetMjd3YUgoVE1MeQB9h8AAHgA1EAEAAABN AAAAPDBCRUIzMjdGOEVFOEM2NENCOTI2MEQ2REE0MTMzRjE1MEFFQzhDOEVAZWhvc3QwMTAtMy5l eGNoMDEwLmludGVybWVkaWEubmV0PgAAAAAeADkQAQAAAN4AAAA8NzY2NTExMS4xNTc2MTE3NzY4 ODYxMjUwNC5KYXZhTWFpbC5yb290QHBlYW51dC5jb2NvbnV0LXBhbG0tc29mdHdhcmUuY29tPjww QkVCMzI3RjhFRThDNjRDQjkyNjBENkRBNDEzM0YxNTBBRUM4QzhBQGVob3N0MDEwLTMuZXhjaDAx MC5pbnRlcm1lZGlhLm5ldD4gPE9GMDQ2MzE2MkMuMjVEMUZCQTUtT044NTI1NzJDRi4wMDY3Njg1 QS04NTI1NzJDRi4wMDY3ODQ4OUBjYS5pYm0uY29tPgAAAB4ARxABAAAADwAAAG1lc3NhZ2UvcmZj ODIyAAALAPIQAQAAAB8A8xABAAAAsAAAAEEAVwAlADMAQQAgAEEAVwAlADMAQQAgAEEAVwAlADMA QQAgAFsAcAByAG8AdgBpAHMAaQBvAG4AaQBuAGcALQBkAGUAdgBdAEkAbQBwAHIAbwB2AGUAZAAJ AHUAcABkAGEAdABlAGcAZQBuAGUAcgBhAHQAaQBvAG4A//hkAGkAcwB0AHIAaQBiAHUAdABpAG8A bgBhAGwAZwBvAHIAaQB0AGgAbQAuAEUATQBMAAAACwD2EAAAAABAAAcw3Y3baj6NxwFAAAgw5BRn Fz+NxwEDAN4/r28AAAMA8T8HBAAAHgD4PwEAAAAOAAAAU3RlZmFuIExpZWJpZwAAAAIB+T8BAAAA ZQAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1PRVhDSDAxMC9PVT1GSVJTVCBBRE1J TklTVFJBVElWRSBHUk9VUC9DTj1SRUNJUElFTlRTL0NOPVNURUZBTi5MSUVCSUcAAAAAHgD6PwEA AAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkI ACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAA HgAwQAEAAAAOAAAAU1RFRkFOLkxJRUJJRwAAAB4AMUABAAAADgAAAFNURUZBTi5MSUVCSUcAAAAe ADJAAQAAACUAAABwcm92aXNpb25pbmctZGV2LWJvdW5jZXNAZWNsaXBzZS5vcmcAAAAAHgAzQAEA AAAcAAAAUGFzY2FsX1JhcGljYXVsdEBjYS5pYm0uY29tAB4AOEABAAAADgAAAFNURUZBTi5MSUVC SUcAAAAeADlAAQAAAAIAAAAuAAAAAwB2QP////8LACkAAAAAAAsAIwAAAAAAAwAGEAPETh4DAAcQ Py4AAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABQQVNDQUwsVEhFREVMVEFNRUNIQU5JU01J U0lOREVQRU5ERU5UT0ZUSEVUUkFOU1BPUlRMQVlFUkJVVFdFQ1VSUkVOVExZT05MWVVTRUhUVFAv U1NURUZBTlZPTjpQUk9WSVNJAAAAAAIBfwABAAAATQAAADwwQkVCMzI3RjhFRThDNjRDQjkyNjBE NkRBNDEzM0YxNTBBRUM4QzhFQGVob3N0MDEwLTMuZXhjaDAxMC5pbnRlcm1lZGlhLm5ldD4AAAAA ntM= ------_=_NextPart_001_01C78D3F.172B7A33-- From iAen8HlJMHUlNQ1M@JBqahwZgp0rLYuF/ Mon May 14 19:21:09 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mail.eclipse.org (Postfix) with SMTP id 9FCA4103196 for ; Mon, 14 May 2007 19:21:08 -0400 (EDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 May 2007 16:21:08 -0700 X-IronPort-AV: i="4.14,533,1170662400"; d="scan'208,217"; a="148936087:sNHT216321489" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4ENL87J001538 for ; Mon, 14 May 2007 16:21:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4ENL720014324 for ; Mon, 14 May 2007 23:21:08 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 16:21:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7967E.8CCA2389" Date: Mon, 14 May 2007 16:20:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Maya contribution available in CVS, getting started guide available Thread-Index: AceWfobukZ+gl8hWRkmo0FsntRwwmA== From: "Sharanya Doddapaneni \(shdoddap\)" To: X-OriginalArrivalTime: 14 May 2007 23:21:07.0802 (UTC) FILETIME=[8CF153A0:01C7967E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4146; t=1179184868; x=1180048868; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=iAen8HlJMHUlNQ1M@JBqahwZgp0rLYuF/; z=From:=20=22Sharanya=20Doddapaneni=20\(shdoddap\)=22=20 |Subject:=20Maya=20contribution=20available=20in=20CVS, =20getting=20start ed=20guide=20available |Sender:=20; bh=hyvtA+teNZsppdxKZFqw/jPYqV4uhNjGGK8EI4AQrpk=; b=xDbvoIXCzhPrOOpaBgRRTAs/ZHuK3XVuMcZYqh1gxIYXdkXg7q1l75nJ9dSvCbiBvgp4bTbU 3OA3hLM6/4QU87rJgujGRn20k+ZmF/1GEO2W0kOLOHuHKcLyzq0S4IGx; Authentication-Results: sj-dkim-2; header.From=iAen8HlJMHUlNQ1M@JBqahwZgp0rLYuF/; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [provisioning-dev] Maya contribution available in CVS, getting started guide available X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2007 23:21:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7967E.8CCA2389 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI: Cross posting from Newsgroup =20 Hello everyone!=20 Sorry for the lack of activity in the newsgroup as of late, we've been working furiously to have the contribution available in the Eclipse repository as well as wrapping up example plugins that allow Maya to be tried out without having to understand the internals. In addition, you will now see that the http://www.eclipse.org/maya site is up and functioning.=20 To try out Maya, follow the Getting Started link. We will continue to update the site with additional information including more details as to the function of each plugin. The architecture wiki page contains some details on the plugins though while finalizing the contribution we did end up changing some of the plugin names to better represent the given functions.=20 Maya's web site : http://www.eclipse.org/maya=20 Trying out Maya : http://wiki.eclipse.org/index.php/Trying_Out_Maya=20 Next week we will be setting up in EclipseZilla the larger known work activities that need to be performed on the contribution to further prepare it for consumption. In addition, we are planning to have another conference call within the next week or so to go over the contribution in more detail as well as engage some more on the actual work on the project.=20 Thanks for everyone's patience and support in achieving this milestone!=20 Tim =20 ------_=_NextPart_001_01C7967E.8CCA2389 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI: = Cross posting=20 from <eclipse.technology.maya> Newsgroup
 
Hello everyone! =

Sorry for the=20 lack of activity in the newsgroup as of late, we've been working = furiously to=20 have the contribution available in the Eclipse repository as well as = wrapping up=20 example plugins that allow Maya to be tried out without having to = understand the=20 internals.  In addition, you will now see that the http://www.eclipse.org/maya = site is up=20 and functioning.

To try out Maya, follow the Getting Started = link. =20 We will continue to update the site with additional information = including more=20 details as to the function of each plugin.  The architecture wiki = page=20 contains some details on the plugins though while finalizing the = contribution we=20 did end up changing some of the plugin names to better represent the = given=20 functions.

Maya's web site : http://www.eclipse.org/maya =
Trying=20 out Maya : http://wiki.ec= lipse.org/index.php/Trying_Out_Maya=20

Next week we will be setting up in EclipseZilla the larger known = work=20 activities that need to be performed on the contribution to further = prepare it=20 for consumption.  In addition, we are planning to have another = conference=20 call within the next week or so to go over the contribution in more = detail as=20 well as engage some more on the actual work on the project. =

Thanks for=20 everyone's patience and support in achieving this milestone!=20

Tim
 
------_=_NextPart_001_01C7967E.8CCA2389-- From dUEAFFLZ5y1/Kgkb@NWxUxqmKJBdCO6sQ Tue May 29 17:30:09 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by mail.eclipse.org (Postfix) with SMTP id DDCC1251F2 for ; Tue, 29 May 2007 17:29:48 -0400 (EDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l4TLTmbh019309 for ; Tue, 29 May 2007 17:29:48 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l4TLTlDg199024 for ; Tue, 29 May 2007 15:29:47 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l4TLTlAC028776 for ; Tue, 29 May 2007 15:29:47 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l4TLTktX028759 for ; Tue, 29 May 2007 15:29:46 -0600 To: X-Mailer: Lotus Notes Build V80_M5_05202007 May 20, 2007 Message-ID: From: Joseph Rusnak Date: Tue, 29 May 2007 17:29:43 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 05/29/2007 15:29:46 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF879DFE7F65B8f9e8a93df938690918c08BBF879DFE7F65B" Content-Disposition: inline Subject: [provisioning-dev] Trying out Maya... X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2007 21:30:09 -0000 --0__=08BBF879DFE7F65B8f9e8a93df938690918c08BBF879DFE7F65B Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I've been trying to "kick the tires" on Maya. I've successfully gotte= n through Steps 1-7, but am having problems with Step 8 ("Start the Maya = Web Server"). JUnit comes up and and quits in run 3 of 10 with the following behavior= : The test for org.eclipse.maya.server.example.setup.steps.CreateSchema s= eems to work OK. The test for org.eclipse.maya.server.example.setup.steps.CreateIcon "testCreateIcon" fails with the following trace: org.eclipse.maya.client.model.context.PersistException: Error persistin= g changes to [1] objects at org.eclipse.maya.client.model.internal.ModelContextImpl.persist(ModelCo= ntextImpl.java:255) at org.eclipse.maya.server.example.setup.steps.CreateIcon.testCreateIcon(C= reateIcon.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source= ) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JU= nit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.j= ava:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteT= estRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteT= estRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRu= nner.java:386) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(Remo= tePluginTestRunner.java:58) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTest= Application.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source= ) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethod(Eclipse= AppContainer.java:533) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.= java:155) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplica= tion(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ecli= pseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java= :363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java= :176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source= ) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:49= 7) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:436) at org.eclipse.equinox.launcher.Main.run(Main.java:1162) at org.eclipse.equinox.launcher.Main.main(Main.java:1137) Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at sun.net.NetworkClient.doConnect(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unkno= wn Source) at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Sou= rce) at org.eclipse.maya.client.core.MayaActionRequest.toWire(MayaActionRequest= .java:135) at org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:218) at org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:161) at org.eclipse.maya.client.core.MayaActionRequest.execute(MayaActionReques= t.java:68) at org.eclipse.maya.client.model.internal.ModelContextImpl.persist(ModelCo= ntextImpl.java:251) ... 40 more All subsequent tests in Run 3 fail too.... I don't have any errors, but I have over 500 warnings in my "Problems" = tab. Most of them seem to be pretty innocuous.... Is this par for the cour= se for the Maya prototype? Or am I doing something wrong? I am running S= un JDK 1.6 and Eclipse 3.3M7 Thanks, Joe Rusnak= --0__=08BBF879DFE7F65B8f9e8a93df938690918c08BBF879DFE7F65B Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I've been trying to "kick the tires" on Maya. I've succe= ssfully gotten through Steps 1-7, but am having problems with Step 8 (&= quot;Start the Maya Web Server").

JUnit comes up and and quits in run 3 of 10 with the following behavior= :

The test for org.eclipse.maya.server.example.setup.steps.CreateSchema s= eems to work OK.

The test for org.eclipse.maya.server.example.setup.steps.CreateIcon &qu= ot;testCreateIcon" fails with the following trace:

org.eclipse.maya.client.model.context.PersistException: Error persistin= g changes to [1] objects
at org.eclipse.maya.client.model.internal.ModelContextImpl.persist(Mod= elContextImpl.java:255)
at org.eclipse.maya.server.example.setup.steps.CreateIcon.testCreateIc= on(CreateIcon.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
= at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.ru= n(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecuti= on.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(Rem= oteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(Rem= oteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTe= stRunner.java:386)
at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(= RemotePluginTestRunner.java:58)
at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(Core= TestApplication.java:24)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
= at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethod(Ecl= ipseAppContainer.java:533)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHan= dle.java:155)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApp= lication(EclipseAppLauncher.java:106)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(= EclipseAppLauncher.java:76)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.= java:363)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.= java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
= at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:497) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:436)
at org.eclipse.equinox.launcher.Main.run(Main.java:1162)
at org.eclipse.equinox.launcher.Main.main(Main.java:1137)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknow= n Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown So= urce)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)=
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown= Source)
at org.eclipse.maya.client.core.MayaActionRequest.toWire(MayaActionReq= uest.java:135)
at org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:218= )
at org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:161= )
at org.eclipse.maya.client.core.MayaActionRequest.execute(MayaActionRe= quest.java:68)
at org.eclipse.maya.client.model.internal.ModelContextImpl.persist(Mod= elContextImpl.java:251)
... 40 more

All subsequent tests in Run 3 fail too....

I don't have any errors, but I have over 500 warnings in my "Probl= ems" tab. Most of them seem to be pretty innocuous.... Is this= par for the course for the Maya prototype? Or am I doing something wr= ong? I am running Sun JDK 1.6 and Eclipse 3.3M7

Thanks,

Joe Rusnak
= --0__=08BBF879DFE7F65B8f9e8a93df938690918c08BBF879DFE7F65B-- From jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/ Wed May 30 11:12:04 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mail.eclipse.org (Postfix) with SMTP id 43A9125222 for ; Wed, 30 May 2007 11:11:41 -0400 (EDT) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 May 2007 11:11:42 -0400 X-IronPort-AV: i="4.14,594,1170651600"; d="scan'208,217"; a="122351375:sNHT268481832" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4UFBfaY032065 for ; Wed, 30 May 2007 11:11:41 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4UFBS63019842 for ; Wed, 30 May 2007 15:11:41 GMT Received: from xmb-rtp-209.amer.cisco.com ([64.102.31.11]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 11:11:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A2CC.D07AC32F" Subject: RE: [provisioning-dev] Trying out Maya... Date: Wed, 30 May 2007 11:11:25 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] Trying out Maya... Thread-Index: AceiOIwfOTCLr9AbTzCk1ZbXQ1OQ1AAk7tMg References: From: "Tim Webb \(tiwebb\)" To: "Developer discussions for provisioning \(Update Manager\)initiatives" X-OriginalArrivalTime: 30 May 2007 15:11:35.0900 (UTC) FILETIME=[D088C1C0:01C7A2CC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16896; t=1180537901; x=1181401901; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/; z=From:=20=22Tim=20Webb=20\(tiwebb\)=22=20 |Subject:=20RE=3A=20[provisioning-dev]=20Trying=20out=20Maya... |Sender:=20 |To:=20=22Developer=20discussions=20for=20provisioning=20\(Update=20Manag er\)initiatives=22=20; bh=0u7j1sDlY6wefWud5ml03RXonP8TQOAePD6Zgw4pLS4=; b=SpS+SQQZ+d1/hFCpFgm3U3ncyHe3Uat20ol2YVXIfqcNUaSadD8ceBWglhIaVaGkMMPwdJOp MKqmCFuIvYmx6j98gRTDRp5gRSaGc2rRLkq+va0Th5ARrBZ3zqLkYnCV; Authentication-Results: rtp-dkim-2; header.From=jAgQBfbvOUZbWjps@JBqahwZgp0rLYuF/; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2007 15:12:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A2CC.D07AC32F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joseph, =20 I'm not sure what would be impacting your ability to run. In step 8, the first two steps connect directly to the Derby Server and then the third uses Hibernate once the initial schema is created by the first two steps. I was able to reproduce from scratch successfully provisioning the server. My only thought is that the JDBC connect string from Hibernate differs from the one we are using in the first two test cases. =20 Will continue to investigate to see what might be causing this. Has anyone else run into similar issues? =20 Tim =20 ________________________________ From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of Joseph Rusnak Sent: Tuesday, May 29, 2007 2:30 PM To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Subject: [provisioning-dev] Trying out Maya... =20 I've been trying to "kick the tires" on Maya. I've successfully gotten through Steps 1-7, but am having problems with Step 8 ("Start the Maya Web Server"). JUnit comes up and and quits in run 3 of 10 with the following behavior: The test for org.eclipse.maya.server.example.setup.steps.CreateSchema seems to work OK. The test for org.eclipse.maya.server.example.setup.steps.CreateIcon "testCreateIcon" fails with the following trace: org.eclipse.maya.client.model.context.PersistException: Error persisting changes to [1] objects at org.eclipse.maya.client.model.internal.ModelContextImpl.persist(ModelCon textImpl.java:255) at org.eclipse.maya.server.example.setup.steps.CreateIcon.testCreateIcon(Cr eateIcon.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUn it3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.ja va:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe stRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe stRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRun ner.java:386) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(Remot ePluginTestRunner.java:58) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestA pplication.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethod(EclipseA ppContainer.java:533) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.j ava:155) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplicat ion(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Eclip seAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java: 363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java: 176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:497) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:436) at org.eclipse.equinox.launcher.Main.run(Main.java:1162) at org.eclipse.equinox.launcher.Main.main(Main.java:1137) Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at sun.net.NetworkClient.doConnect(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at org.eclipse.maya.client.core.MayaActionRequest.toWire(MayaActionRequest. java:135) at org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:218) at org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:161) at org.eclipse.maya.client.core.MayaActionRequest.execute(MayaActionRequest .java:68) at org.eclipse.maya.client.model.internal.ModelContextImpl.persist(ModelCon textImpl.java:251) ... 40 more All subsequent tests in Run 3 fail too.... I don't have any errors, but I have over 500 warnings in my "Problems" tab. Most of them seem to be pretty innocuous.... Is this par for the course for the Maya prototype? Or am I doing something wrong? I am running Sun JDK 1.6 and Eclipse 3.3M7 Thanks, Joe Rusnak ------_=_NextPart_001_01C7A2CC.D07AC32F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joseph,

=

 

I’m not sure what would be = impacting your ability to run.  In step 8, the first two steps connect = directly to the Derby Server and then the third uses Hibernate once the initial schema = is created by the first two steps.  I was able to reproduce from = scratch successfully provisioning the server.  My only thought is that the = JDBC connect string from Hibernate differs from the one we are using in the first two = test cases.

 

Will continue to investigate to see = what might be causing this.  Has anyone else run into similar = issues?

 

Tim

 


From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of Joseph Rusnak
Sent: Tuesday, May 29, = 2007 2:30 PM
To: = bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Subject: = [provisioning-dev] Trying out Maya...

 

I've been trying to "kick the tires" on Maya. I've successfully gotten = through Steps 1-7, but am having problems with Step 8 ("Start the Maya Web Server").

JUnit comes up and and quits in run 3 of 10 with the following = behavior:

The test for org.eclipse.maya.server.example.setup.steps.CreateSchema = seems to work OK.

The test for org.eclipse.maya.server.example.setup.steps.CreateIcon "testCreateIcon" fails with the following trace:

org.eclipse.maya.client.model.context.PersistException: Error persisting changes to [1] objects
at = org.eclipse.maya.client.model.internal.ModelContextImpl.persist(ModelCont= extImpl.java:255)
at org.eclipse.maya.server.example.setup.steps.CreateIcon.testCreateIcon(Cre= ateIcon.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at = org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUni= t3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.jav= a:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTes= tRunner.java:460)
at = org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTes= tRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunn= er.java:386)
at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(Remote= PluginTestRunner.java:58)
at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestAp= plication.java:24)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethod(EclipseAp= pContainer.java:533)
at = org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.ja= va:155)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplicati= on(EclipseAppLauncher.java:106)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Eclips= eAppLauncher.java:76)
at = org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:3= 63)
at = org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:1= 76)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:497)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:436)
at org.eclipse.equinox.launcher.Main.run(Main.java:1162)
at org.eclipse.equinox.launcher.Main.main(Main.java:1137)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown = Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown = Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown = Source)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown = Source)
at org.eclipse.maya.client.core.MayaActionRequest.toWire(MayaActionRequest.j= ava:135)
at = org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:218)
at = org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:161)
at org.eclipse.maya.client.core.MayaActionRequest.execute(MayaActionRequest.= java:68)
at org.eclipse.maya.client.model.internal.ModelContextImpl.persist(ModelCont= extImpl.java:251)
... 40 more

All subsequent tests in Run 3 fail too....

I don't have any errors, but I have over 500 warnings in my "Problems" tab. Most of them seem to be pretty innocuous.... = Is this par for the course for the Maya prototype? Or am I doing something = wrong? I am running Sun JDK 1.6 and Eclipse 3.3M7

Thanks,

Joe Rusnak

------_=_NextPart_001_01C7A2CC.D07AC32F-- From iAen8HlJMHUlNQ1M@JBqahwZgp0rLYuF/ Thu May 31 19:18:13 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mail.eclipse.org (Postfix) with SMTP id 8A3CB25D1A for ; Thu, 31 May 2007 19:17:51 -0400 (EDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 May 2007 16:17:52 -0700 X-IronPort-AV: i="4.16,371,1175497200"; d="scan'208,217"; a="157201484:sNHT124178868" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4VNHqDM014356; Thu, 31 May 2007 16:17:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4VNHctp025275; Thu, 31 May 2007 23:17:51 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 16:17:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A3D9.E42C5701" Subject: RE: [provisioning-dev] Trying out Maya... Date: Thu, 31 May 2007 16:17:30 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] Trying out Maya... Thread-Index: AceiOIwfOTCLr9AbTzCk1ZbXQ1OQ1AAk7tMgAEMVmuA= References: From: "Sharanya Doddapaneni \(shdoddap\)" To: "Developer discussions for provisioning \(Update Manager\)initiatives" , "Joseph Rusnak" X-OriginalArrivalTime: 31 May 2007 23:17:43.0749 (UTC) FILETIME=[E4570F50:01C7A3D9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=19597; t=1180653472; x=1181517472; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=iAen8HlJMHUlNQ1M@JBqahwZgp0rLYuF/; z=From:=20=22Sharanya=20Doddapaneni=20\(shdoddap\)=22=20 |Subject:=20RE=3A=20[provisioning-dev]=20Trying=20out=20Maya... |Sender:=20; bh=oX6Y/mBQrEOMjFaYHKP4+jxmRDSNf5GYRy4fSFj+fw0=; b=mL9yYsCDpdpJaPASKFNhchr+2SgaPv1VTaa5D9Jl+t5x8S6DVkdD4FW6LpDRtH7Fgoy7QAWM QdkNQ1TWRsfg4Sw0rfJkgcUVjpbwzYY75rncFf1kv4jM+4R3kRNYUNw3fOrIsmRHGf2Y+QCd6S Ka5wuc63mzvUvqsjccbYcQ1fg=; Authentication-Results: sj-dkim-1; header.From=iAen8HlJMHUlNQ1M@JBqahwZgp0rLYuF/; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2007 23:18:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A3D9.E42C5701 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Joseph, Looking at the stack trace, it looks like you might not have a database connection established. Please verify that you have the Derby server running and make sure that nothing is blocking your server process from connecting to the database. Also to add, there were couple of bug fixes added to the plug-ins, so please try updating your projects and then try the steps again. =20 Thanks, Sharanya ________________________________ From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of Tim Webb (tiwebb) Sent: Wednesday, May 30, 2007 8:11 AM To: Developer discussions for provisioning (Update Manager)initiatives Subject: RE: [provisioning-dev] Trying out Maya... Joseph, =20 I'm not sure what would be impacting your ability to run. In step 8, the first two steps connect directly to the Derby Server and then the third uses Hibernate once the initial schema is created by the first two steps. I was able to reproduce from scratch successfully provisioning the server. My only thought is that the JDBC connect string from Hibernate differs from the one we are using in the first two test cases. =20 Will continue to investigate to see what might be causing this. Has anyone else run into similar issues? =20 Tim =20 ________________________________ From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of Joseph Rusnak Sent: Tuesday, May 29, 2007 2:30 PM To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Subject: [provisioning-dev] Trying out Maya... =20 I've been trying to "kick the tires" on Maya. I've successfully gotten through Steps 1-7, but am having problems with Step 8 ("Start the Maya Web Server"). JUnit comes up and and quits in run 3 of 10 with the following behavior: The test for org.eclipse.maya.server.example.setup.steps.CreateSchema seems to work OK. The test for org.eclipse.maya.server.example.setup.steps.CreateIcon "testCreateIcon" fails with the following trace: org.eclipse.maya.client.model.context.PersistException: Error persisting changes to [1] objects at org.eclipse.maya.client.model.internal.ModelContextImpl.persist(ModelCon textImpl.java:255) at org.eclipse.maya.server.example.setup.steps.CreateIcon.testCreateIcon(Cr eateIcon.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUn it3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.ja va:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe stRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe stRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRun ner.java:386) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(Remot ePluginTestRunner.java:58) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestA pplication.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethod(EclipseA ppContainer.java:533) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.j ava:155) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplicat ion(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Eclip seAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java: 363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java: 176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:497) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:436) at org.eclipse.equinox.launcher.Main.run(Main.java:1162) at org.eclipse.equinox.launcher.Main.main(Main.java:1137) Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at sun.net.NetworkClient.doConnect(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at org.eclipse.maya.client.core.MayaActionRequest.toWire(MayaActionRequest. java:135) at org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:218) at org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:161) at org.eclipse.maya.client.core.MayaActionRequest.execute(MayaActionRequest .java:68) at org.eclipse.maya.client.model.internal.ModelContextImpl.persist(ModelCon textImpl.java:251) ... 40 more All subsequent tests in Run 3 fail too.... I don't have any errors, but I have over 500 warnings in my "Problems" tab. Most of them seem to be pretty innocuous.... Is this par for the course for the Maya prototype? Or am I doing something wrong? I am running Sun JDK 1.6 and Eclipse 3.3M7 Thanks, Joe Rusnak ------_=_NextPart_001_01C7A3D9.E42C5701 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Joseph,
Looking at the stack trace, it looks like=20 you might not have a database connection established. Please = verify=20 that you have the Derby server running and make sure that nothing is = blocking=20 your server process from connecting to the database. Also to add, there=20 were couple of bug fixes added to the plug-ins, so please try = updating your=20 projects and then try the steps again.
 
Thanks,
Sharanya


From: = fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg=20 [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of Tim = Webb=20 (tiwebb)
Sent: Wednesday, May 30, 2007 8:11 AM
To: = Developer=20 discussions for provisioning (Update = Manager)initiatives
Subject: RE:=20 [provisioning-dev] Trying out Maya...

Joseph,

 

I’m not = sure what would=20 be impacting your ability to run.  In step 8, the first two steps = connect=20 directly to the Derby Server and then the third uses Hibernate once the = initial=20 schema is created by the first two steps.  I was able to reproduce = from=20 scratch successfully provisioning the server.  My only thought is = that the=20 JDBC connect string from Hibernate differs from the one we are using in = the=20 first two test cases.

 

Will continue = to=20 investigate to see what might be causing this.  Has anyone else run = into=20 similar issues?

 

Tim

 


From:=20 fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg=20 [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of Joseph = Rusnak
Sent: Tuesday, May 29, 2007 2:30=20 PM
To:=20 bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
Subject: [provisioning-dev] = Trying out=20 Maya...

 

I've been=20 trying to "kick the tires" on Maya. I've successfully gotten through = Steps 1-7,=20 but am having problems with Step 8 ("Start the Maya Web = Server").

JUnit=20 comes up and and quits in run 3 of 10 with the following = behavior:

The=20 test for org.eclipse.maya.server.example.setup.steps.CreateSchema seems = to work=20 OK.

The test for = org.eclipse.maya.server.example.setup.steps.CreateIcon=20 "testCreateIcon" fails with the following=20 trace:

org.eclipse.maya.client.model.context.PersistException: = Error=20 persisting changes to [1] objects
at=20 org.eclipse.maya.client.model.internal.ModelContextImpl.persist(ModelCont= extImpl.java:255)
at=20 org.eclipse.maya.server.example.setup.steps.CreateIcon.testCreateIcon(Cre= ateIcon.java:72)
at=20 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at=20 sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at=20 sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at=20 java.lang.reflect.Method.invoke(Unknown Source)
at=20 junit.framework.TestCase.runTest(TestCase.java:164)
at=20 junit.framework.TestCase.runBare(TestCase.java:130)
at=20 junit.framework.TestResult$1.protect(TestResult.java:106)
at=20 junit.framework.TestResult.runProtected(TestResult.java:124)
at=20 junit.framework.TestResult.run(TestResult.java:109)
at=20 junit.framework.TestCase.run(TestCase.java:120)
at=20 junit.framework.TestSuite.runTest(TestSuite.java:230)
at=20 junit.framework.TestSuite.run(TestSuite.java:225)
at=20 junit.framework.TestSuite.runTest(TestSuite.java:230)
at=20 junit.framework.TestSuite.run(TestSuite.java:225)
at=20 org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUni= t3TestReference.java:130)
at=20 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.jav= a:38)
at=20 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTes= tRunner.java:460)
at=20 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTes= tRunner.java:673)
at=20 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunn= er.java:386)
at=20 org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(Remote= PluginTestRunner.java:58)
at=20 org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestAp= plication.java:24)
at=20 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at=20 sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at=20 sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at=20 java.lang.reflect.Method.invoke(Unknown Source)
at=20 org.eclipse.equinox.internal.app.EclipseAppContainer.callMethod(EclipseAp= pContainer.java:533)
at=20 org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.ja= va:155)
at=20 org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplicati= on(EclipseAppLauncher.java:106)
at=20 org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Eclips= eAppLauncher.java:76)
at=20 org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:3= 63)
at=20 org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:1= 76)
at=20 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at=20 sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at=20 sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at=20 java.lang.reflect.Method.invoke(Unknown Source)
at=20 org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:497)
at=20 org.eclipse.equinox.launcher.Main.basicRun(Main.java:436)
at=20 org.eclipse.equinox.launcher.Main.run(Main.java:1162)
at=20 org.eclipse.equinox.launcher.Main.main(Main.java:1137)
Caused by:=20 java.net.ConnectException: Connection refused: connect
at=20 java.net.PlainSocketImpl.socketConnect(Native Method)
at=20 java.net.PlainSocketImpl.doConnect(Unknown Source)
at=20 java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at=20 java.net.PlainSocketImpl.connect(Unknown Source)
at=20 java.net.Socket.connect(Unknown Source)
at = java.net.Socket.connect(Unknown=20 Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at=20 sun.net.www.http.HttpClient.openServer(Unknown Source)
at=20 sun.net.www.http.HttpClient.openServer(Unknown Source)
at=20 sun.net.www.http.HttpClient.<init>(Unknown Source)
at=20 sun.net.www.http.HttpClient.New(Unknown Source)
at=20 sun.net.www.http.HttpClient.New(Unknown Source)
at=20 sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown=20 Source)
at = sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown=20 Source)
at = sun.net.www.protocol.http.HttpURLConnection.connect(Unknown=20 Source)
at=20 sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown=20 Source)
at=20 org.eclipse.maya.client.core.MayaActionRequest.toWire(MayaActionRequest.j= ava:135)
at=20 org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:218)
a= t=20 org.eclipse.maya.client.core.MayaClient.execute(MayaClient.java:161)
a= t=20 org.eclipse.maya.client.core.MayaActionRequest.execute(MayaActionRequest.= java:68)
at=20 org.eclipse.maya.client.model.internal.ModelContextImpl.persist(ModelCont= extImpl.java:251)
...=20 40 more

All subsequent tests in Run 3 fail too....

I don't = have=20 any errors, but I have over 500 warnings in my "Problems" tab. Most of = them seem=20 to be pretty innocuous.... Is this par for the course for the Maya = prototype? Or=20 am I doing something wrong? I am running Sun JDK 1.6 and Eclipse=20 3.3M7

Thanks,

Joe=20 Rusnak

------_=_NextPart_001_01C7A3D9.E42C5701-- From Jeff_TTczmgW07z/8fKPW@YHvLZjvCTR1Igv9U Thu Jun 28 10:05:16 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by mail.eclipse.org (Postfix) with SMTP id 4298122D0E; Thu, 28 Jun 2007 10:05:13 -0400 (EDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5SE4duL010116; Thu, 28 Jun 2007 10:04:39 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5SE4dse295188; Thu, 28 Jun 2007 10:04:39 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5SE4dtK028057; Thu, 28 Jun 2007 10:04:39 -0400 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5SE4dOA028047; Thu, 28 Jun 2007 10:04:39 -0400 To: Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg, bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Jeff McAffer Message-ID: Date: Thu, 28 Jun 2007 10:04:36 -0400 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 06/28/2007 10:04:39, Serialize complete at 06/28/2007 10:04:39 Content-Type: multipart/alternative; boundary="=_alternative 004D54DA85257308_=" Cc: Subject: [provisioning-dev] Equinox Summit X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2007 14:05:16 -0000 This is a multipart message in MIME format. --=_alternative 004D54DA85257308_= Content-Type: text/plain; charset="US-ASCII" The Eclipse Foundation and the Equinox team are happy to announce that we are going to run an "Equinox Summit" Sept 25 and 26 in Ottawa. This follows in the mold of the wildly successful CDT Summits and promises to be a quality opportunity for Equinox committers and contributors to get together and make concrete progress on various technical topics. Check out the Equinox Wiki for more information. http://wiki.eclipse.org/Equinox_Summit_2007 See you there! Jeff --=_alternative 004D54DA85257308_= Content-Type: text/html; charset="US-ASCII"
The Eclipse Foundation and the Equinox team are happy to announce that we are going to run an "Equinox Summit" Sept 25 and 26 in Ottawa.  This follows in the mold of the wildly successful CDT Summits and promises to be a quality opportunity for Equinox committers and contributors to get together and make concrete progress on various technical topics.  

Check out the Equinox Wiki for more information.
        http://wiki.eclipse.org/Equinox_Summit_2007

See you there!
Jeff
--=_alternative 004D54DA85257308_=-- From RJLa1gAKTeLBAdDY@NWxUxqmKJBdCO6sQ Thu Jun 28 18:05:50 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by mail.eclipse.org (Postfix) with SMTP id E139B31FA2 for ; Thu, 28 Jun 2007 18:05:49 -0400 (EDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5SM5Ep6029455 for ; Thu, 28 Jun 2007 18:05:14 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5SM5DAF263556 for ; Thu, 28 Jun 2007 16:05:13 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5SM5Du3031724 for ; Thu, 28 Jun 2007 16:05:13 -0600 Received: from d03mc019.boulder.ibm.com (d03mc019.boulder.ibm.com [9.17.195.203]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5SM5DqB031710 for ; Thu, 28 Jun 2007 16:05:13 -0600 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: James D Miles Date: Thu, 28 Jun 2007 17:06:00 -0500 X-MIMETrack: Serialize by Router on D03MC019/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 06/28/2007 16:05:12 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=09BBF99BDFEAA6C08f9e8a93df938690918c09BBF99BDFEAA6C0" Content-Disposition: inline Subject: [provisioning-dev] equinox.prov path is too long X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2007 22:05:50 -0000 --0__=09BBF99BDFEAA6C08f9e8a93df938690918c09BBF99BDFEAA6C0 Content-type: text/plain; charset=US-ASCII I tried to remove the directory tree in \tmp\equinox.prov and discovered that it is not easy to do. Its path length is greater than 255 characters. Is this a mistake or are we supporting this large path length? --0__=09BBF99BDFEAA6C08f9e8a93df938690918c09BBF99BDFEAA6C0 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I tried to remove the directory tree in \tmp\equinox.prov and discovered that it is not easy to do. Its path length is greater than 255 characters. Is this a mistake or are we supporting this large path length? --0__=09BBF99BDFEAA6C08f9e8a93df938690918c09BBF99BDFEAA6C0-- From YgyQFOCWM9g4uOl/@QdoDIVO2IbNTSwBe Tue Jul 3 22:48:26 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by mail.eclipse.org (Postfix) with SMTP id 02FA410D62F for ; Tue, 3 Jul 2007 22:48:25 -0400 (EDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l642ld5E022065 for ; Tue, 3 Jul 2007 19:47:39 -0700 (PDT) Received: from ism-mail03.corp.ad.wrs.com ([128.224.200.20]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 19:47:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jul 2007 04:47:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What is the status on the provisioning projects? Thread-Index: Ace95aw5fyyYqc5xRmqPvxPFvUFsBQ== From: "Scharf, Michael" To: "Developer discussions for provisioning \(Update Manager\)initiatives" X-OriginalArrivalTime: 04 Jul 2007 02:47:39.0326 (UTC) FILETIME=[AF8555E0:01C7BDE5] Cc: Subject: [provisioning-dev] What is the status on the provisioning projects? X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2007 02:48:26 -0000 Hi, what's the best way to get an overview of the current status and the future plans of the provisioning effort? Is there a central place with the information? Is there anything better than (and the Provisioning category)? http://wiki.eclipse.org/Provisioning Or do I have to come to the Summit in September? I also tried this search: http://tinyurl.com/yvt652 Michael --=20 Michael Scharf, Wind River direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805 From Pascal_nZARQQd5G+POZmzf@YHvLZjvCTR1Igv9U Wed Jul 4 10:17:03 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by mail.eclipse.org (Postfix) with SMTP id AE89E26B14; Wed, 4 Jul 2007 10:17:01 -0400 (EDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l64EGGXO017725; Wed, 4 Jul 2007 10:16:16 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l64EGFGn525296; Wed, 4 Jul 2007 10:16:15 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l64EGF02001447; Wed, 4 Jul 2007 10:16:15 -0400 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l64EGFR2001433; Wed, 4 Jul 2007 10:16:15 -0400 In-Reply-To: References: Subject: Re: [provisioning-dev] What is the status on the provisioning projects? To: "Developer discussions for provisioning \(Update Manager\) initiatives" Cc: "Developer discussions for provisioning \(Update Manager\)initiatives" , fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg X-Mailer: Lotus Notes Build V80_M4_03042007NP March 04, 2007 Message-ID: From: Pascal Rapicault Date: Wed, 4 Jul 2007 10:12:57 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 07/04/2007 10:16:15 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2007 14:17:04 -0000 Hi Michael, There is no overall/cross-project plan for the provisioning effort and since each project is independent addressing different part of the provisioning space, it seems to me that the only "cross project plan" we need to have is something that plan discussion, collaboration and then adoption of the new concepts and metadata being defined in the equinox. As you may have already found, the equinox provisioning plan is available here (http://wiki.eclipse.org/Equinox_Provisioning_Plan). For 3.4 and with the current involvement, our goals will be to replace update manager. Given the context of the summit, the discussion will likely focus on the equinox part of the provisioning. Which area of the provisioning work are you interested in? HTH, PaScaL "Scharf, Michael" To Sent by: "Developer discussions for provisioning-dev- provisioning \(Update B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM Manager\)initiatives" rg cc 07/03/2007 10:47 Subject PM [provisioning-dev] What is the status on the provisioning projects? Please respond to "Developer discussions for provisioning \(Update Manager\) initiatives" Hi, what's the best way to get an overview of the current status and the future plans of the provisioning effort? Is there a central place with the information? Is there anything better than (and the Provisioning category)? http://wiki.eclipse.org/Provisioning Or do I have to come to the Summit in September? I also tried this search: http://tinyurl.com/yvt652 Michael -- Michael Scharf, Wind River direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805 _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev From YgyQFOCWM9g4uOl/@QdoDIVO2IbNTSwBe Wed Jul 4 16:07:35 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by mail.eclipse.org (Postfix) with SMTP id 26DBD27357 for ; Wed, 4 Jul 2007 16:07:34 -0400 (EDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l64K6mgx017445 for ; Wed, 4 Jul 2007 13:06:48 -0700 (PDT) Received: from ism-mail03.corp.ad.wrs.com ([128.224.200.20]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 13:06:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [provisioning-dev] What is the status on the provisioningprojects? Date: Wed, 4 Jul 2007 22:06:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] What is the status on the provisioningprojects? Thread-Index: Ace+ReryL6gub9zaR3SlqJV83P6FrAALXiHQ References: From: "Scharf, Michael" To: "Developer discussions for provisioning \(Update Manager\)initiatives" X-OriginalArrivalTime: 04 Jul 2007 20:06:47.0589 (UTC) FILETIME=[D9FB4550:01C7BE76] Cc: X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2007 20:07:35 -0000 Hi Pascal, I have a general interest in provisioning. We have quite some (customer and internal) requests for enhancements of installations.=20 For example: - being able to roll out an installation to the desk of many developers (probably covered by Maya) - updating an installation of many developes in a coordinated way (Maya) - pushing preference settings to developers without overriding their settings (is centralized preference management covered=20 by any of the provisioning projects?) - disallow users to update installed feaures using the update=20 managers - revert a customized installation back to the officially supported version(s) - install non osgi based features - ... Michael --=20 Michael Scharf, Wind River direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805=20 > -----Original Message----- > From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg=20 > [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of=20 > Pascal Rapicault > Sent: Wednesday, 04 July, 2007 16:13 > To: Developer discussions for provisioning (Update Manager)=20 > initiatives > Cc: Developer discussions for provisioning (Update=20 > Manager)initiatives; fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg > Subject: Re: [provisioning-dev] What is the status on the=20 > provisioningprojects? >=20 > Hi Michael, >=20 > There is no overall/cross-project plan for the provisioning effort and > since each project is independent addressing different part of the > provisioning space, it seems to me that the only "cross=20 > project plan" we > need to have is something that plan discussion, collaboration and then > adoption of the new concepts and metadata being defined in=20 > the equinox. >=20 > As you may have already found, the equinox provisioning plan=20 > is available > here (http://wiki.eclipse.org/Equinox_Provisioning_Plan). For=20 > 3.4 and with > the current involvement, our goals will be to replace update manager. >=20 > Given the context of the summit, the discussion will likely=20 > focus on the > equinox part of the provisioning. >=20 > Which area of the provisioning work are you interested in? >=20 > HTH, >=20 > PaScaL >=20 >=20 >=20 > =20 > =20 > "Scharf, Michael" =20 > =20 > =20 > indriver.com> =20 > To=20 > Sent by: "Developer discussions=20 > for =20 > provisioning-dev- provisioning \(Update =20 > =20 > B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM Manager\)initiatives" =20 > =20 > rg =20 > =20 > =20 > cc=20 > =20 > =20 > 07/03/2007 10:47 =20 > Subject=20 > PM [provisioning-dev]=20 > What is the =20 > status on the=20 > provisioning =20 > projects? =20 > =20 > Please respond to =20 > =20 > "Developer =20 > =20 > discussions for =20 > =20 > provisioning =20 > =20 > \(Update =20 > =20 > Manager\) =20 > =20 > initiatives" =20 > =20 > =20 > @eclipse.org> =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 > Hi, >=20 > what's the best way to get an overview of the current status > and the future plans of the provisioning effort? >=20 > Is there a central place with the information? >=20 > Is there anything better than (and the Provisioning category)? > http://wiki.eclipse.org/Provisioning >=20 > Or do I have to come to the Summit in September? >=20 > I also tried this search: http://tinyurl.com/yvt652 >=20 > Michael > -- > Michael Scharf, Wind River > direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805 > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev >=20 >=20 > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev >=20 From John_EljLatxtsXDP9738@YHvLZjvCTR1Igv9U Wed Jul 4 16:38:15 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by mail.eclipse.org (Postfix) with SMTP id 9DB3027361 for ; Wed, 4 Jul 2007 16:38:14 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l64JXtcx013887 for ; Wed, 4 Jul 2007 15:33:55 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l64KbQgs549822 for ; Wed, 4 Jul 2007 16:37:26 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l64KbQft021065 for ; Wed, 4 Jul 2007 16:37:26 -0400 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l64KbPK0021058 for ; Wed, 4 Jul 2007 16:37:26 -0400 In-Reply-To: To: "Developer discussions for provisioning \(Update Manager\) initiatives" Subject: RE: [provisioning-dev] What is the status on the provisioningprojects? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: John Arthorne Message-ID: Date: Wed, 4 Jul 2007 16:37:25 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 07/04/2007 16:37:25, Serialize complete at 07/04/2007 16:37:25 Content-Type: multipart/alternative; boundary="=_alternative 00714A868525730E_=" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2007 20:38:16 -0000 This is a multipart message in MIME format. --=_alternative 00714A868525730E_= Content-Type: text/plain; charset="US-ASCII" At least the last three items on your list are of interest in the equinox provisioning work. I believe the Buckminster project is interested in touching on provisioning of workspaces and preferences. It sounds like you want to keep track of the work in at least Maya, Buckminster, and Equinox provisioning. A useful link for more info on the wiki: http://wiki.eclipse.org/Category:Provisioning Also, discussion on the equinox provisioning is happening in the equinox-dev mailing list. You may want to browse the archive and/or subscribe to keep out to date. John "Scharf, Michael" Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg 07/04/2007 04:06 PM Please respond to "Developer discussions for provisioning \(Update Manager\) initiatives" To "Developer discussions for provisioning \(Update Manager\)initiatives" cc Subject RE: [provisioning-dev] What is the status on the provisioningprojects? Hi Pascal, I have a general interest in provisioning. We have quite some (customer and internal) requests for enhancements of installations. For example: - being able to roll out an installation to the desk of many developers (probably covered by Maya) - updating an installation of many developes in a coordinated way (Maya) - pushing preference settings to developers without overriding their settings (is centralized preference management covered by any of the provisioning projects?) - disallow users to update installed feaures using the update managers - revert a customized installation back to the officially supported version(s) - install non osgi based features - ... Michael -- Michael Scharf, Wind River direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805 > -----Original Message----- > From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg > [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of > Pascal Rapicault > Sent: Wednesday, 04 July, 2007 16:13 > To: Developer discussions for provisioning (Update Manager) > initiatives > Cc: Developer discussions for provisioning (Update > Manager)initiatives; fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg > Subject: Re: [provisioning-dev] What is the status on the > provisioningprojects? > > Hi Michael, > > There is no overall/cross-project plan for the provisioning effort and > since each project is independent addressing different part of the > provisioning space, it seems to me that the only "cross > project plan" we > need to have is something that plan discussion, collaboration and then > adoption of the new concepts and metadata being defined in > the equinox. > > As you may have already found, the equinox provisioning plan > is available > here (http://wiki.eclipse.org/Equinox_Provisioning_Plan). For > 3.4 and with > the current involvement, our goals will be to replace update manager. > > Given the context of the summit, the discussion will likely > focus on the > equinox part of the provisioning. > > Which area of the provisioning work are you interested in? > > HTH, > > PaScaL > > > > > > "Scharf, Michael" > > > indriver.com> > To > Sent by: "Developer discussions > for > provisioning-dev- provisioning \(Update > > B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM Manager\)initiatives" > > rg > > > cc > > > 07/03/2007 10:47 > Subject > PM [provisioning-dev] > What is the > status on the > provisioning > projects? > > Please respond to > > "Developer > > discussions for > > provisioning > > \(Update > > Manager\) > > initiatives" > > > @eclipse.org> > > > > > > > > > > Hi, > > what's the best way to get an overview of the current status > and the future plans of the provisioning effort? > > Is there a central place with the information? > > Is there anything better than (and the Provisioning category)? > http://wiki.eclipse.org/Provisioning > > Or do I have to come to the Summit in September? > > I also tried this search: http://tinyurl.com/yvt652 > > Michael > -- > Michael Scharf, Wind River > direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805 > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev --=_alternative 00714A868525730E_= Content-Type: text/html; charset="US-ASCII"
At least the last three items on your list are of interest in the equinox provisioning work.  I believe the Buckminster project is interested in touching on provisioning of workspaces and preferences. It sounds like you want to keep track of the work in at least Maya, Buckminster, and Equinox provisioning.  A useful link for more info on the wiki:

http://wiki.eclipse.org/Category:Provisioning

Also, discussion on the equinox provisioning is happening in the equinox-dev mailing list. You may want to browse the archive and/or subscribe to keep out to date.

John



"Scharf, Michael" <YgyQFOCWM9g4uOl/@QdoDIVO2IbNTSwBe>
Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg

07/04/2007 04:06 PM
Please respond to
"Developer discussions for provisioning \(Update Manager\)        initiatives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>

To
"Developer discussions for provisioning \(Update Manager\)initiatives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>
cc
Subject
RE: [provisioning-dev] What is the status on the provisioningprojects?





Hi Pascal,

I have a general interest in provisioning. We have quite some
(customer and internal) requests for enhancements of installations.
For example:

- being able to roll out an installation to the desk of many
 developers (probably covered by Maya)
- updating an installation of many developes in a coordinated
 way (Maya)
- pushing preference settings to developers without overriding
 their settings (is centralized preference management covered
 by any of the provisioning projects?)
- disallow users to update installed feaures using the update
 managers
- revert a customized installation back to the officially supported
 version(s)
- install non osgi based features
- ...


Michael
--
Michael Scharf, Wind River
direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805

> -----Original Message-----
> From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg
> [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of
> Pascal Rapicault
> Sent: Wednesday, 04 July, 2007 16:13
> To: Developer discussions for provisioning (Update Manager)
> initiatives
> Cc: Developer discussions for provisioning (Update
> Manager)initiatives; fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg
> Subject: Re: [provisioning-dev] What is the status on the
> provisioningprojects?
>
> Hi Michael,
>
> There is no overall/cross-project plan for the provisioning effort and
> since each project is independent addressing different part of the
> provisioning space, it seems to me that the only "cross
> project plan" we
> need to have is something that plan discussion, collaboration and then
> adoption of the new concepts and metadata being defined in
> the equinox.
>
> As you may have already found, the equinox provisioning plan
> is available
> here (http://wiki.eclipse.org/Equinox_Provisioning_Plan). For
> 3.4 and with
> the current involvement, our goals will be to replace update manager.
>
> Given the context of the summit, the discussion will likely
> focus on the
> equinox part of the provisioning.
>
> Which area of the provisioning work are you interested in?
>
> HTH,
>
> PaScaL
>
>
>
>                                                              
>              
>              "Scharf, Michael"                                
>              
>              <Michael.Scharf@w                                
>              
>              indriver.com>                                    
>           To
>              Sent by:                  "Developer discussions
> for          
>              provisioning-dev-         provisioning \(Update  
>              
>              B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM         Manager\)initiatives"  
>              
>              rg                        
> <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>      
>                                                              
>           cc
>                                                              
>              
>              07/03/2007 10:47                                
>      Subject
>              PM                        [provisioning-dev]
> What is the      
>                                        status on the
> provisioning          
>                                        projects?              
>              
>              Please respond to                                
>              
>                 "Developer                                    
>              
>               discussions for                                
>              
>                provisioning                                  
>              
>                  \(Update                                    
>              
>                  Manager\)                                    
>              
>                initiatives"                                  
>              
>              <provisioning-dev                                
>              
>                @eclipse.org>                                  
>              
>                                                              
>              
>                                                              
>              
>
>
>
>
> Hi,
>
> what's the best way to get an overview of the current status
> and the future plans of the provisioning effort?
>
> Is there a central place with the information?
>
> Is there anything better than (and the Provisioning category)?
>    http://wiki.eclipse.org/Provisioning
>
> Or do I have to come to the Summit in September?
>
> I also tried this search: http://tinyurl.com/yvt652
>
> Michael
> --
> Michael Scharf, Wind River
> direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805
> _______________________________________________
> provisioning-dev mailing list
> bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
> https://dev.eclipse.org/mailman/listinfo/provisioning-dev
>
>
> _______________________________________________
> provisioning-dev mailing list
> bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
> https://dev.eclipse.org/mailman/listinfo/provisioning-dev
>
_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev

--=_alternative 00714A868525730E_=-- From TVFpuITA/FOlewS/@RgofA6Na+BoXv9wI Thu Jul 5 10:27:57 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mail.eclipse.org (Postfix) with SMTP id C7EE627BE8 for ; Thu, 5 Jul 2007 10:27:56 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 69so2249565wri for ; Thu, 05 Jul 2007 07:27:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=eNb53SJOs7bjfG+aCq8KDui6mhO8NHdKvo6IV759z99Hgl49omyuCPMkyqB0Ma3bIrb+omDPwmgnYL1ozjgSwchTE91msGSkdJn1XK4I2ufF2cHsc9s7S9LYg/iiNb/fAYCYvx+NF6Fj8FHpYA07hrD/FH+WPKaFTlrZqPljgj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=I42A5hzpO//3Y4Wl5Ex8pp+UGhzGyTlmky23soXOJITkBmB54bXPAFKk5xJRJe5qBJq8FFIKFF8PxDmFj2FA+VBjCPw7/onQ5b57+RtWlLJHpKXfM847tjdsAFqNy2EZH/JfcGciCy7vJqtDA1CADnCz0D+p7ddULPTrKHpomMc= Received: by 10.90.91.14 with SMTP id o14mr7761098agb.1183645627906; Thu, 05 Jul 2007 07:27:07 -0700 (PDT) Received: by 10.90.86.18 with HTTP; Thu, 5 Jul 2007 07:27:07 -0700 (PDT) Message-ID: Date: Thu, 5 Jul 2007 09:27:07 -0500 From: "Tim Webb" Sender: TVFpuITA/FOlewS/@RgofA6Na+BoXv9wI To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] What is the status on the provisioningprojects? In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_109769_30996392.1183645627877" References: X-Google-Sender-Auth: d6bb7fbd3d992e5f X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2007 14:27:57 -0000 ------=_Part_109769_30996392.1183645627877 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Agreed. And most likely when using Maya with Equinox, it will likely involve a combination of Equinox and Maya to achieve some of the functions at least for those outside of the scope of preference configuration. Tim On 7/4/07, John Arthorne wrote: > > > At least the last three items on your list are of interest in the equinox > provisioning work. I believe the Buckminster project is interested in > touching on provisioning of workspaces and preferences. It sounds like you > want to keep track of the work in at least Maya, Buckminster, and Equinox > provisioning. A useful link for more info on the wiki: > > http://wiki.eclipse.org/Category:Provisioning > > Also, discussion on the equinox provisioning is happening in the > equinox-dev mailing list. You may want to browse the archive and/or > subscribe to keep out to date. > > John > > > > *"Scharf, Michael" * > Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg > > 07/04/2007 04:06 PM Please respond to > "Developer discussions for provisioning \(Update Manager\) > initiatives" > > To > "Developer discussions for provisioning \(Update Manager\)initiatives" < > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg> cc > > Subject > RE: [provisioning-dev] What is the status on the provisioningprojects? > > > > > > > Hi Pascal, > > I have a general interest in provisioning. We have quite some > (customer and internal) requests for enhancements of installations. > For example: > > - being able to roll out an installation to the desk of many > developers (probably covered by Maya) > - updating an installation of many developes in a coordinated > way (Maya) > - pushing preference settings to developers without overriding > their settings (is centralized preference management covered > by any of the provisioning projects?) > - disallow users to update installed feaures using the update > managers > - revert a customized installation back to the officially supported > version(s) > - install non osgi based features > - ... > > > Michael > -- > Michael Scharf, Wind River > direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805 > > > -----Original Message----- > > From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg > > [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of > > Pascal Rapicault > > Sent: Wednesday, 04 July, 2007 16:13 > > To: Developer discussions for provisioning (Update Manager) > > initiatives > > Cc: Developer discussions for provisioning (Update > > Manager)initiatives; fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg > > Subject: Re: [provisioning-dev] What is the status on the > > provisioningprojects? > > > > Hi Michael, > > > > There is no overall/cross-project plan for the provisioning effort and > > since each project is independent addressing different part of the > > provisioning space, it seems to me that the only "cross > > project plan" we > > need to have is something that plan discussion, collaboration and then > > adoption of the new concepts and metadata being defined in > > the equinox. > > > > As you may have already found, the equinox provisioning plan > > is available > > here (http://wiki.eclipse.org/Equinox_Provisioning_Plan). For > > 3.4 and with > > the current involvement, our goals will be to replace update manager. > > > > Given the context of the summit, the discussion will likely > > focus on the > > equinox part of the provisioning. > > > > Which area of the provisioning work are you interested in? > > > > HTH, > > > > PaScaL > > > > > > > > > > > > "Scharf, Michael" > > > > > > > indriver.com> > > To > > Sent by: "Developer discussions > > for > > provisioning-dev- provisioning \(Update > > > > B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM Manager\)initiatives" > > > > rg > > > > > > cc > > > > > > 07/03/2007 10:47 > > Subject > > PM [provisioning-dev] > > What is the > > status on the > > provisioning > > projects? > > > > Please respond to > > > > "Developer > > > > discussions for > > > > provisioning > > > > \(Update > > > > Manager\) > > > > initiatives" > > > > > > > @eclipse.org> > > > > > > > > > > > > > > > > > > > > Hi, > > > > what's the best way to get an overview of the current status > > and the future plans of the provisioning effort? > > > > Is there a central place with the information? > > > > Is there anything better than (and the Provisioning category)? > > http://wiki.eclipse.org/Provisioning > > > > Or do I have to come to the Summit in September? > > > > I also tried this search: http://tinyurl.com/yvt652 > > > > Michael > > -- > > Michael Scharf, Wind River > > direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805 > > _______________________________________________ > > provisioning-dev mailing list > > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > > > > > _______________________________________________ > > provisioning-dev mailing list > > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > ------=_Part_109769_30996392.1183645627877 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Agreed.  And most likely when using Maya with Equinox, it will likely involve a combination of Equinox and Maya to achieve some of the functions at least for those outside of the scope of preference configuration.

Tim

On 7/4/07, John Arthorne <John_EljLatxtsXDP9738@YHvLZjvCTR1Igv9U> wrote:

At least the last three items on your list are of interest in the equinox provisioning work.  I believe the Buckminster project is interested in touching on provisioning of workspaces and preferences. It sounds like you want to keep track of the work in at least Maya, Buckminster, and Equinox provisioning.  A useful link for more info on the wiki:

http://wiki.eclipse.org/Category:Provisioning

Also, discussion on the equinox provisioning is happening in the equinox-dev mailing list. You may want to browse the archive and/or subscribe to keep out to date.

John



"Scharf, Michael" <YgyQFOCWM9g4uOl/@QdoDIVO2IbNTSwBe>
Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg

07/04/2007 04:06 PM
Please respond to
"Developer discussions for provisioning \(Update Manager\)        initiatives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>

To
"Developer discussions for provisioning \(Update Manager\)initiatives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>
cc

Subject
RE: [provisioning-dev] What is the status on the provisioningprojects?







Hi Pascal,

I have a general interest in provisioning. We have quite some
(customer and internal) requests for enhancements of installations.
For example:

- being able to roll out an installation to the desk of many
 developers (probably covered by Maya)
- updating an installation of many developes in a coordinated
 way (Maya)
- pushing preference settings to developers without overriding
 their settings (is centralized preference management covered
 by any of the provisioning projects?)
- disallow users to update installed feaures using the update
 managers
- revert a customized installation back to the officially supported
 version(s)
- install non osgi based features
- ...


Michael
--
Michael Scharf, Wind River
direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805

> -----Original Message-----
> From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg
> [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of
> Pascal Rapicault
> Sent: Wednesday, 04 July, 2007 16:13
> To: Developer discussions for provisioning (Update Manager)
> initiatives
> Cc: Developer discussions for provisioning (Update
> Manager)initiatives; fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg
> Subject: Re: [provisioning-dev] What is the status on the
> provisioningprojects?
>
> Hi Michael,
>
> There is no overall/cross-project plan for the provisioning effort and
> since each project is independent addressing different part of the
> provisioning space, it seems to me that the only "cross
> project plan" we
> need to have is something that plan discussion, collaboration and then
> adoption of the new concepts and metadata being defined in
> the equinox.
>
> As you may have already found, the equinox provisioning plan
> is available
> here (http://wiki.eclipse.org/Equinox_Provisioning_Plan). For
> 3.4 and with
> the current involvement, our goals will be to replace update manager.
>
> Given the context of the summit, the discussion will likely
> focus on the
> equinox part of the provisioning.
>
> Which area of the provisioning work are you interested in?
>
> HTH,
>
> PaScaL
>
>
>
>                                                              
>              
>              "Scharf, Michael"                                
>              
>              <Michael.Scharf@w                                
>              
>              indriver.com>                                    
>           To
>              Sent by:                  "Developer discussions
> for          
>              provisioning-dev-         provisioning \(Update  
>              
>              B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM         Manager\)initiatives"  
>              
>              rg                        
> <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>      
>                                                              
>           cc
>                                                              
>              
>              07/03/2007 10:47                                
>      Subject
>              PM                        [provisioning-dev]
> What is the      
>                                        status on the
> provisioning          
>                                        projects?              
>              
>              Please respond to                                
>              
>                 "Developer                                    
>              
>               discussions for                                
>              
>                provisioning                                  
>              
>                  \(Update                                    
>              
>                  Manager\)                                    
>              
>                initiatives"                                  
>              
>              <provisioning-dev                                
>              
>                @eclipse.org>                                  
>              
>                                                              
>              
>                                                              
>              
>
>
>
>
> Hi,
>
> what's the best way to get an overview of the current status
> and the future plans of the provisioning effort?
>
> Is there a central place with the information?
>
> Is there anything better than (and the Provisioning category)?
>    http://wiki.eclipse.org/Provisioning
>
> Or do I have to come to the Summit in September?
>
> I also tried this search: http://tinyurl.com/yvt652
>
> Michael
> --
> Michael Scharf, Wind River
> direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805
> _______________________________________________
> provisioning-dev mailing list
> bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
> https://dev.eclipse.org/mailman/listinfo/provisioning-dev
>
>
> _______________________________________________
> provisioning-dev mailing list
> bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
> https://dev.eclipse.org/mailman/listinfo/provisioning-dev
>
_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev


_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev


------=_Part_109769_30996392.1183645627877-- From TVFpuITA/FOlewS/@RgofA6Na+BoXv9wI Mon Jul 16 13:17:19 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mail.eclipse.org (Postfix) with SMTP id E9C6E7517B for ; Mon, 16 Jul 2007 13:17:18 -0400 (EDT) Received: by wx-out-0506.google.com with SMTP id i30so1133629wxd for ; Mon, 16 Jul 2007 10:16:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=GuvBAeCCsGH9oHGK85RvcjnufEN4Y2OsZFlBJEZabea0xTWnogbamy5KHcRut6TJ0zg++odmtRwAXbGG8cQxCFf3wSTXLau6rS+TNNRudv6NgYGyz4qQfijN4pO79o94bmRHN04S7C6xCiSBkgzqHWZFM2lU1BUJ1QM5wpv/aaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=nDCw5O83+IIT2RYvkf2F6kFiAB89l6HVBPQ2fNBKikXSYKF+9Omu6xjAvXecTVv9wR8cfMILzISRnXpBz3a04RgkBkuxAIUlCvSbpS5vJ46l5On0Xvq4YbN5wpk3O3BsfpulW3I2E3FDNXz8sZMOxU5UkbETLobUpFNT6eFBQIk= Received: by 10.90.29.18 with SMTP id c18mr3437650agc.1184606168845; Mon, 16 Jul 2007 10:16:08 -0700 (PDT) Received: by 10.90.86.18 with HTTP; Mon, 16 Jul 2007 10:16:08 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 12:16:08 -0500 From: "Tim Webb" Sender: TVFpuITA/FOlewS/@RgofA6Na+BoXv9wI To: "Maya development mailing list" , "Developer discussions for provisioning (Update Manager) initiatives" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_53701_12554951.1184606168824" X-Google-Sender-Auth: d6e7c850943106c6 Cc: Subject: [provisioning-dev] Maya updates to support JPA and Eclipse 3.3 X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 17:17:19 -0000 ------=_Part_53701_12554951.1184606168824 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline As you may have seen, Dennis has checked in code to support using JPA instead of the current dependency on Hibernate. If you want to play with this, in the near term you'll need to use Toplink Essentials while Oracle sorts out final IP review on EclipseLink. Also, Maya now correctly supports using the org.eclipse.equinox.launcher plugin as the startup.jar equivalent when using Eclipse 3.3 or higher. The example deployment of Maya now defaults to Eclipse 3.3 instead of 3.2. We suggest only updating if you are also going to test out using Toplink Essentials since the current code base now has a dependency to that. Cheers, Tim ------=_Part_53701_12554951.1184606168824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline As you may have seen, Dennis has checked in code to support using JPA instead of the current dependency on Hibernate.  If you want to play with this, in the near term you'll need to use Toplink Essentials while Oracle sorts out final IP review on EclipseLink.  Also, Maya now correctly supports using the org.eclipse.equinox.launcher plugin as the startup.jar equivalent when using Eclipse 3.3 or higher.  The example deployment of Maya now defaults to Eclipse 3.3 instead of 3.2.  We suggest only updating if you are also going to test out using Toplink Essentials since the current code base now has a dependency to that.

Cheers,
Tim
------=_Part_53701_12554951.1184606168824-- From susan_Ooip62J6hzCYWvyE@NWxUxqmKJBdCO6sQ Mon Jul 23 14:40:07 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by mail.eclipse.org (Postfix) with SMTP id 837962846A for ; Mon, 23 Jul 2007 14:40:06 -0400 (EDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6NIciWF022765 for ; Mon, 23 Jul 2007 14:38:44 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6NIciNp203768 for ; Mon, 23 Jul 2007 12:38:44 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6NIciM1028610 for ; Mon, 23 Jul 2007 12:38:44 -0600 X-Authentication-Warning: d03av03.boulder.ibm.com: Processed from queue /var/spool/mqueue/active* X-Authentication-Warning: d03av03.boulder.ibm.com: Processed by postman with -C /relay/etc/sendmail.cf-deliver Received: from d03nm113.boulder.ibm.com (d03nm113.boulder.ibm.com [9.17.195.139]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6NIcioB028607 for ; Mon, 23 Jul 2007 12:38:44 -0600 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Susan M Franklin Date: Mon, 23 Jul 2007 11:38:38 -0700 X-MIMETrack: Serialize by Router on D03NM113/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 07/23/2007 12:38:44, Serialize complete at 07/23/2007 12:38:44 Content-Type: multipart/alternative; boundary="=_alternative 00667DF088257321_=" Subject: [provisioning-dev] new UI projects released to incubator X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 18:40:09 -0000 This is a multipart message in MIME format. --=_alternative 00667DF088257321_= Content-Type: text/plain; charset="US-ASCII" There are two new UI projects in the provisioning area - equinox-incubator/provisioning/org.eclipse.equinox.prov.ui - equinox-incubator/provisioning/org.eclipse.equinox.prov.ui.admin Assuming you are already self hosting the provisioning code, you'll want to: - get these projects from the repository (they are not currently in the project set) - create an "Eclipse application" launch config and copy the arguments from one of your other launch configs, such as Test Director SDK - launch the workspace and then open the "Provisioning" perspective The UI is simply a browsing UI on top the existing API. Its purpose is to exercise and visualize the provisioning API. In other words, I don't believe this UI to be targeted at any users besides provisioning hackers and folks interested in the provisioning model. It is certainly not an update manager UI replacement....just a first step in playing with UI's on top of the new API. please see this bug for further info: https://bugs.eclipse.org/bugs/show_bug.cgi?id=197405 thanks, susan --=_alternative 00667DF088257321_= Content-Type: text/html; charset="US-ASCII"
There are two new UI projects in the provisioning area
        - equinox-incubator/provisioning/org.eclipse.equinox.prov.ui
        - equinox-incubator/provisioning/org.eclipse.equinox.prov.ui.admin

Assuming you are already self hosting the provisioning code, you'll want to:
- get these projects from the repository (they are not currently in the project set)
- create an "Eclipse application" launch config and copy the arguments from one of your other launch configs, such as Test Director SDK
- launch the workspace and then open the "Provisioning" perspective

The UI is simply a browsing UI on top the existing API.  Its purpose is to exercise and visualize the provisioning API.  In other words, I don't believe this UI to be targeted at any users besides provisioning hackers and folks interested in the provisioning model.  It is certainly not an update manager UI replacement....just a first step in playing with UI's on top of the new API.


please see this bug for further info:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=197405

thanks,
susan --=_alternative 00667DF088257321_=-- From c4ggBaWL03soQqfa@NWxUxqmKJBdCO6sQ Thu Jul 26 16:43:18 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by mail.eclipse.org (Postfix) with SMTP id 81A28337E6; Thu, 26 Jul 2007 16:43:16 -0400 (EDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6QKfnc3020877; Thu, 26 Jul 2007 16:41:49 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6QKfmfW214372; Thu, 26 Jul 2007 14:41:49 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6QKfm7w004936; Thu, 26 Jul 2007 14:41:48 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6QKfmNv004930; Thu, 26 Jul 2007 14:41:48 -0600 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg, Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: David R Stevenson Message-ID: Date: Thu, 26 Jul 2007 13:41:46 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V80_M5_05202007|May 20, 2007) at 07/26/2007 14:44:44, Serialize complete at 07/26/2007 14:44:44 Content-Type: multipart/alternative; boundary="=_alternative 0071C74488257324_=" Cc: Subject: [provisioning-dev] [prov] fix for bugzilla X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2007 20:43:18 -0000 This is a multipart message in MIME format. --=_alternative 0071C74488257324_= Content-Type: text/plain; charset="US-ASCII" I committed a fix for bugzilla 197404 - Profile class has wrong property name string assigned to PROP_NAME. I also fixed a couple of other naming inconsistencies, in particular property name constant for flavor from "flavor" to "eclipse.prov.flavor". This has a side-effect in existing persisted profiles of causing an error dialog when browsing the profile properties in the UI, because there is no value under the new flavor key. The (draconian) solution is to delete the agent data and existing installs and the agent data and reinstall (if desired). Let me know if you have any questions/problems. - Dave --=_alternative 0071C74488257324_= Content-Type: text/html; charset="US-ASCII"
I committed a fix for  bugzilla 197404 - Profile class has wrong property name string assigned to PROP_NAME.

I also fixed a couple of other naming inconsistencies, in particular property name constant for flavor from "flavor" to "eclipse.prov.flavor". This has a side-effect in existing persisted profiles of causing an error dialog when browsing the profile properties in the UI, because there is no value under the new flavor key. The (draconian) solution is to delete the agent data and existing installs and the agent data and reinstall (if desired).

Let me know if you have any questions/problems.

        - Dave --=_alternative 0071C74488257324_=-- From susan_Ooip62J6hzCYWvyE@NWxUxqmKJBdCO6sQ Thu Jul 26 18:39:32 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by mail.eclipse.org (Postfix) with SMTP id 07CFA27E9F for ; Thu, 26 Jul 2007 18:39:31 -0400 (EDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6QMc3RQ023992 for ; Thu, 26 Jul 2007 18:38:03 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6QMc3XZ168726 for ; Thu, 26 Jul 2007 16:38:03 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6QMc3aH031527 for ; Thu, 26 Jul 2007 16:38:03 -0600 X-Authentication-Warning: d03av03.boulder.ibm.com: Processed from queue /var/spool/mqueue/active* X-Authentication-Warning: d03av03.boulder.ibm.com: Processed by postman with -C /relay/etc/sendmail.cf-deliver Received: from d03nm113.boulder.ibm.com (d03nm113.boulder.ibm.com [9.17.195.139]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6QMc3KR031522 for ; Thu, 26 Jul 2007 16:38:03 -0600 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Susan M Franklin Date: Thu, 26 Jul 2007 15:38:00 -0700 X-MIMETrack: Serialize by Router on D03NM113/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 07/26/2007 16:38:02, Serialize complete at 07/26/2007 16:38:02 Content-Type: multipart/alternative; boundary="=_alternative 007C68B088257324_=" Subject: [provisioning-dev] two process questions... X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2007 22:39:32 -0000 This is a multipart message in MIME format. --=_alternative 007C68B088257324_= Content-Type: text/plain; charset="US-ASCII" 1 - Should we start using bugzilla milestones (such as 3.4 M1) to tag provisioning bugs that we fix for our M1?...or is this confusing for those running reports on the 3.4 release since the code is not mainstream 3.4 yet? 2 - I've noticed that most provisioning questions/discussions lately have taken place on equinox-dev with [prov] in the title. Is this just to reach a wider audience and should we be encouraging people to subscribe to this mailing list? thanks, susan --=_alternative 007C68B088257324_= Content-Type: text/html; charset="US-ASCII"
1 - Should we start using bugzilla milestones (such as 3.4 M1) to tag provisioning bugs that we fix for our M1?...or is this confusing for those running reports on the 3.4 release since the code is not mainstream 3.4 yet?  
2 - I've noticed that most provisioning questions/discussions lately have taken place on equinox-dev with [prov] in the title.  Is this just to reach a wider audience and should we be encouraging people to subscribe to this mailing list?  

thanks,
susan --=_alternative 007C68B088257324_=-- From susan_Ooip62J6hzCYWvyE@NWxUxqmKJBdCO6sQ Thu Jul 26 20:48:23 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by mail.eclipse.org (Postfix) with SMTP id 691622857E; Thu, 26 Jul 2007 20:48:21 -0400 (EDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6R0krPB012015; Thu, 26 Jul 2007 20:46:53 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6R0krcT218500; Thu, 26 Jul 2007 18:46:53 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6R0krH5002833; Thu, 26 Jul 2007 18:46:53 -0600 Received: from d03nm113.boulder.ibm.com (d03nm113.boulder.ibm.com [9.17.195.139]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6R0krPP002827; Thu, 26 Jul 2007 18:46:53 -0600 In-Reply-To: To: Equinox development mailing list MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Susan M Franklin Date: Thu, 26 Jul 2007 17:46:51 -0700 X-MIMETrack: Serialize by Router on D03NM113/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 07/26/2007 18:46:53, Serialize complete at 07/26/2007 18:46:53 Content-Type: multipart/alternative; boundary="=_alternative 00045E6D88257325_=" Cc: Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg, bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg, X5UfnEHRtTnuvWCG@XzQPvII7mdsgt6xg Subject: [provisioning-dev] Re: [equinox-dev] [prov] fix for bugzilla X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 00:48:23 -0000 This is a multipart message in MIME format. --=_alternative 00045E6D88257325_= Content-Type: text/plain; charset="US-ASCII" It's bogus of me that the UI chokes on the null value. A less draconian solution is to patch it up as Andrew did in bug #197970. I'll clean these up in the next set of changes. susan David R Stevenson/Redmond/IBM@IBMUS Sent by: X5UfnEHRtTnuvWCG@XzQPvII7mdsgt6xg 07/26/2007 01:41 PM Please respond to Equinox development mailing list To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg, Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg cc: Subject: [equinox-dev] [prov] fix for bugzilla I committed a fix for bugzilla 197404 - Profile class has wrong property name string assigned to PROP_NAME. I also fixed a couple of other naming inconsistencies, in particular property name constant for flavor from "flavor" to "eclipse.prov.flavor". This has a side-effect in existing persisted profiles of causing an error dialog when browsing the profile properties in the UI, because there is no value under the new flavor key. The (draconian) solution is to delete the agent data and existing installs and the agent data and reinstall (if desired). Let me know if you have any questions/problems. - Dave_______________________________________________ equinox-dev mailing list Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/equinox-dev --=_alternative 00045E6D88257325_= Content-Type: text/html; charset="US-ASCII"
It's bogus of me that the UI chokes on the null value.  A less draconian solution is to patch it up as Andrew did in bug #197970.  I'll clean these up in the next set of changes.

susan


David R Stevenson/Redmond/IBM@IBMUS
Sent by: X5UfnEHRtTnuvWCG@XzQPvII7mdsgt6xg

07/26/2007 01:41 PM
Please respond to Equinox development mailing list

       
        To:        bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg, Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg
        cc:        
        Subject:        [equinox-dev] [prov] fix for bugzilla




I committed a fix for  
bugzilla 197404 - Profile class has wrong property name string assigned to PROP_NAME.

I also fixed a couple of other naming inconsistencies, in particular property name constant for flavor from "flavor" to "eclipse.prov.flavor". This has a side-effect in existing persisted profiles of causing an error dialog when browsing the profile properties in the UI, because there is no value under the new flavor key. The (draconian) solution is to delete the agent data and existing installs and the agent data and reinstall (if desired).


Let me know if you have any questions/problems.


       - Dave
_______________________________________________
equinox-dev mailing list
Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/equinox-dev

--=_alternative 00045E6D88257325_=-- From Jeff_TTczmgW07z/8fKPW@YHvLZjvCTR1Igv9U Thu Jul 26 23:14:00 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by mail.eclipse.org (Postfix) with SMTP id 11BFF338E3 for ; Thu, 26 Jul 2007 23:13:59 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6R3CVmO006459 for ; Thu, 26 Jul 2007 23:12:31 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6R3CVWA559844 for ; Thu, 26 Jul 2007 23:12:31 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6R3CVW0011347 for ; Thu, 26 Jul 2007 23:12:31 -0400 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6R3CV8x011342 for ; Thu, 26 Jul 2007 23:12:31 -0400 In-Reply-To: To: "Developer discussions for provisioning \(Update Manager\) initiatives" Subject: Re: [provisioning-dev] two process questions... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Jeff McAffer Message-ID: Date: Thu, 26 Jul 2007 23:12:31 -0400 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 07/26/2007 23:12:33, Serialize complete at 07/26/2007 23:12:33 Content-Type: multipart/alternative; boundary="=_alternative 00115F3085257325_=" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 03:14:00 -0000 This is a multipart message in MIME format. --=_alternative 00115F3085257325_= Content-Type: text/plain; charset="US-ASCII" 1) yes, I think we in Equinox should use 3.4M1 as our M1 target. We are a week earlier than the full project but that's ok. 2) The provisioning-dev list was setup mostly for general provisioning discussions across Eclipse (e.g., Equionx, Maya, EPP, ...). Notifications of progress, conceptual discussions, usecases, ... Maya and Equinox have (currently) separate code bases and developer communities. So for example, the discussion around M1 is only relevant to Equinox (unless Maya happens to be having an M1 at the same time). I do think that people should be subscribed to this list but it would likely be best to keep the Equinox and Maya detailed discussions on their respective lists. Note, I am not dogmatic about this and could be argued into a different position. Jeff Susan M Franklin Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg 07/26/2007 06:38 PM Please respond to "Developer discussions for provisioning \(Update Manager\) initiatives" To bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg cc Subject [provisioning-dev] two process questions... 1 - Should we start using bugzilla milestones (such as 3.4 M1) to tag provisioning bugs that we fix for our M1?...or is this confusing for those running reports on the 3.4 release since the code is not mainstream 3.4 yet? 2 - I've noticed that most provisioning questions/discussions lately have taken place on equinox-dev with [prov] in the title. Is this just to reach a wider audience and should we be encouraging people to subscribe to this mailing list? thanks, susan_______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev --=_alternative 00115F3085257325_= Content-Type: text/html; charset="US-ASCII"
1) yes, I think we in Equinox should use 3.4M1 as our M1 target.  We are a week earlier than the full project but that's ok.

2) The provisioning-dev list was setup mostly for general provisioning discussions across Eclipse (e.g., Equionx, Maya, EPP, ...).  Notifications of progress, conceptual discussions, usecases, ...  Maya and Equinox have (currently) separate code bases and developer communities.  So for example, the discussion around M1 is only relevant to Equinox (unless Maya happens to be having an M1 at the same time).  I do think that people should be subscribed to this list but it would likely be best to keep the Equinox and Maya detailed discussions on their respective lists.  Note, I am not dogmatic about this and could be argued into a different position.

Jeff




Susan M Franklin <susan_Ooip62J6hzCYWvyE@NWxUxqmKJBdCO6sQ>
Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg

07/26/2007 06:38 PM
Please respond to
"Developer discussions for provisioning \(Update Manager\)        initiatives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>

To
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
cc
Subject
[provisioning-dev] two  process questions...






1 - Should we start using bugzilla milestones (such as 3.4 M1) to tag provisioning bugs that we fix for our M1?...or is this confusing for those running reports on the 3.4 release since the code is not mainstream 3.4 yet?  

2 - I've noticed that most provisioning questions/discussions lately have taken place on equinox-dev with [prov] in the title.  Is this just to reach a wider audience and should we be encouraging people to subscribe to this mailing list?  


thanks,

susan
_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev

--=_alternative 00115F3085257325_=-- From Jeff_TTczmgW07z/8fKPW@YHvLZjvCTR1Igv9U Fri Aug 3 00:35:16 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by mail.eclipse.org (Postfix) with SMTP id 5CE911FD6A; Fri, 3 Aug 2007 00:35:15 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l734XYU0024805; Fri, 3 Aug 2007 00:33:34 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l734XYUQ549558; Fri, 3 Aug 2007 00:33:34 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l734XYtS027264; Fri, 3 Aug 2007 00:33:34 -0400 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l734XYBl027261; Fri, 3 Aug 2007 00:33:34 -0400 To: Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg, bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Jeff McAffer Message-ID: Date: Fri, 3 Aug 2007 00:33:33 -0400 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 08/03/2007 00:33:34, Serialize complete at 08/03/2007 00:33:34 Content-Type: multipart/alternative; boundary="=_alternative 0019135D8525732C_=" Cc: Subject: [provisioning-dev] Equinox Provisioning M1 X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2007 04:35:17 -0000 This is a multipart message in MIME format. --=_alternative 0019135D8525732C_= Content-Type: text/plain; charset="US-ASCII" It is with great pleasure (and just a bit of last minute fuss) that the Equinox Provisioning team announces the delivery of its Milestone 1. Milestone 1, as the name implies, is our first step towards a new provisioning system for Eclipse. We have hit most of the major items on the M1 plan and most importantly are well-positioned to acheive the M1 goal of self-provision. That is, we will now use the new provisioning support to install and manage the Eclipse environment that we ourselves use to write the provisioning system. Over the comming weeks we will undoubtedly find various issues and make numerous improvements. We invite you along on that journey with the understanding that this is M1. It is very early days and the road will be bumpy in spots. Your ideas, insights, bug reports and contributions are what will make this effort a success. Please direct comments to the Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg mailing list and bug reports to the Eclipse/Equinox/Incubator bugzilla bucket (use [prov] in the summary line). For more details (in progress) see: http://wiki.eclipse.org/Equinox_Provisioning_M1 The Equinox Provisioning Team --=_alternative 0019135D8525732C_= Content-Type: text/html; charset="US-ASCII"
It is with great pleasure (and just a bit of last minute fuss) that the Equinox Provisioning team announces the delivery of its Milestone 1.  Milestone 1, as the name implies, is our first step towards a  new provisioning system for Eclipse. We have hit most of the major items on the  M1 plan and most importantly are well-positioned to acheive the M1 goal of self-provision. That is, we will now use the new provisioning support to install and manage the Eclipse environment that we ourselves use to write the provisioning system.

Over the comming weeks we will undoubtedly find various issues and make numerous improvements.  We invite you along on that journey with the understanding that this is M1.  It is very early days and the road will be bumpy in spots.  Your ideas, insights, bug reports and contributions are what will make this effort a success.  Please direct comments to the Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg mailing list and bug reports to the Eclipse/Equinox/Incubator bugzilla bucket (use [prov] in the summary line).

For more details (in progress) see:
        http://wiki.eclipse.org/Equinox_Provisioning_M1

The Equinox Provisioning Team --=_alternative 0019135D8525732C_=-- From ibUJb3sa9f9eQvpv@NI2tUOVyBgDlja3U Tue Aug 7 13:40:37 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.eclipse.org (Postfix) with SMTP id A68D7286C8 for ; Tue, 7 Aug 2007 13:40:36 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l77Hckpx020803 for ; Tue, 7 Aug 2007 13:38:46 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l77HcjNg018027 for ; Tue, 7 Aug 2007 13:38:45 -0400 Received: from touchme.toronto.redhat.com (IDENT:WDiYDPqf/uCuLoKB@PVpMn8dKDgreGpjk [172.16.14.9]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l77Hcjsh017933 for ; Tue, 7 Aug 2007 13:38:45 -0400 Received: from [172.16.14.103] (to-dhcp3.toronto.redhat.com [172.16.14.103]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 3354280008E for ; Tue, 7 Aug 2007 13:38:45 -0400 (EDT) From: Andrew Overholt To: provisioning-dev X-Mutt-Fcc: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eOWAJg1f7EW6kEsBmSr1" Date: Tue, 07 Aug 2007 13:37:50 -0400 Message-Id: Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 (2.10.2-3.fc7) Subject: [provisioning-dev] Profile inheritance X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2007 17:40:38 -0000 --=-eOWAJg1f7EW6kEsBmSr1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, The week before last I had some discussions with Pascal about how Equinox provisioning stuff will interact with Linux distribution packages. Since then I've been struggling a bit to get my thoughts and our discussions collected so I'd like to discuss them here to get others' opinions. One of the ideas we discussed was profile inheritance. With that, we would have a system-wide (administrator-managed) profile that is populated with the entire set of bundles available via installed distro packages (RPMs, .debs, whatever). (I am thinking we'd have to manually avoid conflicts in what we ship, but that's tangential here.) We would also have per-user profiles that allow for system-wide things to be disabled/enabled and allows for per-user bundle installation. Does this make sense? Thanks, Andrew --=-eOWAJg1f7EW6kEsBmSr1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGuK3l3yjNjou+b0IRAoyDAJ4k/83qe6+vAE5Z0qCqvFM1D2PwmwCfSqcG v0RlXYWo8gGODVFPOTLMw50= =9keW -----END PGP SIGNATURE----- --=-eOWAJg1f7EW6kEsBmSr1-- From TVFpuITA/FOlewS/@RgofA6Na+BoXv9wI Tue Aug 7 13:57:21 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by mail.eclipse.org (Postfix) with SMTP id 1BB7D286C3 for ; Tue, 7 Aug 2007 13:57:20 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 58so1434060wri for ; Tue, 07 Aug 2007 10:55:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=X9hKACcbc4fCQ/R5ckIk11MPYgtNAjyjh4KPemKMik9LHeLfOVJG1nCGwl0pmDMZCwIIjdnFDPEwp7kVwWI1fxPV/fQl+rqTRXMo5WL0ZB80+ZOaD0rPnSYVBYX+oKwK9Tq7g4+gl1sislnkfGuxYSzRNbComs9dBIfqO9VlWgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=JHjE0+2KFV08WE0lfTbUWGzneKuFTqH9aNIKZvsc2IvcHAfQ7as8ftpu53u/CJoCNJghbEeUtK0fRbB0zBaBAoRL9EjIWIqpXPsgqMhDxpLMZsQXdehToqUqwqCvdXv6fl20eIbNDvUr7RD99Ave18LGIOaAYxGr2uMJuSDWGSI= Received: by 10.90.66.9 with SMTP id o9mr6360169aga.1186509327047; Tue, 07 Aug 2007 10:55:27 -0700 (PDT) Received: by 10.90.86.18 with HTTP; Tue, 7 Aug 2007 10:55:26 -0700 (PDT) Message-ID: Date: Tue, 7 Aug 2007 12:55:26 -0500 From: "Tim Webb" Sender: TVFpuITA/FOlewS/@RgofA6Na+BoXv9wI To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] Profile inheritance In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_93747_6267491.1186509326965" References: X-Google-Sender-Auth: 1991b59bf683b31e X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2007 17:57:27 -0000 ------=_Part_93747_6267491.1186509326965 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What your proposing is extremely similar to what we had been doing in our data model in Maya in that the base profile defined by an administrator could be augmented by a user. In this case, we had envisioned rules as to what could be excluded such that some adminstrator defined software would be required while others could be updated to be excluded by the user. The big difference in what we were doing in Maya was that the profiles were shared across systems, though I have a feeling if the use cases we defined worked out well in the shared case, then whether shared across systems or shared by users of a single system, I imagine the model could still work out fine. In the case of integrating with Linux, the user would need to be able to define potentially multiple derivative profiles off of the base system one. The challenge will be maintaining consistency of those derived profiles as the system-wide profile is updated by various package operations RPM, etc. In that regard, I think the ease would depend on the rules of the added software. If the added software conflicted with what the user already had in the profile, but the included software is able to be excluded, that it would be automatically added as an exclude rule. In addition, in the case of a managed provisioning scenario with governance, if the governance model prohibits adding certain software that is added by RPM or other package, the user's profile would still need to have that software excluded. Tim On 8/7/07, Andrew Overholt wrote: > > Hi, > > The week before last I had some discussions with Pascal about how > Equinox provisioning stuff will interact with Linux distribution > packages. Since then I've been struggling a bit to get my thoughts and > our discussions collected so I'd like to discuss them here to get > others' opinions. > > One of the ideas we discussed was profile inheritance. With that, we > would have a system-wide (administrator-managed) profile that is > populated with the entire set of bundles available via installed distro > packages (RPMs, .debs, whatever). (I am thinking we'd have to manually > avoid conflicts in what we ship, but that's tangential here.) We would > also have per-user profiles that allow for system-wide things to be > disabled/enabled and allows for per-user bundle installation. Does this > make sense? > > Thanks, > > Andrew > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > > ------=_Part_93747_6267491.1186509326965 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What your proposing is extremely similar to what we had been doing in our data model in Maya in that the base profile defined by an administrator could be augmented by a user.  In this case, we had envisioned rules as to what could be excluded such that some adminstrator defined software would be required while others could be updated to be excluded by the user.  The big difference in what we were doing in Maya was that the profiles were shared across systems, though I have a feeling if the use cases we defined worked out well in the shared case, then whether shared across systems or shared by users of a single system, I imagine the model could still work out fine.

In the case of integrating with Linux, the user would need to be able to define potentially multiple derivative profiles off of the base system one.  The challenge will be maintaining consistency of those derived profiles as the system-wide profile is updated by various package operations RPM, etc.  In that regard, I think the ease would depend on the rules of the added software.  If the added software conflicted with what the user already had in the profile, but the included software is able to be excluded, that it would be automatically added as an exclude rule.  In addition, in the case of a managed provisioning scenario with governance, if the governance model prohibits adding certain software that is added by RPM or other package, the user's profile would still need to have that software excluded.

Tim

On 8/7/07, Andrew Overholt <ibUJb3sa9f9eQvpv@NI2tUOVyBgDlja3U> wrote:
Hi,

The week before last I had some discussions with Pascal about how
Equinox provisioning stuff will interact with Linux distribution
packages.  Since then I've been struggling a bit to get my thoughts and
our discussions collected so I'd like to discuss them here to get
others' opinions.

One of the ideas we discussed was profile inheritance.  With that, we
would have a system-wide (administrator-managed) profile that is
populated with the entire set of bundles available via installed distro
packages (RPMs, .debs, whatever).  (I am thinking we'd have to manually
avoid conflicts in what we ship, but that's tangential here.)  We would
also have per-user profiles that allow for system-wide things to be
disabled/enabled and allows for per-user bundle installation.  Does this
make sense?

Thanks,

Andrew

_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev



------=_Part_93747_6267491.1186509326965-- From RJLa1gAKTeLBAdDY@NWxUxqmKJBdCO6sQ Tue Aug 7 14:01:28 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by mail.eclipse.org (Postfix) with SMTP id 0E1A529683 for ; Tue, 7 Aug 2007 14:01:27 -0400 (EDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.12.11.20060308/8.13.8) with ESMTP id l77GrCeg016195 for ; Tue, 7 Aug 2007 12:53:12 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l77HxboM241950 for ; Tue, 7 Aug 2007 11:59:37 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l77Hxb8I022799 for ; Tue, 7 Aug 2007 11:59:37 -0600 Received: from d03mc019.boulder.ibm.com (d03mc019.boulder.ibm.com [9.17.195.203]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l77HxbJQ022791 for ; Tue, 7 Aug 2007 11:59:37 -0600 In-Reply-To: Subject: Re: [provisioning-dev] Profile inheritance To: "Developer discussions for provisioning \(Update Manager\) initiatives" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: James D Miles Date: Tue, 7 Aug 2007 13:00:52 -0500 X-MIMETrack: Serialize by Router on D03MC019/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 08/07/2007 11:59:36 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2007 18:01:28 -0000 --0__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC Content-type: multipart/related; Boundary="1__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC" --1__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC Content-type: multipart/alternative; Boundary="2__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC" --2__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I think we also need administrative profile on windows or any OS for th= at matter. For the multiuser install there needs to be an administrative profile. The ability to have disable/enable profiles for each user is right on. = This is more or less how we work with the current eclipse. = Andrew Overholt = = To Sent by: provisioning-dev = provisioning-dev- = B9Rnu9unMxZqnP1G@THhw9RaooydiiRCM = cc rg = Subj= ect [provisioning-dev] Profile = 08/07/2007 12:37 inheritance = PM = = = Please respond to = "Developer = discussions for = provisioning = \(Update = Manager\) = initiatives" = = = = Hi, The week before last I had some discussions with Pascal about how Equinox provisioning stuff will interact with Linux distribution packages. Since then I've been struggling a bit to get my thoughts and= our discussions collected so I'd like to discuss them here to get others' opinions. One of the ideas we discussed was profile inheritance. With that, we would have a system-wide (administrator-managed) profile that is populated with the entire set of bundles available via installed distro= packages (RPMs, .debs, whatever). (I am thinking we'd have to manually= avoid conflicts in what we ship, but that's tangential here.) We would= also have per-user profiles that allow for system-wide things to be disabled/enabled and allows for per-user bundle installation. Does thi= s make sense? Thanks, Andrew (See attached file: signature.asc) _______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev = --2__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I think we also need administrative profile on windows or any OS for= that matter. For the multiuser install there needs to be an administra= tive profile.
The ability to have disable/enable profiles for each user is right on. = This is more or less how we work with the current eclipse.



3D"InactiveAndrew Overholt <overholt@re= dhat.com>


=
          Andrew Overholt <ibUJb3sa9f9eQvpv@NI2tUOVyBgDlja3U>
          Sent by: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg

          08/07/2007 12:37 PM
          Please respond to
          "Developer discussions for provisioning \(Update Manager\) initiat= ives" <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg>

=
3D=
To
3D""
provisioning-dev <bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg><= /font>
3D=
cc
3D""
3D=
Subject
3D""
[provisioning-dev] Profile inheritance
3D=3D""

Hi,

The week before last I had some discussions with Pascal about how
Equinox provisioning stuff will interact with Linux distribution
packages.  Since then I've been struggling a bit to get my thought= s and
our discussions collected so I'd like to discuss them here to get
others' opinions.

One of the ideas we discussed was profile inheritance.  With that,= we
would have a system-wide (administrator-managed) profile that is
populated with the entire set of bundles available via installed distro=
packages (RPMs, .debs, whatever).  (I am thinking we'd have to man= ually
avoid conflicts in what we ship, but that's tangential here.)  We = would
also have per-user profiles that allow for system-wide things to be
= disabled/enabled and allows for per-user bundle installation.  Doe= s this
make sense?

Thanks,

Andrew
(See attached file: signature.asc)_____________________= __________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev

= --2__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC-- --1__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <2__=SCtYqtNbX8rRHvef@NWxUxqmKJBdCO6sQ> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --1__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC Content-type: image/gif; name="pic29885.gif" Content-Disposition: inline; filename="pic29885.gif" Content-ID: <3__=SCtYqtNbX8rRHvef@NWxUxqmKJBdCO6sQ> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --1__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <4__=SCtYqtNbX8rRHvef@NWxUxqmKJBdCO6sQ> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --1__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC-- --0__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC Content-type: application/octet-stream; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-ID: <1__=SCtYqtNbX8rRHvef@NWxUxqmKJBdCO6sQ> Content-transfer-encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuNyAoR05V L0xpbnV4KQ0KDQppRDhEQlFCR3VLM2wzeWpOam91K2IwSVJBb3lEQUo0ay84M3FlNit2QUU1WjBx Q3F2Rk0xRDJQd213Q2ZTcWNHDQp2MFJsWFlXbzhnR09EVkZQT1RMTXc1MD0NCj05a2VXDQotLS0t LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --0__=09BBF9A3DFF1D2DC8f9e8a93df938690918c09BBF9A3DFF1D2DC-- From Jeff_TTczmgW07z/8fKPW@YHvLZjvCTR1Igv9U Fri Aug 10 15:48:20 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by mail.eclipse.org (Postfix) with SMTP id 712551ECDB; Fri, 10 Aug 2007 15:48:19 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7AJkNWG015049; Fri, 10 Aug 2007 15:46:23 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l7AJkNH9484506; Fri, 10 Aug 2007 15:46:23 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7AJkNdR030864; Fri, 10 Aug 2007 15:46:23 -0400 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7AJkNl1030845; Fri, 10 Aug 2007 15:46:23 -0400 To: Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg, bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Jeff McAffer Message-ID: Date: Fri, 10 Aug 2007 15:46:21 -0400 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 08/10/2007 15:46:23, Serialize complete at 08/10/2007 15:46:23 Content-Type: multipart/alternative; boundary="=_alternative 006C915D85257333_=" Cc: Subject: [provisioning-dev] [prov] Equinox Provisioning M1a X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2007 19:48:21 -0000 This is a multipart message in MIME format. --=_alternative 006C915D85257333_= Content-Type: text/plain; charset="US-ASCII" M1 was so much fun we decided to do an M1a! That's right! A new and improved M1. Actually, all we did was fix a couple issues and restructure everything on top of Eclipse 3.4 M1 which came out today. Rather then adding a bunch of M1a information we updated last week's M1 pages http://wiki.eclipse.org/Equinox_Provisioning_M1 to point to the new agent download etc. and removed the old downloads. If you are just kicking the tires, M1 is likely sufficient. If you are going to do anything more comprehensive we suggest that you move to M1a. The Equinox Provisioning Team --=_alternative 006C915D85257333_= Content-Type: text/html; charset="US-ASCII"
M1 was so much fun we decided to do an M1a!  That's right!  A new and improved M1.  Actually, all we did was fix a couple issues and restructure everything on top of Eclipse 3.4 M1 which came out today.  Rather then adding a bunch of M1a information we updated last week's M1 pages
        http://wiki.eclipse.org/Equinox_Provisioning_M1
to point to the new agent download etc. and removed the old downloads.  If you are just kicking the tires, M1 is likely sufficient.  If you are going to do anything more comprehensive we suggest that you move to M1a.

The Equinox Provisioning Team --=_alternative 006C915D85257333_=-- From Jeff_TTczmgW07z/8fKPW@YHvLZjvCTR1Igv9U Tue Sep 11 07:59:33 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by mail.eclipse.org (Postfix) with SMTP id 0A21923718; Tue, 11 Sep 2007 07:59:31 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l8BBuZcQ007700; Tue, 11 Sep 2007 07:56:35 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l8BBuaiq548690; Tue, 11 Sep 2007 07:56:36 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l8BBuZYG011883; Tue, 11 Sep 2007 07:56:35 -0400 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l8BBuZtA011880; Tue, 11 Sep 2007 07:56:35 -0400 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg, iI2puDUXZVvuJVwf@XzQPvII7mdsgt6xg, Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Jeff McAffer Message-ID: Date: Tue, 11 Sep 2007 07:56:05 -0400 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 09/11/2007 07:56:07, Serialize complete at 09/11/2007 07:56:07 Content-Type: multipart/alternative; boundary="=_alternative 0041980685257353_=" Cc: Subject: [provisioning-dev] Provisioning Symposium at Eclipse Summit Europe X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 11:59:34 -0000 This is a multipart message in MIME format. --=_alternative 0041980685257353_= Content-Type: text/plain; charset="US-ASCII" First off, the Eclipse Summit Europe is coming and is looking like a great event. http://eclipsesummit.org/summiteurope2007/ Last year there were a series of very cool symposia during the conference. This year that set has been expanded and now occupy a full day prior to the main event. http://eclipsesummit.org/summiteurope2007/index.php?page=tuesday/ Tim Webb (Maya) and I are hosting a Provisioning Symposium with the intention of following on from the Ganymede Provisioning workshop held in the spring. That workshop was very successful as a context-setting and initial direction setting effort. Several key connections were made and fruit of those connections has been born. In the intervening months both the Equinox provisioning effort (now called "p2") and Maya have made progress and much code has been written. This symposium brings together committers and interested parties to report on and evaluate current provisioning initiatives, sketch efficient and practical solutions to real provisioning problems and identify opportunities for cooperation. http://eclipsesummit.org/summiteurope2007/index.php?page=detail/&id=5 The symposium is structured as a relatively informal gathering where the focus is on discussion, not presentation. To facilitate that discussion we are asking potential participants to send in a position paper describing their interests. This does not have to be anything fancy or long. Just outline what your use cases, interests, code, ... See the symposium description for more details. http://eclipsesummit.org/summiteurope2007/index.php?page=symposiaformat/ Hope to see you there. Jeff/Tim --=_alternative 0041980685257353_= Content-Type: text/html; charset="US-ASCII"
First off, the Eclipse Summit Europe is coming and is looking like a great event.
        http://eclipsesummit.org/summiteurope2007/

Last year there were a series of very cool symposia during the conference.  This year that set has been expanded and now occupy a full day prior to the main event.
        http://eclipsesummit.org/summiteurope2007/index.php?page=tuesday/

Tim Webb (Maya) and I are hosting a Provisioning  Symposium with the intention of following on from the Ganymede Provisioning workshop held in the spring.  That workshop was very successful as a context-setting and initial direction setting effort.  Several key connections were made and fruit of those connections has been born.  In the intervening months both the Equinox provisioning effort (now called "p2") and Maya have made progress and much code has been written.  This symposium brings together committers and interested parties to report on and evaluate current provisioning initiatives, sketch efficient and practical solutions to real provisioning problems and identify opportunities for cooperation.
        http://eclipsesummit.org/summiteurope2007/index.php?page=detail/&id=5

The symposium is structured as a relatively informal gathering where the focus is on discussion, not presentation.  To facilitate that discussion we are asking potential participants to send in a position paper describing their interests.  This does not have to be anything fancy or long.  Just outline what your use cases, interests, code, ...  See the symposium description for more details.
        http://eclipsesummit.org/summiteurope2007/index.php?page=symposiaformat/

Hope to see you there.

Jeff/Tim --=_alternative 0041980685257353_=-- From X7faejM8ZSuiOyKw@BlQYHhHFTc++u3d/ Fri Sep 21 18:05:18 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from genuitec.com (genuitec.com [209.135.140.128]) by mail.eclipse.org (Postfix) with SMTP id A878237F39; Fri, 21 Sep 2007 18:05:18 -0400 (EDT) Received: from [192.168.0.223] (c-24-218-241-63.hsd1.ma.comcast.net [24.218.241.63]) by genuitec.com (8.13.1/8.13.1) with ESMTP id l8LM5HNF002708; Fri, 21 Sep 2007 17:05:17 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Timothy Webb Date: Fri, 21 Sep 2007 18:05:17 -0400 To: iI2puDUXZVvuJVwf@XzQPvII7mdsgt6xg, bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailer: Apple Mail (2.752.3) Cc: Subject: [provisioning-dev] Name change coming to Maya X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 22:05:19 -0000 Hi all, Looks like we are going to be changing the name of the Maya project. The long and short is that it turns out we do not have clear trademark rights to use the Maya name and we need to find an alternative in quick order. I've setup a wiki page at the link below and would appreciate any suggestions that may come to mind -- even if you don't think your option is perfect, putting it up may well help foster brainstorming. :) http://wiki.eclipse.org/New_Names_for_M--- I greatly appreciate your help in coming up with some viable options. Thanks! Tim From YgyQFOCWM9g4uOl/@QdoDIVO2IbNTSwBe Fri Sep 21 19:04:00 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by mail.eclipse.org (Postfix) with SMTP id 6097937ED0; Fri, 21 Sep 2007 19:03:59 -0400 (EDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l8LN40j1028194; Fri, 21 Sep 2007 16:04:00 -0700 (PDT) Received: from ism-mail03.corp.ad.wrs.com ([128.224.200.20]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 16:04:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [provisioning-dev] Name change coming to Maya Date: Sat, 22 Sep 2007 01:03:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] Name change coming to Maya Thread-Index: Acf8m4gO34Uy7/w5Q9K1a3G6BAxOnQAB6WvQ References: From: "Scharf, Michael" To: "Developer discussions for provisioning (Update Manager)initiatives" , X-OriginalArrivalTime: 21 Sep 2007 23:04:00.0354 (UTC) FILETIME=[B23CB420:01C7FCA3] Cc: X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 23:04:01 -0000 I added some names to the webpage. The main criterion was to be google unique (or almost google unique) Some google unique names (assuming that google unique names have no trademark): * maylipse http://www.google.com/search?q=3Dmaylipse * mayalipse http://www.google.com/search?q=3Dmayalipse * maynstaller http://www.google.com/search?q=3Dmaynstaller * maynstall http://www.google.com/search?q=3Dmaynstall * mayastall http://www.google.com/search?q=3Dmayastall * mayaploy http://www.google.com/search?q=3Dmayaploy * maynotfail http://www.google.com/search?q=3Dmaynotfail Some (almost) google unique names: * maydeploy http://www.google.com/search?q=3Dmaydeploy * maclipse http://www.google.com/search?q=3Dmaclipse * melipse http://www.google.com/search?q=3Dmelipse * mayayam http://www.google.com/search?q=3Dmayayam=20 * mapaya http://www.google.com/search?q=3Dmapaya * maquaya http://www.google.com/search?q=3Dmaquaya Michael --=20 Michael Scharf, Wind River direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805=20 > -----Original Message----- > From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg=20 > [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of=20 > Timothy Webb > Sent: Saturday, 22 September, 2007 00:05 > To: iI2puDUXZVvuJVwf@XzQPvII7mdsgt6xg; bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > Subject: [provisioning-dev] Name change coming to Maya >=20 > Hi all, >=20 > Looks like we are going to be changing the name of the Maya=20 > project. =20 > The long and short is that it turns out we do not have clear =20 > trademark rights to use the Maya name and we need to find an =20 > alternative in quick order. I've setup a wiki page at the=20 > link below =20 > and would appreciate any suggestions that may come to mind --=20 > even if =20 > you don't think your option is perfect, putting it up may well help =20 > foster brainstorming. :) >=20 > http://wiki.eclipse.org/New_Names_for_M--- >=20 > I greatly appreciate your help in coming up with some viable options. >=20 > Thanks! > Tim > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev >=20 From YgyQFOCWM9g4uOl/@QdoDIVO2IbNTSwBe Fri Sep 21 19:28:26 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by mail.eclipse.org (Postfix) with SMTP id 1A7D32789F; Fri, 21 Sep 2007 19:28:25 -0400 (EDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l8LNSQng003033; Fri, 21 Sep 2007 16:28:26 -0700 (PDT) Received: from ism-mail03.corp.ad.wrs.com ([128.224.200.20]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 16:28:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [provisioning-dev] Name change coming to Maya Date: Sat, 22 Sep 2007 01:28:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] Name change coming to Maya Thread-Index: Acf8m4gO34Uy7/w5Q9K1a3G6BAxOnQAC33BA References: From: "Scharf, Michael" To: "Developer discussions for provisioning (Update Manager)initiatives" , X-OriginalArrivalTime: 21 Sep 2007 23:28:26.0479 (UTC) FILETIME=[1C1D9FF0:01C7FCA7] Cc: X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 23:28:28 -0000 I created a bugzilla entry: https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D204340 I think bugzilla is much better to keep track of the discussion than email or wiki... Michael --=20 Michael Scharf, Wind River direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805=20 > -----Original Message----- > From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg=20 > [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of=20 > Timothy Webb > Sent: Saturday, 22 September, 2007 00:05 > To: iI2puDUXZVvuJVwf@XzQPvII7mdsgt6xg; bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > Subject: [provisioning-dev] Name change coming to Maya >=20 > Hi all, >=20 > Looks like we are going to be changing the name of the Maya=20 > project. =20 > The long and short is that it turns out we do not have clear =20 > trademark rights to use the Maya name and we need to find an =20 > alternative in quick order. I've setup a wiki page at the=20 > link below =20 > and would appreciate any suggestions that may come to mind --=20 > even if =20 > you don't think your option is perfect, putting it up may well help =20 > foster brainstorming. :) >=20 > http://wiki.eclipse.org/New_Names_for_M--- >=20 > I greatly appreciate your help in coming up with some viable options. >=20 > Thanks! > Tim > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev >=20 From co+hcxZiZ8nFYYJP@pk9v0MQ7qJVM9hDX Sat Sep 22 12:32:07 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from genuitec.com (genuitec.com [209.135.140.128]) by mail.eclipse.org (Postfix) with SMTP id 4529A2BDF9 for ; Sat, 22 Sep 2007 12:32:06 -0400 (EDT) Received: from Genuitec1111 (pool-72-64-66-236.dllstx.fios.verizon.net [72.64.66.236]) by genuitec.com (8.13.1/8.13.1) with ESMTP id l8MGW1rF013553 for ; Sat, 22 Sep 2007 11:32:03 -0500 Message-ID: <03b101c7fd36$1738acc0$0301a8c0@Genuitec1111> From: "Todd Williams" To: References: Date: Sat, 22 Sep 2007 11:31:55 -0500 Organization: Genuitec, LLC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Subject: [provisioning-dev] Re: provisioning-dev Digest, Vol 6, Issue 2 X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 16:32:07 -0000 OK, I added three more. Keep them coming. Todd ----- Original Message ----- From: To: Sent: Saturday, September 22, 2007 11:00 AM Subject: [work] provisioning-dev Digest, Vol 6, Issue 2 > Send provisioning-dev mailing list submissions to > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > > To subscribe or unsubscribe via the World Wide Web, visit > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > or, via email, send a message with subject or body 'help' to > k7NFCUegXHl0KIPq@XzQPvII7mdsgt6xg > > You can reach the person managing the list at > Z7PYsTmFXcLcT/Av@XzQPvII7mdsgt6xg > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of provisioning-dev digest..." > > > Today's Topics: > > 1. Name change coming to Maya (Timothy Webb) > 2. RE: Name change coming to Maya (Scharf, Michael) > 3. RE: Name change coming to Maya (Scharf, Michael) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Sep 2007 18:05:17 -0400 > From: Timothy Webb > Subject: [provisioning-dev] Name change coming to Maya > To: iI2puDUXZVvuJVwf@XzQPvII7mdsgt6xg, bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > Message-ID: > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Hi all, > > Looks like we are going to be changing the name of the Maya project. > The long and short is that it turns out we do not have clear > trademark rights to use the Maya name and we need to find an > alternative in quick order. I've setup a wiki page at the link below > and would appreciate any suggestions that may come to mind -- even if > you don't think your option is perfect, putting it up may well help > foster brainstorming. :) > > http://wiki.eclipse.org/New_Names_for_M--- > > I greatly appreciate your help in coming up with some viable options. > > Thanks! > Tim > > > ------------------------------ > > Message: 2 > Date: Sat, 22 Sep 2007 01:03:54 +0200 > From: "Scharf, Michael" > Subject: RE: [provisioning-dev] Name change coming to Maya > To: "Developer discussions for provisioning (Update > Manager)initiatives" , > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > I added some names to the webpage. The main criterion > was to be google unique (or almost google unique) > > Some google unique names (assuming that google unique names have no > trademark): > * maylipse http://www.google.com/search?q=maylipse > * mayalipse http://www.google.com/search?q=mayalipse > * maynstaller http://www.google.com/search?q=maynstaller > * maynstall http://www.google.com/search?q=maynstall > * mayastall http://www.google.com/search?q=mayastall > * mayaploy http://www.google.com/search?q=mayaploy > * maynotfail http://www.google.com/search?q=maynotfail > Some (almost) google unique names: > * maydeploy http://www.google.com/search?q=maydeploy > * maclipse http://www.google.com/search?q=maclipse > * melipse http://www.google.com/search?q=melipse > * mayayam http://www.google.com/search?q=mayayam > * mapaya http://www.google.com/search?q=mapaya > * maquaya http://www.google.com/search?q=maquaya > > > Michael > > -- > Michael Scharf, Wind River > direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805 > >> -----Original Message----- >> From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg >> [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of >> Timothy Webb >> Sent: Saturday, 22 September, 2007 00:05 >> To: iI2puDUXZVvuJVwf@XzQPvII7mdsgt6xg; bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg >> Subject: [provisioning-dev] Name change coming to Maya >> >> Hi all, >> >> Looks like we are going to be changing the name of the Maya >> project. >> The long and short is that it turns out we do not have clear >> trademark rights to use the Maya name and we need to find an >> alternative in quick order. I've setup a wiki page at the >> link below >> and would appreciate any suggestions that may come to mind -- >> even if >> you don't think your option is perfect, putting it up may well help >> foster brainstorming. :) >> >> http://wiki.eclipse.org/New_Names_for_M--- >> >> I greatly appreciate your help in coming up with some viable options. >> >> Thanks! >> Tim >> _______________________________________________ >> provisioning-dev mailing list >> bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg >> https://dev.eclipse.org/mailman/listinfo/provisioning-dev >> > > > ------------------------------ > > Message: 3 > Date: Sat, 22 Sep 2007 01:28:20 +0200 > From: "Scharf, Michael" > Subject: RE: [provisioning-dev] Name change coming to Maya > To: "Developer discussions for provisioning (Update > Manager)initiatives" , > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > I created a bugzilla entry: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=204340 > > I think bugzilla is much better to keep track of the discussion than > email or wiki... > > Michael > > -- > Michael Scharf, Wind River > direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805 > >> -----Original Message----- >> From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg >> [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of >> Timothy Webb >> Sent: Saturday, 22 September, 2007 00:05 >> To: iI2puDUXZVvuJVwf@XzQPvII7mdsgt6xg; bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg >> Subject: [provisioning-dev] Name change coming to Maya >> >> Hi all, >> >> Looks like we are going to be changing the name of the Maya >> project. >> The long and short is that it turns out we do not have clear >> trademark rights to use the Maya name and we need to find an >> alternative in quick order. I've setup a wiki page at the >> link below >> and would appreciate any suggestions that may come to mind -- >> even if >> you don't think your option is perfect, putting it up may well help >> foster brainstorming. :) >> >> http://wiki.eclipse.org/New_Names_for_M--- >> >> I greatly appreciate your help in coming up with some viable options. >> >> Thanks! >> Tim >> _______________________________________________ >> provisioning-dev mailing list >> bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg >> https://dev.eclipse.org/mailman/listinfo/provisioning-dev >> > > > ------------------------------ > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev > > > End of provisioning-dev Digest, Vol 6, Issue 2 > ********************************************** > From X7faejM8ZSuiOyKw@BlQYHhHFTc++u3d/ Fri Sep 28 10:37:16 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from genuitec.com (genuitec.com [209.135.140.128]) by mail.eclipse.org (Postfix) with SMTP id 888A737F99; Fri, 28 Sep 2007 10:36:59 -0400 (EDT) Received: from [192.168.0.223] (c-24-218-241-63.hsd1.ma.comcast.net [24.218.241.63]) by genuitec.com (8.13.1/8.13.1) with ESMTP id l8SEakQU028558; Fri, 28 Sep 2007 09:36:47 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Timothy Webb Date: Fri, 28 Sep 2007 10:36:50 -0400 To: iI2puDUXZVvuJVwf@XzQPvII7mdsgt6xg X-Mailer: Apple Mail (2.752.3) Cc: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Subject: [provisioning-dev] Maya to be known as Maynstall X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2007 14:37:17 -0000 We are officially going ahead with the name change from Maya to Maynstall. I've posted a blog entry at our new blog below: http://dev.eclipse.org/blogs/maynstall/ The foundation has done a trademark search and we are good to go with this name. The first step will be to change the web presence and then in parallel we will begin the task of changing the APIs and plug- ins as needed. I am aware of at least a couple code bases built on top of Maya and I would like to check for any other that we should be made aware of. Please add to the related bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=204912 Thanks for your support in helping get the name out there. Cheers, Tim From YgyQFOCWM9g4uOl/@QdoDIVO2IbNTSwBe Fri Sep 28 11:57:51 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by mail.eclipse.org (Postfix) with SMTP id 7BFA6382E8; Fri, 28 Sep 2007 11:57:49 -0400 (EDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l8SFvm91022691; Fri, 28 Sep 2007 08:57:48 -0700 (PDT) Received: from ism-mail03.corp.ad.wrs.com ([128.224.200.20]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 08:57:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [provisioning-dev] Maya to be known as Maynstall Date: Fri, 28 Sep 2007 17:57:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] Maya to be known as Maynstall Thread-Index: AcgB3R7eWoO3ZoduTfuy3WhSEivCFwACm5xg References: From: "Scharf, Michael" To: "Developer discussions for provisioning (Update Manager)initiatives" , X-OriginalArrivalTime: 28 Sep 2007 15:57:48.0392 (UTC) FILETIME=[510D3680:01C801E8] Cc: X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2007 15:57:51 -0000 I am happy to see that one of the names of my little=20 brainstorming was chosen :-) I think is a good decision to take one of the Google unique names. Overloaded names (like "eclipse") make it hard to find project related information..... Michael > -----Original Message----- > From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg=20 > [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of=20 > Timothy Webb > Sent: Friday, 28 September, 2007 16:37 > To: iI2puDUXZVvuJVwf@XzQPvII7mdsgt6xg > Cc: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > Subject: [provisioning-dev] Maya to be known as Maynstall >=20 > We are officially going ahead with the name change from Maya to =20 > Maynstall. I've posted a blog entry at our new blog below: >=20 > http://dev.eclipse.org/blogs/maynstall/ >=20 > The foundation has done a trademark search and we are good to=20 > go with =20 > this name. The first step will be to change the web presence and =20 > then in parallel we will begin the task of changing the APIs=20 > and plug-=20 > ins as needed. I am aware of at least a couple code bases built on =20 > top of Maya and I would like to check for any other that we=20 > should be =20 > made aware of. Please add to the related bug: >=20 > https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D204912 >=20 > Thanks for your support in helping get the name out there. >=20 > Cheers, > Tim > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev >=20 From diRgzxqRkzMYfO5J@IyiOGdeyptTmzuMP Mon Oct 1 03:42:12 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from smtprelay11.ispgateway.de (smtprelay11.ispgateway.de [80.67.29.28]) by mail.eclipse.org (Postfix) with SMTP id 6AAE1379BB for ; Mon, 1 Oct 2007 03:42:11 -0400 (EDT) Received: (qmail 1937 invoked from network); 1 Oct 2007 07:42:03 -0000 Received: from unknown (HELO [192.168.100.11]) (383542@[195.143.217.178]) (envelope-sender ) by smtprelay11.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 1 Oct 2007 07:42:03 -0000 Message-ID: Date: Mon, 01 Oct 2007 09:43:29 +0200 From: Joerg von Frantzius User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Enigmail-Version: 0.95.3 Content-Type: multipart/mixed; boundary="------------040502000507000801010404" Subject: [provisioning-dev] EPP packages for LInux x86_64? X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 07:42:13 -0000 This is a multi-part message in MIME format. --------------040502000507000801010404 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Hi,

I learned that the EPP project builds those nice packages from the Europa release train plugins. Unfortunately, there are no builds for Linux x86_64, but I read in eclipse.foundation that those could be created if there was demand from the community.

I'd be happy to download, use every day and so test a J2EE build for x86_64.

Regards,
Jörg


--------------040502000507000801010404 Content-Type: text/x-vcard; charset=utf-8; name="joerg.von.frantzius.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="joerg.von.frantzius.vcf" begin:vcard fn;quoted-printable:J=C3=B6rg von Frantzius n;quoted-printable:von Frantzius;J=C3=B6rg org:artnology GmbH adr:;;Milastr. 4;Berlin;;10437;Germany email;internet:diRgzxqRkzMYfO5J@IyiOGdeyptTmzuMP title:Software Architect tel;work:+49 (30) 443 50 99 26 tel;fax:+49 (30) 443 50 99 99 x-mozilla-html:TRUE version:2.1 end:vcard --------------040502000507000801010404-- From b01NNcLhHUZeEP70@EOCq6JOAWVtjPI0r Mon Oct 1 04:43:15 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mail.eclipse.org (Postfix) with SMTP id A27A522F95 for ; Mon, 1 Oct 2007 04:43:01 -0400 (EDT) Received: from [212.227.126.203] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1IcGrb-0008Aq-00 for bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg; Mon, 01 Oct 2007 10:42:51 +0200 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1IcGrD-0000gl-0B for bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg; Mon, 01 Oct 2007 10:42:27 +0200 Received: from xchgfe04.exchange.xchg ([172.23.1.53]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 10:42:07 +0200 Received: from mk.ka.innoopract ([217.8.59.30]) by xchgfe04.exchange.xchg with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 10:42:07 +0200 From: Markus Knauer Organization: Innoopract Informationssysteme GmbH To: "Developer discussions for provisioning \(Update Manager\) initiatives" Subject: Re: [provisioning-dev] EPP packages for LInux x86_64? Date: Mon, 1 Oct 2007 10:42:04 +0200 User-Agent: KMail/1.9.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: X-OriginalArrivalTime: 01 Oct 2007 08:42:07.0382 (UTC) FILETIME=[F308E360:01C80406] X-Provags-ID: kundenserver.de mFit/2ULPjzYnh9d@uAVsZ3wjdw/a/1s6 ident:@172.23.1.26 X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 08:43:17 -0000 Hi Joerg, let's see what I can do... I'll report soon about it. Markus On Monday 01 October 2007 09:43, Joerg von Frantzius wrote: > Hi, > > I learned that the EPP project builds those nice packages from the Europa > release train plugins. Unfortunately, there are no builds for Linux x86_6= 4, > but I read in eclipse.foundation that those could be created if there was > demand from the community. > > I'd be happy to download, use every day and so test a J2EE build for > x86_64. > > Regards, > J=C3=B6rg From b01NNcLhHUZeEP70@EOCq6JOAWVtjPI0r Mon Oct 1 10:58:58 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by mail.eclipse.org (Postfix) with SMTP id 8F54F237F3 for ; Mon, 1 Oct 2007 10:58:56 -0400 (EDT) Received: from [212.227.126.203] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1IcMjW-0005Mo-00 for bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg; Mon, 01 Oct 2007 16:58:54 +0200 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1IcMig-0001fk-03 for bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg; Mon, 01 Oct 2007 16:58:02 +0200 Received: from xchgfe05.exchange.xchg ([172.23.1.55]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 16:57:56 +0200 Received: from mk.ka.innoopract ([217.8.59.30]) by xchgfe05.exchange.xchg with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 16:57:55 +0200 From: Markus Knauer Organization: Innoopract Informationssysteme GmbH To: "Developer discussions for provisioning \(Update Manager\) initiatives" Subject: Re: [provisioning-dev] EPP packages for LInux x86_64? Date: Mon, 1 Oct 2007 16:57:52 +0200 User-Agent: KMail/1.9.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: X-OriginalArrivalTime: 01 Oct 2007 14:57:56.0194 (UTC) FILETIME=[732C8C20:01C8043B] X-Provags-ID: kundenserver.de mFit/2ULPjzYnh9d@uAVsZ3wjdw/a/1s6 ident:@172.23.1.26 X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 14:58:59 -0000 If you wanna test... the new test packages are currently distributed to the= =20 different Eclipse mirrors, so do not expect that every mirror is working. Anyway, here is the EPP download URL: http://www.eclipse.org/epp/download.p= hp Please report here in this mailing list or (even better) write bug reports = in=20 bugzilla. Cheers, Markus On Monday 01 October 2007 10:42, Markus Knauer wrote: > Hi Joerg, > > let's see what I can do... I'll report soon about it. > > Markus > > On Monday 01 October 2007 09:43, Joerg von Frantzius wrote: > > Hi, > > > > I learned that the EPP project builds those nice packages from the > > Europa release train plugins. Unfortunately, there are no builds for > > Linux x86_64, but I read in eclipse.foundation that those could be > > created if there was demand from the community. > > > > I'd be happy to download, use every day and so test a J2EE build for > > x86_64. > > > > Regards, > > J=C3=B6rg From diRgzxqRkzMYfO5J@IyiOGdeyptTmzuMP Mon Oct 1 11:11:04 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.18.44]) by mail.eclipse.org (Postfix) with SMTP id C012C2C4EE for ; Mon, 1 Oct 2007 11:10:59 -0400 (EDT) Received: (qmail 16989 invoked from network); 1 Oct 2007 15:10:56 -0000 Received: from unknown (HELO [192.168.100.11]) (383542@[195.143.217.178]) (envelope-sender ) by smtprelay06.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 1 Oct 2007 15:10:56 -0000 Message-ID: Date: Mon, 01 Oct 2007 17:12:24 +0200 From: Joerg von Frantzius User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] EPP packages for LInux x86_64? References: In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: multipart/mixed; boundary="------------050100080909090901060502" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 15:11:07 -0000 This is a multi-part message in MIME format. --------------050100080909090901060502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Markus,

thanks for creating the package! The download is coming in here at ~ 10KB/s, so don't expect feedback from me too soon ;)

Regards,
Jörg

Markus Knauer schrieb:

If you wanna test... the new test packages are currently distributed to the 
different Eclipse mirrors, so do not expect that every mirror is working.

Anyway, here is the EPP download URL: http://www.eclipse.org/epp/download.php

Please report here in this mailing list or (even better) write bug reports in 
bugzilla.

Cheers,
Markus

On Monday 01 October 2007 10:42, Markus Knauer wrote:
  
Hi Joerg,

let's see what I can do... I'll report soon about it.

Markus

On Monday 01 October 2007 09:43, Joerg von Frantzius wrote:
    
 Hi,

 I learned that the EPP project builds those nice packages from the
Europa release train plugins. Unfortunately, there are no builds for
Linux x86_64, but I read in eclipse.foundation that those could be
created if there was demand from the community.

 I'd be happy to download, use every day and so test a J2EE build for
x86_64.

 Regards,
 Jörg
      
_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev


  

--------------050100080909090901060502 Content-Type: text/x-vcard; charset=utf-8; name="joerg.von.frantzius.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="joerg.von.frantzius.vcf" YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6Sj1DMz1CNnJnIHZvbiBGcmFudHpp dXMNCm47cXVvdGVkLXByaW50YWJsZTp2b24gRnJhbnR6aXVzO0o9QzM9QjZyZw0Kb3JnOmFy dG5vbG9neSBHbWJIDQphZHI6OztNaWxhc3RyLiA0O0Jlcmxpbjs7MTA0Mzc7R2VybWFueQ0K ZW1haWw7aW50ZXJuZXQ6am9lcmcudm9uLmZyYW50eml1c0BhcnRub2xvZ3kuY29tDQp0aXRs ZTpTb2Z0d2FyZSBBcmNoaXRlY3QNCnRlbDt3b3JrOis0OSAoMzApIDQ0MyA1MCA5OSAyNg0K dGVsO2ZheDorNDkgKDMwKSA0NDMgNTAgOTkgOTkNCngtbW96aWxsYS1odG1sOlRSVUUNCnZl cnNpb246Mi4xDQplbmQ6dmNhcmQNCg0K --------------050100080909090901060502-- From John_EljLatxtsXDP9738@YHvLZjvCTR1Igv9U Mon Oct 1 15:55:44 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by mail.eclipse.org (Postfix) with SMTP id A7F752BACD; Mon, 1 Oct 2007 15:55:43 -0400 (EDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l91JvCGb021972; Mon, 1 Oct 2007 15:57:12 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l91Jthj1316630; Mon, 1 Oct 2007 15:55:43 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l91JthDa012795; Mon, 1 Oct 2007 15:55:43 -0400 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l91JtgSc012783; Mon, 1 Oct 2007 15:55:43 -0400 To: Y8DYbDjzI0mDhc5Y@XzQPvII7mdsgt6xg, bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: John Arthorne Message-ID: Date: Mon, 1 Oct 2007 15:55:42 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 10/01/2007 15:55:43, Serialize complete at 10/01/2007 15:55:43 Content-Type: multipart/alternative; boundary="=_alternative 006D787185257367_=" Cc: Subject: [provisioning-dev] [p2] Wiki page reorg X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 19:55:45 -0000 This is a multipart message in MIME format. --=_alternative 006D787185257367_= Content-Type: text/plain; charset="US-ASCII" The wiki pages for p2 have been reorganized. Page titles now generally start with the prefix "Equinox p2". There is also a new "Equinox p2" category for all wiki pages relating to the p2 work. Categories in the wiki support multiple inheritance, so the "Equinox p2" category is a sub-category of both the "Equinox" category and the "Provisioning" category. You now only need to add the one category tag at the bottom of the page, and it will be reachable from both of the parent categories. For example, if the page title is "Equinox p2 Blort", the bottom of the page should have: [[Category:Equinox p2|Blort]] The part after the pipe character is just used to alphabetize the list of pages on the category page. Here is the current index of Equinox p2 wiki pages: http://wiki.eclipse.org/Category:Equinox_p2 --=_alternative 006D787185257367_= Content-Type: text/html; charset="US-ASCII"
The wiki pages for p2 have been reorganized. Page titles now generally start with the prefix "Equinox p2". There is also a new "Equinox p2" category for all wiki pages relating to the p2 work.  Categories in the wiki support multiple inheritance, so the "Equinox p2" category is a sub-category of both the "Equinox" category and the "Provisioning" category.  You now only need to add the one category tag at the bottom of the page, and it will be reachable from both of the parent categories. For example, if the page title is "Equinox p2 Blort", the bottom of the page should have:

[[Category:Equinox p2|Blort]]

The part after the pipe character is just used to alphabetize the list of pages on the category page. Here is the current index of Equinox p2 wiki pages:

http://wiki.eclipse.org/Category:Equinox_p2
--=_alternative 006D787185257367_=-- From diRgzxqRkzMYfO5J@IyiOGdeyptTmzuMP Thu Oct 18 10:45:50 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.18.44]) by mail.eclipse.org (Postfix) with SMTP id D3F58104A2B for ; Thu, 18 Oct 2007 10:45:48 -0400 (EDT) Received: (qmail 22085 invoked from network); 18 Oct 2007 14:45:48 -0000 Received: from unknown (HELO [192.168.100.11]) (383542@[195.143.217.178]) (envelope-sender ) by smtprelay06.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 18 Oct 2007 14:45:48 -0000 Message-ID: Date: Thu, 18 Oct 2007 16:48:08 +0200 From: Joerg von Frantzius User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] EPP packages for LInux x86_64? References: In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: multipart/mixed; boundary="------------020509060700090600090702" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 14:45:51 -0000 This is a multi-part message in MIME format. --------------020509060700090600090702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Alright, I almost forgot to mention it: the 20071001.testing-eclipse-jee-europa-fall-linux.gtk.x86_64.tar.gz package works fine for me.

Wouldn't it be possible to put all architectures into one package, with different launchers for each?

Markus Knauer schrieb:
If you wanna test... the new test packages are currently distributed to the 
different Eclipse mirrors, so do not expect that every mirror is working.

Anyway, here is the EPP download URL: http://www.eclipse.org/epp/download.php

Please report here in this mailing list or (even better) write bug reports in 
bugzilla.

Cheers,
Markus

On Monday 01 October 2007 10:42, Markus Knauer wrote:
  
Hi Joerg,

let's see what I can do... I'll report soon about it.

Markus

On Monday 01 October 2007 09:43, Joerg von Frantzius wrote:
    
 Hi,

 I learned that the EPP project builds those nice packages from the
Europa release train plugins. Unfortunately, there are no builds for
Linux x86_64, but I read in eclipse.foundation that those could be
created if there was demand from the community.

 I'd be happy to download, use every day and so test a J2EE build for
x86_64.

 Regards,
 Jörg
      
_______________________________________________
provisioning-dev mailing list
bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg
https://dev.eclipse.org/mailman/listinfo/provisioning-dev


  

--------------020509060700090600090702 Content-Type: text/x-vcard; charset=utf-8; name="joerg.von.frantzius.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="joerg.von.frantzius.vcf" YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6Sj1DMz1CNnJnIHZvbiBGcmFudHpp dXMNCm47cXVvdGVkLXByaW50YWJsZTp2b24gRnJhbnR6aXVzO0o9QzM9QjZyZw0Kb3JnOmFy dG5vbG9neSBHbWJIDQphZHI6OztNaWxhc3RyLiA0O0Jlcmxpbjs7MTA0Mzc7R2VybWFueQ0K ZW1haWw7aW50ZXJuZXQ6am9lcmcudm9uLmZyYW50eml1c0BhcnRub2xvZ3kuY29tDQp0aXRs ZTpTb2Z0d2FyZSBBcmNoaXRlY3QNCnRlbDt3b3JrOis0OSAoMzApIDQ0MyA1MCA5OSAyNg0K dGVsO2ZheDorNDkgKDMwKSA0NDMgNTAgOTkgOTkNCngtbW96aWxsYS1odG1sOlRSVUUNCnZl cnNpb246Mi4xDQplbmQ6dmNhcmQNCg0K --------------020509060700090600090702-- From FkJqwWsCkGROpO8g@b0C/ARcn5yziq/5u Fri Nov 30 08:05:11 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from hotelroom3.mainloop.net (hotelroom3.mainloop.net [192.71.58.59]) by mail.eclipse.org (Postfix) with SMTP id DD1E713DC15 for ; Fri, 30 Nov 2007 08:05:08 -0500 (EST) Received: (qmail 22410 invoked from network); 30 Nov 2007 14:05:07 +0100 Received: from 241-180-207-85.zapcechy.adsl-llu.static.bluetone.cz (HELO ?192.168.157.199?) (85.207.180.241) by www-hotelroom3.mainloop.net with SMTP; 30 Nov 2007 14:05:07 +0100 Message-ID: Date: Fri, 30 Nov 2007 14:05:06 +0100 From: Filip Hrbek Organization: Cloudsmith Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: [provisioning-dev] cssite 2765 X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2007 13:05:12 -0000 Update your staging area too - there are API changes! Improved mapper wizard / mapper tabs documentation system - minor text corrections - automatic field display control (everything is now driven by the mappers, not by mysterious rules, constants and expressions in the cssite java & xhtml code) - removed obsolete tooltips on mapper tabs (should be replaced with rich tooltips in future) Filip From FkJqwWsCkGROpO8g@b0C/ARcn5yziq/5u Fri Nov 30 09:28:32 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from hotelroom3.mainloop.net (hotelroom3.mainloop.net [192.71.58.59]) by mail.eclipse.org (Postfix) with SMTP id 47EAC349CC for ; Fri, 30 Nov 2007 09:28:30 -0500 (EST) Received: (qmail 16742 invoked from network); 30 Nov 2007 15:28:29 +0100 Received: from 241-180-207-85.zapcechy.adsl-llu.static.bluetone.cz (HELO ?192.168.157.199?) (85.207.180.241) by www-hotelroom3.mainloop.net with SMTP; 30 Nov 2007 15:28:29 +0100 Message-ID: Date: Fri, 30 Nov 2007 15:28:28 +0100 From: Filip Hrbek Organization: Cloudsmith Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Developer discussions for provisioning (Update Manager) initiatives" Subject: Re: [provisioning-dev] cssite 2765 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2007 14:28:32 -0000 My apology - this mail should have been sent somewhere else! You really don't have to update anything :-) Filip Filip Hrbek wrote: > Update your staging area too - there are API changes! > > Improved mapper wizard / mapper tabs documentation system > > - minor text corrections > - automatic field display control (everything is now driven by the > mappers, not by mysterious rules, constants and expressions in the > cssite java & xhtml code) > - removed obsolete tooltips on mapper tabs (should be replaced with > rich tooltips in future) > > Filip > > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev From Hdsuv5idQ0ouV2BM@nQ09UH3BU9qHQzjU Tue Dec 11 09:46:07 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mail.fit.fraunhofer.de (mail.fit.fraunhofer.de [129.26.165.170]) by mail.eclipse.org (Postfix) with SMTP id 0022134370; Tue, 11 Dec 2007 09:46:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.fit.fraunhofer.de (Postfix) with ESMTP id 4FE875491DF; Tue, 11 Dec 2007 15:46:02 +0100 (CET) Received: from mail.fit.fraunhofer.de ([129.26.165.170]) by localhost (mail.fit.fraunhofer.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23329-01; Tue, 11 Dec 2007 15:46:01 +0100 (CET) Received: from [141.99.157.115] (unknown [141.99.157.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.fit.fraunhofer.de (Postfix) with ESMTP id BD0F653E729; Tue, 11 Dec 2007 15:46:00 +0100 (CET) Message-ID: Date: Tue, 11 Dec 2007 15:45:57 +0100 From: Gunnar Stevens User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Content-Type: multipart/alternative; boundary="------------040908010108010001080406" X-Virus-Scanned: by amavisd-new at fit.fraunhofer.de Cc: Mfh2NEkylSW8jBRc@XzQPvII7mdsgt6xg Subject: [provisioning-dev] Equinox p2 M3: Configure startup parameters of a profile X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 14:46:08 -0000 This is a multi-part message in MIME format. --------------040908010108010001080406 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit I have tried out the Admin UI, but for me it was not possible to assembling different plugins to a new application. My idea was to create a new profile and integrating several IUs and than switch the current Admin UI RCP to this new profile or start the new profile (although such an action is missing). In that way, I become aware of a missing functionality of the P2 Admin: At the moment the Admin UI support the user to build a new Eclipse profile by integrating different IU (mainly the replacement of old site.xml, feature.xml & plugin manifest.mf, etc). But to start such a new profile, I think also some extra configuration effort is needed. E.g. my new profile has different 'product plugins' therefore someone must say in someway, which is the 'main plugin' and has to do also some extra work. So, form a user experience perspective, I'm interested if there any design ideas for this issue exists (e.g. integrating a config.ini editor and/or wizard and/or provide a pre-configuration as an IU?). Thanks Gunnar Stevens -- Gunnar Stevens Fraunhofer Institute for Applied Information Technology (FhG-FIT) Schloss Birlinghoven Office C5-116 53754 Sankt Augustin Germany Fon: +49 (02241) 14-2847 Fax: +49 (02241) 14-2146 --------------040908010108010001080406 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable

I have tried out the Admin UI, but for me it was not possible to assembling different plugins to a new application. My idea was to create a new profile and integrating several IUs and than switch the current Admin UI RCP to this new profile or start the new profile (although such an action is missing). <= /p>

In that way, I become aware of a missing functionality of the P2 Admin: At the moment the Admin UI support the user to build a new Eclipse profile by integrating different IU (mainly the replacement of old site.xml, feature.xml & plugin manifest.mf, etc).

But to start such a new profile, I think also some extra configuration effort is needed. E.g. my new profile has different ‘product plugins’ t= herefore someone must say in someway, which is the ‘main plugin’ and has to do= also some extra work.

So, for= m a user experience perspective, I’m interested if there any design ideas fo= r this issue exists (e.g. integrating a config.ini editor and/or wizard and/or provide a pre-configuration as an IU?).
=A0

Thanks<= /span>

= Gunnar Stevens

--=20
Gunnar Stevens

Fraunhofer Institute for Applied Information Technology (FhG-FIT)

Schloss Birlinghoven
Office C5-116
53754 Sankt Augustin
Germany

Fon: +49 (02241) 14-2847
Fax: +49 (02241) 14-2146 
--------------040908010108010001080406-- From John_EljLatxtsXDP9738@YHvLZjvCTR1Igv9U Thu Dec 13 10:03:42 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by mail.eclipse.org (Postfix) with SMTP id 7A40B35C8A for ; Thu, 13 Dec 2007 10:03:40 -0500 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lBDF3fgp005078 for ; Thu, 13 Dec 2007 10:03:41 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lBDF3erf488374 for ; Thu, 13 Dec 2007 10:03:40 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lBDF3eE8003087 for ; Thu, 13 Dec 2007 10:03:40 -0500 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lBDF3eps003044 for ; Thu, 13 Dec 2007 10:03:40 -0500 In-Reply-To: To: "Developer discussions for provisioning \(Update Manager\) initiatives" MIME-Version: 1.0 Subject: Re: [provisioning-dev] Equinox p2 M3: Configure startup parameters of a profile X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: John Arthorne Message-ID: Date: Thu, 13 Dec 2007 10:03:40 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 12/13/2007 10:03:41, Serialize complete at 12/13/2007 10:03:41 Content-Type: multipart/alternative; boundary="=_alternative 0052BBFA852573B0_=" X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 15:03:43 -0000 This is a multipart message in MIME format. --=_alternative 0052BBFA852573B0_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhpcyBraW5kIG9mIGZ1bmN0aW9uYWxpdHkgaXMgYSBiaXQgb3V0IG9mIHNjb3BlIGZvciB0aGUg YWRtaW4gVUkgcmlnaHQgDQpub3cuIFRoZXJlIGFyZSBsb3dlciBsZXZlbCB0b29scywgcGFydGlj dWxhcmx5IGFuIGFwcGxpY2F0aW9uL2FudCB0YXNrIA0KY2FsbGVkIHRoZSAiZ2VuZXJhdG9yIiB0 aGF0IGNhbiBiZSB1c2VkIHRvIGFzc2VtYmxlIHlvdXIgb3duIGFwcGxpY2F0aW9uLCANCmJ1dCBu byBVSS1sZXZlbCB0b29scyB5ZXQuIFRoZSBraW5kIG9mIGZ1bmN0aW9uYWxpdHkgeW91J3JlIGxv b2tpbmcgZm9yIA0Kd2lsbCBsaWtlbHkgZW5kIHVwIHN1cmZhY2luZyBhcyBwYXJ0IG9mIFBERSAo UGx1Zy1pbiBEZXZlbG9wbWVudCANCkVudmlyb25tZW50KSwgd2hpY2ggaXMgc3RhcnRpbmcgdG8g aW5jb3Jwb3JhdGUgdG9vbGluZyBmb3IgcDIgbWV0YWRhdGEgYW5kIA0KYXJ0aWZhY3RzLg0KDQpK b2huDQoNCkd1bm5hciBTdGV2ZW5zIHdyb3RlIG9uIDEyLzExLzIwMDcgMDk6NDU6NTcgQU06DQoN Cj4gSSBoYXZlIHRyaWVkIG91dCB0aGUgQWRtaW4gVUksIGJ1dCBmb3IgbWUgaXQgd2FzIG5vdCBw b3NzaWJsZSB0byANCj4gYXNzZW1ibGluZyBkaWZmZXJlbnQgcGx1Z2lucyB0byBhIG5ldyBhcHBs aWNhdGlvbi4gTXkgaWRlYSB3YXMgdG8gDQo+IGNyZWF0ZSBhIG5ldyBwcm9maWxlIGFuZCBpbnRl Z3JhdGluZyBzZXZlcmFsIElVcyBhbmQgdGhhbiBzd2l0Y2ggdGhlDQo+IGN1cnJlbnQgQWRtaW4g VUkgUkNQIHRvIHRoaXMgbmV3IHByb2ZpbGUgb3Igc3RhcnQgdGhlIG5ldyBwcm9maWxlIA0KPiAo YWx0aG91Z2ggc3VjaCBhbiBhY3Rpb24gaXMgbWlzc2luZykuIA0KPiBJbiB0aGF0IHdheSwgSSBi ZWNvbWUgYXdhcmUgb2YgYSBtaXNzaW5nIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIFAyIA0KPiBBZG1p bjogQXQgdGhlIG1vbWVudCB0aGUgQWRtaW4gVUkgc3VwcG9ydCB0aGUgdXNlciB0byBidWlsZCBh IG5ldyANCj4gRWNsaXBzZSBwcm9maWxlIGJ5IGludGVncmF0aW5nIGRpZmZlcmVudCBJVSAobWFp bmx5IHRoZSByZXBsYWNlbWVudCANCj4gb2Ygb2xkIHNpdGUueG1sLCBmZWF0dXJlLnhtbCAmIHBs dWdpbiBtYW5pZmVzdC5tZiwgZXRjKS4gDQo+IEJ1dCB0byBzdGFydCBzdWNoIGEgbmV3IHByb2Zp bGUsIEkgdGhpbmsgYWxzbyBzb21lIGV4dHJhIA0KPiBjb25maWd1cmF0aW9uIGVmZm9ydCBpcyBu ZWVkZWQuIEUuZy4gbXkgbmV3IHByb2ZpbGUgaGFzIGRpZmZlcmVudCANCj4g4oCYcHJvZHVjdCBw bHVnaW5z4oCZIHRoZXJlZm9yZSBzb21lb25lIG11c3Qgc2F5IGluIHNvbWV3YXksIHdoaWNoIGlz IA0KPiB0aGUg4oCYbWFpbiBwbHVnaW7igJkgYW5kIGhhcyB0byBkbyBhbHNvIHNvbWUgZXh0cmEg d29yay4NCj4gU28sIGZvcm0gYSB1c2VyIGV4cGVyaWVuY2UgcGVyc3BlY3RpdmUsIEnigJltIGlu dGVyZXN0ZWQgaWYgdGhlcmUgYW55IA0KPiBkZXNpZ24gaWRlYXMgZm9yIHRoaXMgaXNzdWUgZXhp c3RzIChlLmcuIGludGVncmF0aW5nIGEgY29uZmlnLmluaSANCj4gZWRpdG9yIGFuZC9vciB3aXph cmQgYW5kL29yIHByb3ZpZGUgYSBwcmUtY29uZmlndXJhdGlvbiBhcyBhbiBJVT8pLg0KPiAgDQo+ IFRoYW5rcw0KPiBHdW5uYXIgU3RldmVucyANCj4gLS0gDQo+IEd1bm5hciBTdGV2ZW5zDQo+IA0K PiBGcmF1bmhvZmVyIEluc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBUZWNobm9sb2d5 IChGaEctRklUKQ0KPiANCj4gU2NobG9zcyBCaXJsaW5naG92ZW4NCj4gT2ZmaWNlIEM1LTExNg0K PiA1Mzc1NCBTYW5rdCBBdWd1c3Rpbg0KPiBHZXJtYW55DQo+IA0KPiBGb246ICs0OSAoMDIyNDEp IDE0LTI4NDcNCj4gRmF4OiArNDkgKDAyMjQxKSAxNC0yMTQ2IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHByb3Zpc2lvbmluZy1kZXYgbWFpbGluZyBs aXN0DQo+IHByb3Zpc2lvbmluZy1kZXZAZWNsaXBzZS5vcmcNCj4gaHR0cHM6Ly9kZXYuZWNsaXBz ZS5vcmcvbWFpbG1hbi9saXN0aW5mby9wcm92aXNpb25pbmctZGV2DQoNCg== --=_alternative 0052BBFA852573B0_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoaXMga2luZCBvZiBmdW5jdGlv bmFsaXR5IGlzIGEgYml0DQpvdXQgb2Ygc2NvcGUgZm9yIHRoZSBhZG1pbiBVSSByaWdodCBub3cu IFRoZXJlIGFyZSBsb3dlciBsZXZlbCB0b29scywgcGFydGljdWxhcmx5DQphbiBhcHBsaWNhdGlv bi9hbnQgdGFzayBjYWxsZWQgdGhlICZxdW90O2dlbmVyYXRvciZxdW90OyB0aGF0IGNhbiBiZSB1 c2VkDQp0byBhc3NlbWJsZSB5b3VyIG93biBhcHBsaWNhdGlvbiwgYnV0IG5vIFVJLWxldmVsIHRv b2xzIHlldC4gVGhlIGtpbmQgb2YNCmZ1bmN0aW9uYWxpdHkgeW91J3JlIGxvb2tpbmcgZm9yIHdp bGwgbGlrZWx5IGVuZCB1cCBzdXJmYWNpbmcgYXMgcGFydCBvZg0KUERFIChQbHVnLWluIERldmVs b3BtZW50IEVudmlyb25tZW50KSwgd2hpY2ggaXMgc3RhcnRpbmcgdG8gaW5jb3Jwb3JhdGUNCnRv b2xpbmcgZm9yIHAyIG1ldGFkYXRhIGFuZCBhcnRpZmFjdHMuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Kb2huPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+R3VubmFyIFN0ZXZlbnMgd3JvdGUgb24gMTIvMTEvMjAwNyAwOTo0NTo1NyBB TTo8YnI+DQo8YnI+DQomZ3Q7IEkgaGF2ZSB0cmllZCBvdXQgdGhlIEFkbWluIFVJLCBidXQgZm9y IG1lIGl0IHdhcyBub3QgcG9zc2libGUgdG8gPGJyPg0KJmd0OyBhc3NlbWJsaW5nIGRpZmZlcmVu dCBwbHVnaW5zIHRvIGEgbmV3IGFwcGxpY2F0aW9uLiBNeSBpZGVhIHdhcyB0bw0KPGJyPg0KJmd0 OyBjcmVhdGUgYSBuZXcgcHJvZmlsZSBhbmQgaW50ZWdyYXRpbmcgc2V2ZXJhbCBJVXMgYW5kIHRo YW4gc3dpdGNoIHRoZTxicj4NCiZndDsgY3VycmVudCBBZG1pbiBVSSBSQ1AgdG8gdGhpcyBuZXcg cHJvZmlsZSBvciBzdGFydCB0aGUgbmV3IHByb2ZpbGUNCjxicj4NCiZndDsgKGFsdGhvdWdoIHN1 Y2ggYW4gYWN0aW9uIGlzIG1pc3NpbmcpLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgSW4gdGhhdCB3YXksIEkgYmVjb21lIGF3YXJlIG9mIGEgbWlzc2luZyBmdW5jdGlv bmFsaXR5DQpvZiB0aGUgUDIgPGJyPg0KJmd0OyBBZG1pbjogQXQgdGhlIG1vbWVudCB0aGUgQWRt aW4gVUkgc3VwcG9ydCB0aGUgdXNlciB0byBidWlsZCBhIG5ldw0KPGJyPg0KJmd0OyBFY2xpcHNl IHByb2ZpbGUgYnkgaW50ZWdyYXRpbmcgZGlmZmVyZW50IElVIChtYWlubHkgdGhlIHJlcGxhY2Vt ZW50DQo8YnI+DQomZ3Q7IG9mIG9sZCBzaXRlLnhtbCwgZmVhdHVyZS54bWwgJmFtcDsgcGx1Z2lu IG1hbmlmZXN0Lm1mLCBldGMpLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgQnV0IHRvIHN0YXJ0IHN1Y2ggYSBuZXcgcHJvZmlsZSwgSSB0aGluayBhbHNvDQpzb21lIGV4 dHJhIDxicj4NCiZndDsgY29uZmlndXJhdGlvbiBlZmZvcnQgaXMgbmVlZGVkLiBFLmcuIG15IG5l dyBwcm9maWxlIGhhcyBkaWZmZXJlbnQNCjxicj4NCiZndDsg4oCYcHJvZHVjdCBwbHVnaW5z4oCZ IHRoZXJlZm9yZSBzb21lb25lIG11c3Qgc2F5IGluIHNvbWV3YXksIHdoaWNoIGlzDQo8YnI+DQom Z3Q7IHRoZSDigJhtYWluIHBsdWdpbuKAmSBhbmQgaGFzIHRvIGRvIGFsc28gc29tZSBleHRyYSB3 b3JrLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBTbywgZm9ybSBhIHVz ZXIgZXhwZXJpZW5jZSBwZXJzcGVjdGl2ZSwgSeKAmW0NCmludGVyZXN0ZWQgaWYgdGhlcmUgYW55 IDxicj4NCiZndDsgZGVzaWduIGlkZWFzIGZvciB0aGlzIGlzc3VlIGV4aXN0cyAoZS5nLiBpbnRl Z3JhdGluZyBhIGNvbmZpZy5pbmkNCjxicj4NCiZndDsgZWRpdG9yIGFuZC9vciB3aXphcmQgYW5k L29yIHByb3ZpZGUgYSBwcmUtY29uZmlndXJhdGlvbiBhcyBhbiBJVT8pLjxicj4NCiZndDsgJm5i c3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoYW5rczwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBHdW5uYXIgU3RldmVucyA8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgLS0gPGJyPg0KJmd0OyBHdW5uYXIgU3RldmVu czxicj4NCiZndDsgPGJyPg0KJmd0OyBGcmF1bmhvZmVyIEluc3RpdHV0ZSBmb3IgQXBwbGllZCBJ bmZvcm1hdGlvbiBUZWNobm9sb2d5IChGaEctRklUKTxicj4NCiZndDsgPGJyPg0KJmd0OyBTY2hs b3NzIEJpcmxpbmdob3Zlbjxicj4NCiZndDsgT2ZmaWNlIEM1LTExNjxicj4NCiZndDsgNTM3NTQg U2Fua3QgQXVndXN0aW48YnI+DQomZ3Q7IEdlcm1hbnk8YnI+DQomZ3Q7IDxicj4NCiZndDsgRm9u OiArNDkgKDAyMjQxKSAxNC0yODQ3PGJyPg0KJmd0OyBGYXg6ICs0OSAoMDIyNDEpIDE0LTIxNDYg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 IHByb3Zpc2lvbmluZy1kZXYgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBwcm92aXNpb25pbmctZGV2 QGVjbGlwc2Uub3JnPGJyPg0KJmd0OyBodHRwczovL2Rldi5lY2xpcHNlLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Byb3Zpc2lvbmluZy1kZXY8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 0052BBFA852573B0_=-- From X7faejM8ZSuiOyKw@BlQYHhHFTc++u3d/ Tue Dec 18 15:21:47 2007 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from genuitec.com (genuitec.com [209.135.140.128]) by mail.eclipse.org (Postfix) with SMTP id 2F34242F8C; Tue, 18 Dec 2007 15:21:46 -0500 (EST) Received: from [192.168.0.223] (c-24-218-241-63.hsd1.ma.comcast.net [24.218.241.63]) by genuitec.com (8.13.1/8.13.1) with ESMTP id lBIKLkME019619; Tue, 18 Dec 2007 14:21:46 -0600 Message-Id: From: Timothy Webb To: Maynstall Developers List Content-Type: multipart/alternative; boundary=Apple-Mail-44-658774481 Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 18 Dec 2007 15:21:46 -0500 X-Mailer: Apple Mail (2.915) Cc: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Subject: [provisioning-dev] [maynstall] [prov] Migration of Maynstall to p2 work is beginning X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2007 20:21:47 -0000 --Apple-Mail-44-658774481 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit As a heads-up to those interested in provisioning, we are beginning work on utilizing p2 as part of Maynstall. To track work in this area, we will be using the following BZ for discussions with other BZs created off of it as appropriate: https://bugs.eclipse.org/bugs/show_bug.cgi?id=213361 To aide in this work, Jed Anderson (Genuitec) who has been working on Maynstall behind the scenes will be coming on board as a committer (voting wrapping up shortly). All development work will be done off of the HEAD of the Maynstall source repository. During this work, we should also be switching over to EclipseLink as the underlying database technology (in place of TopLink Essentials). Thanks, Tim --Apple-Mail-44-658774481 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit As a heads-up to those interested in provisioning, we are beginning work on utilizing p2 as part of Maynstall.

To track work in this area, we will be using the following BZ for discussions with other BZs created off of it as appropriate:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=213361

To aide in this work, Jed Anderson (Genuitec) who has been working on Maynstall behind the scenes will be coming on board as a committer (voting wrapping up shortly).

All development work will be done off of the HEAD of the Maynstall source repository.  During this work, we should also be switching over to EclipseLink as the underlying database technology (in place of TopLink Essentials).

Thanks,
Tim
--Apple-Mail-44-658774481-- From FuCY0HCeXKUXamBz@QdoDIVO2IbNTSwBe Mon Jan 14 14:38:28 2008 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by mail.eclipse.org (Postfix) with SMTP id 9C74046B99 for ; Mon, 14 Jan 2008 14:38:25 -0500 (EST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m0EJcNJx019256 for ; Mon, 14 Jan 2008 11:38:23 -0800 (PST) Received: from ala-mail08.corp.ad.wrs.com ([147.11.57.145]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 11:38:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C856E5.05DB181E" Date: Mon, 14 Jan 2008 11:38:22 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hi from the new guy Thread-Index: AchW5QWePVkutztQS8GIRyaqRpba6Q== From: "Schaefer, Doug" To: X-OriginalArrivalTime: 14 Jan 2008 19:38:22.0743 (UTC) FILETIME=[05F3EA70:01C856E5] Subject: [provisioning-dev] Hi from the new guy X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 19:38:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C856E5.05DB181E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey gang, =20 As you may have read in my blog, I'm now managing the install and licensing team at Wind River. My first task is to help come up with a vision for managing installations of Wind River's products and, of course, I'm very interested in what's happening with the Eclipse provisioning projects. =20 I'm going through the p2 wiki to learn what I can. If there's more information you think I might find useful, please let me know. =20 Thanks, Doug Schaefer Engineering Manager, Wind River Systems and Eclipse CDT Project Lead ------_=_NextPart_001_01C856E5.05DB181E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hey=20 gang,
 
As you = may have read=20 in my blog, I'm now managing the install and licensing team at Wind = River. My=20 first task is to help come up with a vision for managing installations = of Wind=20 River's products and, of course, I'm very interested in what's happening = with=20 the Eclipse provisioning projects.
 
I'm = going through=20 the p2 wiki to learn what I can. If there's more information you think=20 I might find useful, please let me know.
 
Thanks,
Doug Schaefer
Engineering Manager, = Wind River=20 Systems
and Eclipse CDT = Project=20 Lead
------_=_NextPart_001_01C856E5.05DB181E-- From Pascal_nZARQQd5G+POZmzf@YHvLZjvCTR1Igv9U Mon Jan 14 15:13:37 2008 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by mail.eclipse.org (Postfix) with SMTP id 72FA436F30; Mon, 14 Jan 2008 15:13:35 -0500 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m0EKFQeW030864; Mon, 14 Jan 2008 15:15:26 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0EKDaq5096838; Mon, 14 Jan 2008 15:13:36 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m0EKDaJm011118; Mon, 14 Jan 2008 15:13:36 -0500 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m0EKDZaf011044; Mon, 14 Jan 2008 15:13:36 -0500 In-Reply-To: References: Subject: Re: [provisioning-dev] Hi from the new guy To: "Developer discussions for provisioning \(Update Manager\) initiatives" Cc: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg, fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg X-Mailer: Lotus Notes Release 8.0 August 02, 2007 Message-ID: From: Pascal Rapicault Date: Mon, 14 Jan 2008 15:16:38 -0500 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 01/14/2008 15:13:37 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 20:13:38 -0000 Welcome ! This week we are running a meeting marathon http://wiki.eclipse.org/Equinox_p2_Meeting_Week_Jan_14-18_2008 to decide what we want to ship in 1.0. If you are interested in joining any of these, please chime in on the equinox-dev mailing list. PaScaL |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |"Schaefer, Doug" | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |01/14/2008 02:38 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[provisioning-dev] Hi from the new guy | >--------------------------------------------------------------------------------------------------------------------------------------------------| Hey gang, As you may have read in my blog, I'm now managing the install and licensing team at Wind River. My first task is to help come up with a vision for managing installations of Wind River's products and, of course, I'm very interested in what's happening with the Eclipse provisioning projects. I'm going through the p2 wiki to learn what I can. If there's more information you think I might find useful, please let me know. Thanks, Doug Schaefer Engineering Manager, Wind River Systems and Eclipse CDT Project Lead_______________________________________________ provisioning-dev mailing list bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg https://dev.eclipse.org/mailman/listinfo/provisioning-dev From FuCY0HCeXKUXamBz@QdoDIVO2IbNTSwBe Mon Jan 14 15:18:29 2008 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by mail.eclipse.org (Postfix) with SMTP id 53B68360B6 for ; Mon, 14 Jan 2008 15:18:28 -0500 (EST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m0EKIT5q001049 for ; Mon, 14 Jan 2008 12:18:29 -0800 (PST) Received: from ala-mail08.corp.ad.wrs.com ([147.11.57.145]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 12:18:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [provisioning-dev] Hi from the new guy Date: Mon, 14 Jan 2008 12:18:28 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provisioning-dev] Hi from the new guy Thread-Index: AchW6f889veiAm4QRoG+UAVZlY30fwAAI1Ew References: From: "Schaefer, Doug" To: "Developer discussions for provisioning (Update Manager)initiatives" X-OriginalArrivalTime: 14 Jan 2008 20:18:28.0291 (UTC) FILETIME=[9FC56930:01C856EA] X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 20:18:30 -0000 Thanks Pascal, I'm also in meetings this week but will try to keep an eye on what's happening. Cheers, Doug =20 > -----Original Message----- > From: fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg=20 > [mailto:fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg] On Behalf Of=20 > Pascal Rapicault > Sent: Monday, January 14, 2008 3:17 PM > To: Developer discussions for provisioning (Update Manager)=20 > initiatives > Cc: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg; fX0bdaz/PWJBlrNu@XzQPvII7mdsgt6xg > Subject: Re: [provisioning-dev] Hi from the new guy >=20 > Welcome ! This week we are running a meeting marathon > http://wiki.eclipse.org/Equinox_p2_Meeting_Week_Jan_14-18_2008 > to decide what we want to ship in 1.0. > If you are interested in joining any of these, please chime=20 > in on the equinox-dev mailing list. >=20 > PaScaL >=20 >=20 > |------------> > | From: | > |------------> > =20 > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| > |"Schaefer, Doug" =20 > =20 > | > =20 > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| > |------------> > | To: | > |------------> > =20 > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| > | =20 > =20 > | > =20 > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| > |------------> > | Date: | > |------------> > =20 > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| > |01/14/2008 02:38 PM =20 > =20 > | > =20 > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| > |------------> > | Subject: | > |------------> > =20 > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| > |[provisioning-dev] Hi from the new guy =20 > =20 > | > =20 > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| >=20 >=20 >=20 >=20 >=20 > Hey gang, >=20 > As you may have read in my blog, I'm now managing the install=20 > and licensing team at Wind River. My first task is to help=20 > come up with a vision for managing installations of Wind=20 > River's products and, of course, I'm very interested in=20 > what's happening with the Eclipse provisioning projects. >=20 > I'm going through the p2 wiki to learn what I can. If there's=20 > more information you think I might find useful, please let me know. >=20 > Thanks, > Doug Schaefer > Engineering Manager, Wind River Systems > and Eclipse CDT Project=20 > Lead_______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev >=20 >=20 > _______________________________________________ > provisioning-dev mailing list > bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg > https://dev.eclipse.org/mailman/listinfo/provisioning-dev >=20 From dpXq3MrXkRlp3Rb9@RgofA6Na+BoXv9wI Sat May 10 04:50:04 2008 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mail.eclipse.org (Postfix) with SMTP id 9D1D73C6E8 for ; Sat, 10 May 2008 04:50:02 -0400 (EDT) Received: by wf-out-1314.google.com with SMTP id 28so1795514wfc.18 for ; Sat, 10 May 2008 01:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=XfjW6N/SxMIQm6/e7bARj6nYNvflkskK0RbLPi/F2bk=; b=U8tsZGFjmPYZ10rzZNlq7g/g1db8KEh3Se0x0W1Ax2G8iiCsxnnlvQ603gL+Hmm10nkxiNLgQiuH51R++iZksjXDbzkWoDGQmFua4UP1JYcrmv3ugUrUFJjnC7tC599TVsohRgwzENGHk3s6Qux5ULc6wYLf+kbAtyXGbOo1V2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=LAhFkMpMGuLXmlyc1nXL23A2M3Iymly8tVL9QPSPBmovKp5uMhVtQP7ktvAv5msgNltUBSpLIN2JgNqujlRZA87G71ZZLdbEGU5+mEXNfRSV2j8Uy7I5p7SuYEiNNSVvn/yG7eTB68TEm7qJ+XOK1SNkyiFbsnZZksbWwv6sxVM= Received: by 10.142.53.13 with SMTP id b13mr2338171wfa.258.1210409402586; Sat, 10 May 2008 01:50:02 -0700 (PDT) Received: by 10.142.13.19 with HTTP; Sat, 10 May 2008 01:50:02 -0700 (PDT) Message-ID: Date: Sat, 10 May 2008 09:50:02 +0100 From: "gary thompson" To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7319_7365513.1210409402578" Subject: [provisioning-dev] installer failure amd64 ubuntu gutsy X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 08:50:05 -0000 ------=_Part_7319_7365513.1210409402578 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all I tried downloading the p2 eclipse installer for Ganymede m7 and running it on an amd64 ubuntu 7.10 installation. However, it just ran and did nothing. I guess this is a bug, should i report it if so where and is there any other information that I need to forward? regards gary nb java -version java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) ------=_Part_7319_7365513.1210409402578 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all
I tried downloading the p2 eclipse installer for Ganymede m7 and running it on an amd64 ubuntu 7.10 installation. However, it just ran and did nothing. I guess this is a bug, should i report it if so where and is there any other information that I need to forward?


regards
gary

nb

java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)

------=_Part_7319_7365513.1210409402578-- From Pascal_nZARQQd5G+POZmzf@YHvLZjvCTR1Igv9U Mon Jul 14 19:57:03 2008 Return-Path: X-Original-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Delivered-To: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by mail.eclipse.org (Postfix) with SMTP id 9D0EC149173; Mon, 14 Jul 2008 19:57:03 -0400 (EDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6ENv4N9021658; Mon, 14 Jul 2008 19:57:04 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6ENv4lm233316; Mon, 14 Jul 2008 19:57:04 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6ENv4Rn012098; Mon, 14 Jul 2008 19:57:04 -0400 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6ENv3Es012089; Mon, 14 Jul 2008 19:57:04 -0400 To: Equinox development mailing list , "Developer discussions for provisioning \(Update Manager\) initiatives" X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: Pascal Rapicault Date: Mon, 14 Jul 2008 20:01:30 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 07/14/2008 19:57:03 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFE15DF10D0E68f9e8a93df938690918c0ABBFE15DF10D0E6" Content-Disposition: inline Cc: Subject: [provisioning-dev] [prov] p2 mailing list created X-BeenThere: bXzS9kgiBpQc+PW7@XzQPvII7mdsgt6xg X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Id: "Developer discussions for provisioning \(Update Manager\) initiatives" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2008 23:57:04 -0000 --0__=0ABBFE15DF10D0E68f9e8a93df938690918c0ABBFE15DF10D0E6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable To the request of the p2 community, a p2 specific mailing list has been= created and is now available at rh5hrW0Xnopbw3ac@XzQPvII7mdsgt6xg. You can register at= https://dev.eclipse.org/mailman/listinfo/p2-dev See you there, PaScaL= --0__=0ABBFE15DF10D0E68f9e8a93df938690918c0ABBFE15DF10D0E6 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

To the request of the p2 community, a p2 specific mailing list has b= een created and is now available at rh5hrW0Xnopbw3ac@XzQPvII7mdsgt6xg. You can registe= r at https:= //dev.eclipse.org/mailman/listinfo/p2-dev
See you there,

PaScaL= --0__=0ABBFE15DF10D0E68f9e8a93df938690918c0ABBFE15DF10D0E6--