From sacadmin Fri Jul 18 14:54:47 2008 Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6ILsl8n004078; Fri, 18 Jul 2008 14:54:47 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m6ILsl2K024559; Fri, 18 Jul 2008 14:54:47 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m6ILslx2024555; Fri, 18 Jul 2008 14:54:47 -0700 (PDT) Date: Fri, 18 Jul 2008 14:54:47 -0700 (PDT) From: Danek Duvall Message-Id: <200807182154.m6ILslx2024555@zruty.sfbay.sun.com> To: LSARC-record@sac.sfbay.sun.com Subject: SWT (Standard Widget Toolkit) [LSARC/2008/462 FastTrack timeout 07/28/2008] Status: RO Content-Length: 570 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: SWT (Standard Widget Toolkit) 1.2. Name of Document Author/Supplier: Author: Harshal Patil 1.3 Date of This Document: 18 July, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW / JDS 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From danek.duvall@sun.com Fri Jul 18 14:58:12 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6ILwCt6004228 for ; Fri, 18 Jul 2008 14:58:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6ILwBqC012885 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 18 Jul 2008 14:58:12 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4800I0V2D0Z700@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 18 Jul 2008 14:58:12 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4800AI62CZLBB0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 18 Jul 2008 14:58:11 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6ILwAnj039879; Fri, 18 Jul 2008 14:58:10 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m6ILw9wq024584; Fri, 18 Jul 2008 14:58:09 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m6ILw9rL024583; Fri, 18 Jul 2008 14:58:09 -0700 (PDT) Date: Fri, 18 Jul 2008 14:58:09 -0700 From: Danek Duvall Subject: SWT (Standard Widget Toolkit) (LSARC/2008/462) To: lsarc-ext@sun.com Cc: Harshal Patil Message-id: <20080718215809.GY15656@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1960 I'm sponsoring the following case for Harshal Patil. This case is intended to support the Azureus (soon to be Vuze) bittorrent client, the case for which should be running soon. It would also enable Eclipse to be integrated. I'm not satisfied with the materials as they are, but Harshal asked that I run the case anyway, and re-ask my questions on the record. So here it is. The case times out on Monday, July 28, 2008. Danek ====================================================================== Summary ======= SWT is an open source widget toolkit for Java designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented. SWT is release under Eclipse Public License. This project requests a minor release binding, requires minor changes in makefile. it will be added in SFW as SUNWswt. Interfaces ========== Stability classification Uncommitted for all exported interfaces. Man pages are included in the case materials directory. Exported Interfaces ------------------- /usr/lib/swt/swt.jar /usr/lib/swt/swt-debug.jar /usr/lib/swt/libswt-pi-gtk-3349.so /usr/lib/swt/libswt-gtk-3349.so /usr/lib/swt/libswt-gnome-gtk-3349.so /usr/lib/swt/libswt-cde-gtk-3349.so /usr/lib/swt/libswt-cairo-gtk-3349.so /usr/lib/swt/libswt-awt-gtk-3349.so /usr/lib/swt/libswt-atk-gtk-3349.so Since this is a shared lib, the numbers before .so don't matter.. even if we later upgrade this lib, all the apps depending on it will not be affected. What those apps will look for is to load libs like swt-atk-gtk etc. Imported Interfaces (Following are the dependacies while compiling the SWT, they are not require to use SWT, one can install pre-compiled SWT without these packages) ------------------- SUNWcairomm SUNWpng SUNWxwinc SUNWgnome-common-devel Reference Documents =================== [1] http://www.eclipse.org/swt/ [2] http://en.wikipedia.org/wiki/Standard_Widget_Toolkit From danek.duvall@sun.com Fri Jul 18 15:17:07 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6IMH6Kn004768 for ; Fri, 18 Jul 2008 15:17:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6IMH1Ap019454 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 18 Jul 2008 23:17:05 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4800J0538GUK00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 18 Jul 2008 15:17:04 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4800A3L38GL3B0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 18 Jul 2008 15:17:04 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6IMH24p049492; Fri, 18 Jul 2008 15:17:02 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m6IMH2B1025042; Fri, 18 Jul 2008 15:17:02 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m6IMH24w025041; Fri, 18 Jul 2008 15:17:02 -0700 (PDT) Date: Fri, 18 Jul 2008 15:17:01 -0700 From: Danek Duvall Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <20080718215809.GY15656@zruty.sfbay.sun.com> To: Harshal Patil Cc: lsarc-ext@sun.com Message-id: <20080718221701.GZ15656@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 2000 > Stability classification Uncommitted for all exported interfaces. Man > pages are included in the case materials directory. Please send me those man pages, and I will put them in the case directory. > Exported Interfaces > ------------------- > > /usr/lib/swt/swt.jar > /usr/lib/swt/swt-debug.jar I believe that Public jar files on Solaris tend to go into /usr/share/lib, or a subdirectory thereof, though if this is where most other systems place the jar files, they should be made available here, even if only via a symlink. Though I'll note that at least on ubuntu, it's in /usr/lib/java. > /usr/lib/swt/libswt-pi-gtk-3349.so > /usr/lib/swt/libswt-gtk-3349.so > /usr/lib/swt/libswt-gnome-gtk-3349.so > /usr/lib/swt/libswt-cde-gtk-3349.so > /usr/lib/swt/libswt-cairo-gtk-3349.so > /usr/lib/swt/libswt-awt-gtk-3349.so > /usr/lib/swt/libswt-atk-gtk-3349.so > > Since this is a shared lib, the numbers before .so don't matter. This isn't even remotely true. Those numbers are baked into every executable that links against them, so if the library names change, anything linked against them will break. However, if these libraries are intended only to be dlopen()ed by the Java code in the SWT jar files, then as long as those classes are changed whenever these libraries are, there's no issue. But then the libraries are Project Private, and not any form of Public. > Imported Interfaces (Following are the dependacies while compiling the SWT, > they are not require to use SWT, one can install pre-compiled SWT without > these packages) > ------------------- > SUNWcairomm > SUNWpng > SUNWxwinc > SUNWgnome-common-devel The build-time dependencies are (mostly) uninteresting here. We do care about the libraries that you're linking against. I would expect that libswt-atk-gtk-3349.so likely links against one or more gtk libraries and the atk library, and will require all of those to be present on the system at run-time. The others probably have similar dependencies. Danek From Harshal.Patil@Sun.COM Fri Jul 18 20:00:46 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6J30kQb008498 for ; Fri, 18 Jul 2008 20:00:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6J30jvJ014842 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 18 Jul 2008 20:00:46 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4800A01GD8K300@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 18 Jul 2008 20:00:44 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K48000NUGD7Z1A0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 18 Jul 2008 20:00:44 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6J31Bmo024119 for ; Sat, 19 Jul 2008 03:01:11 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K4800K01G94PV00@mail-apac.sun.com> (original mail from Harshal.Patil@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 19 Jul 2008 10:58:21 +0800 (SGT) Received: from [192.168.1.2] ([122.167.6.33]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4800BU5G97REZ1@mail-apac.sun.com>; Sat, 19 Jul 2008 10:58:21 +0800 (SGT) Date: Sat, 19 Jul 2008 08:30:41 +0530 From: Harshal Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <20080718221701.GZ15656@zruty.sfbay.sun.com> Sender: Harshal.Patil@Sun.COM To: Danek Duvall Cc: lsarc-ext@Sun.COM Message-id: <488158D9.3090409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> <20080718221701.GZ15656@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 4823 Danek Duvall wrote: >> Stability classification Uncommitted for all exported interfaces. Man >> pages are included in the case materials directory. > > Please send me those man pages, and I will put them in the case directory. Sorry, that line came by mistake. I can using example review for my reference. There are no man pages for using lib. I checked on ubuntu, they too are not shipping any man pages with libswt. > >> Exported Interfaces >> ------------------- >> >> /usr/lib/swt/swt.jar >> /usr/lib/swt/swt-debug.jar > > I believe that Public jar files on Solaris tend to go into /usr/share/lib, > or a subdirectory thereof, though if this is where most other systems place > the jar files, they should be made available here, even if only via a > symlink. Though I'll note that at least on ubuntu, it's in /usr/lib/java. The original package SWT for Solaris was in SFE repository under the name SFEswt. This package was not getting built on opensolaris as it was trying to look for /usr/dt which means files associated with CDE, which is no longer supported in OpenSolaris. Hence I started working on JDS project SUNWswt, which will get built on OpenSolaris and can be part of OpenSolaris repository. About the location of files in filesystem, I have not modified anything in spec file to build SUNWswt apart from removing calls for CDE based files. so the original author of that spec file was given a green signal to go ahead to create a SFE spec files with whatever locations were chosen. Original spec file can be found at, http://pkgbuild.svn.sourceforge.net/viewvc/pkgbuild/spec-files-extra/trunk/SFEswt.spec?revision=1223&view=markup > >> /usr/lib/swt/libswt-pi-gtk-3349.so >> /usr/lib/swt/libswt-gtk-3349.so >> /usr/lib/swt/libswt-gnome-gtk-3349.so >> /usr/lib/swt/libswt-cde-gtk-3349.so >> /usr/lib/swt/libswt-cairo-gtk-3349.so >> /usr/lib/swt/libswt-awt-gtk-3349.so >> /usr/lib/swt/libswt-atk-gtk-3349.so Please ignore the /usr/lib/swt/libswt-cde-gtk-3349.so from above list of files. As on OpenSolaris that file wont appear since CDE is not supported there. >> >> Since this is a shared lib, the numbers before .so don't matter. > > This isn't even remotely true. Those numbers are baked into every > executable that links against them, so if the library names change, > anything linked against them will break. > > However, if these libraries are intended only to be dlopen()ed by the Java > code in the SWT jar files, then as long as those classes are changed > whenever these libraries are, there's no issue. But then the libraries are > Project Private, and not any form of Public. Frankly I don't know much about shared libs. but I can tell you my experience. Say you have Azureus installed on your system. and I change the SWT lib version say from 3.3.1 to 3.3.2. This would mean that all the file names will change from *-3346.so to *-3349.so ... But I can still use Azureus without re-compiling or re-installing. for example, When an app requires a SWT lib (say swt-gtk), it searches for swt-gtk in swt.library.path, java.library.path or the jar file .. I have copy pasted how it looks on console in case you remove the SWT lib... Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-gtk-3346 or swt-gtk in swt.library.path, java.library.path or the jar file at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source) > >> Imported Interfaces (Following are the dependacies while compiling the SWT, >> they are not require to use SWT, one can install pre-compiled SWT without >> these packages) >> ------------------- >> SUNWcairomm >> SUNWpng >> SUNWxwinc >> SUNWgnome-common-devel > > The build-time dependencies are (mostly) uninteresting here. We do care > about the libraries that you're linking against. I would expect that > libswt-atk-gtk-3349.so likely links against one or more gtk libraries and > the atk library, and will require all of those to be present on the system > at run-time. The others probably have similar dependencies. > > Danek SWT is doesnt require java to run, however it does require following things, libswt-atk-gtk-3349.so: Requires - libatk-1.0.so.0 libgtk-x11-2.0.so.0 libswt-cairo-gtk-3349.so: Requires - libcairo.so.2 libswt-cde-gtk-3349.so: Requires - libXt.so.4 libX11.so.4 libDtSvc.so.1 libswt-gnome-gtk-3349.so: Requires - libgnomevfs-2.so.0 libgnome-2.so.0 libgnomeui-2.so.0 libswt-pi-gtk-3349.so: Requires - libgtk-x11-2.0.so.0 libgthread-2.0.so.0 libXtst.so.1 rest of the .so files don't show any dependencies. PS: sorry for all the trouble, I am very new to this work. --Harshal From Darren.Moffat@Sun.com Mon Jul 21 02:15:04 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6L9F3B0008499 for ; Mon, 21 Jul 2008 02:15:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m6L9Evgl008169 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 21 Jul 2008 17:15:02 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4C00I01N122L00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Mon, 21 Jul 2008 02:15:02 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4C0094EN10EVE0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Mon, 21 Jul 2008 02:15:00 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6L9ExYB004199 for ; Mon, 21 Jul 2008 09:14:59 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4C00H01IRIQN00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Mon, 21 Jul 2008 10:14:59 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4C005UJMMFKD70@fe-emea-10.sun.com>; Mon, 21 Jul 2008 10:07:10 +0100 (BST) Date: Mon, 21 Jul 2008 10:06:15 +0100 From: Darren J Moffat Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <20080718215809.GY15656@zruty.sfbay.sun.com> Sender: Darren.Moffat@Sun.com To: Danek Duvall Cc: lsarc-ext@Sun.com, Harshal Patil Message-id: <48845187.5020506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 1781 Danek Duvall wrote: > I'm sponsoring the following case for Harshal Patil. This case is intended > to support the Azureus (soon to be Vuze) bittorrent client, the case for > which should be running soon. It would also enable Eclipse to be > integrated. Yeah, I've spent far to much time in the last two weeks trying to build these libs for exactly that reason! > /usr/lib/swt/swt.jar Why are we hiding the main swt interface here ? Should this be somewhere more generic like /usr/share/lib/java/ > /usr/lib/swt/swt-debug.jar > /usr/lib/swt/libswt-pi-gtk-3349.so > /usr/lib/swt/libswt-gtk-3349.so > /usr/lib/swt/libswt-gnome-gtk-3349.so > /usr/lib/swt/libswt-cde-gtk-3349.so > /usr/lib/swt/libswt-cairo-gtk-3349.so > /usr/lib/swt/libswt-awt-gtk-3349.so > /usr/lib/swt/libswt-atk-gtk-3349.so > > Since this is a shared lib, the numbers before .so don't matter.. even if > we later upgrade this lib, all the apps depending on it will not be > affected. What those apps will look for is to load libs like swt-atk-gtk > etc. As Danek already pointed out the statement is clearly false. I'm also VERY concerned about this since the motivation for this case is Vuze which auto updates itself. I'm concerned that some future version of an autoupdate of Vuze will need a different version of SWT. How will that be dealt with [ Not the Vuze update but the future version of libswt ] ? Unless there is a plan to have multiple versions of SWT installed I see no reason to have the -3349 in the file names. Particularly since it is NOT present in the main swt.jar file; meaning it isn't possible with the layout presented in this case to have multiple versions of SWT. So just drop the -3349. What versions of the JRE does this SWT build support ? -- Darren J Moffat From Harshal.Patil@Sun.COM Mon Jul 21 03:29:14 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6LATDV9010205 for ; Mon, 21 Jul 2008 03:29:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m6LATCYo006246 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 21 Jul 2008 18:29:13 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4C00L0NQGL2500@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Mon, 21 Jul 2008 03:29:09 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4C00JTVQGJHC20@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Mon, 21 Jul 2008 03:29:08 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6LAUFDk020446 for ; Mon, 21 Jul 2008 10:30:15 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K4C00B01Q692K00@mail-apac.sun.com> (original mail from Harshal.Patil@Sun.COM) for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Mon, 21 Jul 2008 18:26:43 +0800 (SGT) Received: from [192.168.1.4] ([122.167.24.152]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4C00BVZQCIRE63@mail-apac.sun.com>; Mon, 21 Jul 2008 18:26:43 +0800 (SGT) Date: Mon, 21 Jul 2008 15:59:06 +0530 From: Harshal Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <48845187.5020506@Sun.COM> Sender: Harshal.Patil@Sun.COM To: Darren J Moffat Cc: Danek Duvall , lsarc-ext@Sun.COM Message-id: <488464F2.9090304@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> <48845187.5020506@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 3920 Darren J Moffat wrote: > Danek Duvall wrote: >> I'm sponsoring the following case for Harshal Patil. This case is >> intended >> to support the Azureus (soon to be Vuze) bittorrent client, the case for >> which should be running soon. It would also enable Eclipse to be >> integrated. > > Yeah, I've spent far to much time in the last two weeks trying to build > these libs for exactly that reason! I guess you are trying to build on OpenSolaris 2008.05. If yes, there is simple hack for it. get the spec file for SWT from spec-files-extra and search for this line, make -j$CPUS replace that line with following, make -j$CPUS -f make_solaris.mak JAVA_HOME=/usr/java make_swt make_atk make_awt make_cairo make_gnome This will remove the Dt dependency and your SWT will get built without Dt support. Resulting lib works fine with Vuze, I haven't checked it with Eclipse though. And this is all I am doing. That is why the questions like, this file should be in this directory puzzle me, because I haven't decided any of these file locations. I took to spec file from SFE and by doing the above mentioned trick, things worked for me. Does spec files submitted on spec-files-extra go through similar kind of Reviews? I don't know, I am just few days old in SUN. so may be I am missing something. > >> /usr/lib/swt/swt.jar > > Why are we hiding the main swt interface here ? > > Should this be somewhere more generic like /usr/share/lib/java/ > >> /usr/lib/swt/swt-debug.jar >> /usr/lib/swt/libswt-pi-gtk-3349.so >> /usr/lib/swt/libswt-gtk-3349.so >> /usr/lib/swt/libswt-gnome-gtk-3349.so >> /usr/lib/swt/libswt-cde-gtk-3349.so >> /usr/lib/swt/libswt-cairo-gtk-3349.so >> /usr/lib/swt/libswt-awt-gtk-3349.so >> /usr/lib/swt/libswt-atk-gtk-3349.so >> >> Since this is a shared lib, the numbers before .so don't matter.. even if >> we later upgrade this lib, all the apps depending on it will not be >> affected. What those apps will look for is to load libs like swt-atk-gtk >> etc. > > As Danek already pointed out the statement is clearly false. > > I'm also VERY concerned about this since the motivation for this case is > Vuze which auto updates itself. I'm concerned that some future version > of an autoupdate of Vuze will need a different version of SWT. How will > that be dealt with [ Not the Vuze update but the future version of > libswt ] ? > > Unless there is a plan to have multiple versions of SWT installed I see > no reason to have the -3349 in the file names. Particularly since it is > NOT present in the main swt.jar file; meaning it isn't possible with the > layout presented in this case to have multiple versions of SWT. So just > drop the -3349. > OK, this is how it looks on ubuntu 8.04, /usr/lib/jni/libswt-gnome-gtk-3236.so /usr/lib/jni/libswt-awt-gtk-3236.so /usr/lib/jni/libswt-atk-gtk-3236.so /usr/lib/jni/libswt-gtk-3236.so /usr/lib/jni/libswt-pi-gtk-3236.so /usr/lib/jni/libswt-cairo-gtk-3236.so /usr/lib/jni/libswt-mozilla-gtk-3236.so /usr/lib/jni/libswt-glx-gtk-3236.so They haven't drop any tailing numbers. I am no expert on shared libs, but I can tell you what I have experienced. I have used libs with -3346 and download the .jar files for Azureus 2 and Azureus 3. Both worked fine! so upgrade didnt matter, then I kept Azureus 3 constant, and changed SWT libs from -3346 to -3349.. it still works. If you want I can send you the spec file and you can try it out (i dont know if sending any attachments on this list is acceptable). What I saw is that, if you completely remove SWT from path, it will spit saying swt-gtk not found in blah blah blah path. > What versions of the JRE does this SWT build support ? > To build SWT thought you need JDK, I have compiled using JDK 1.5 and JDK 1.6 both. JRE is not required directly by SWT, it might be required by the app which might use SWT (eg. my very own headache Vuze ;) From danek.duvall@sun.com Fri Jul 25 10:58:49 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6PHwmhn028127 for ; Fri, 25 Jul 2008 10:58:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6PHwg7a026890 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 25 Jul 2008 18:58:47 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4K00K05PXY2J00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 25 Jul 2008 10:58:46 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4K00E3XPXYBU80@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 25 Jul 2008 10:58:46 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6PHwiDs028536; Fri, 25 Jul 2008 10:58:44 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m6PHwiJA018197; Fri, 25 Jul 2008 10:58:44 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m6PHwh69018196; Fri, 25 Jul 2008 10:58:43 -0700 (PDT) Date: Fri, 25 Jul 2008 10:58:43 -0700 From: Danek Duvall Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <20080718215809.GY15656@zruty.sfbay.sun.com> To: lsarc-ext@sun.com Cc: Harshal Patil , Brian Cameron Message-id: <20080725175843.GA17878@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 845 After some offline discussion, it's been determined that the primary interface to SWT is through Java, and not through the native libs. Thus I'd ask that the native libs be considered Project Private, and kept in /usr/lib/swt (a Project Private directory). Further, the SWT jar files should move to /usr/share/lib or /usr/share/lib/swt, as with most of the rest of our public jar files. The imported interfaces appear to be ATK 1.x and GTK+ 2.x, which the GNOME cases have marked as committed for some time, as well as libgnome, libgnomevfs, and libgnomeui, none of which I'm sure of the stability. Brian (or JohnF), can you comment? I'm curious about the distinction between swt.jar and swt-debug.jar. Would you use one or the other, or do you use both at the same time? Are you sure that cairomm is needed, or just cairo? Thanks, Danek From Harshal.Patil@sun.com Fri Jul 25 11:10:43 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6PIAhKT028333 for ; Fri, 25 Jul 2008 11:10:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6PIAgAa065065 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 25 Jul 2008 12:10:43 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4K00K03QHUJK00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 25 Jul 2008 11:10:42 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4K00E8ZQHTBH80@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 25 Jul 2008 11:10:42 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6PIBCmO026865 for ; Fri, 25 Jul 2008 18:11:12 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K4K00601QG1CJ00@mail-apac.sun.com> (original mail from Harshal.Patil@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 26 Jul 2008 02:10:09 +0800 (SGT) Received: from [192.168.1.2] ([122.167.8.101]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4K00MA6QGV9M96@mail-apac.sun.com>; Sat, 26 Jul 2008 02:10:09 +0800 (SGT) Date: Fri, 25 Jul 2008 23:40:39 +0530 From: Harshal Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <20080725175843.GA17878@zruty.sfbay.sun.com> Sender: Harshal.Patil@sun.com To: Danek Duvall Cc: lsarc-ext@sun.com, Brian Cameron Message-id: <488A171F.6020005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> <20080725175843.GA17878@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 1052 Danek Duvall wrote: > After some offline discussion, it's been determined that the primary > interface to SWT is through Java, and not through the native libs. Thus > I'd ask that the native libs be considered Project Private, and kept in > /usr/lib/swt (a Project Private directory). Further, the SWT jar files > should move to /usr/share/lib or /usr/share/lib/swt, as with most of the > rest of our public jar files. > for SWT jar files will /usr/share/lib/java/ do? just a question, if its not OK, I will change it to /usr/share/lib. > The imported interfaces appear to be ATK 1.x and GTK+ 2.x, which the GNOME > cases have marked as committed for some time, as well as libgnome, > libgnomevfs, and libgnomeui, none of which I'm sure of the stability. > Brian (or JohnF), can you comment? > > I'm curious about the distinction between swt.jar and swt-debug.jar. Would > you use one or the other, or do you use both at the same time? > just swt.jar is enough. > Are you sure that cairomm is needed, or just cairo? > cairomm --Harshal From danek.duvall@Sun.COM Fri Jul 25 11:19:45 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6PIJieX028384 for ; Fri, 25 Jul 2008 11:19:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m6PIJfsO023310 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Sat, 26 Jul 2008 02:19:43 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4K00I0VQWSFH00@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri, 25 Jul 2008 12:19:40 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4K00HB0QWR2B10@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri, 25 Jul 2008 12:19:39 -0600 (MDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6PIJbKv003237; Fri, 25 Jul 2008 11:19:37 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m6PIJbTE018352; Fri, 25 Jul 2008 11:19:37 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m6PIJbY3018351; Fri, 25 Jul 2008 11:19:37 -0700 (PDT) Date: Fri, 25 Jul 2008 11:19:36 -0700 From: Danek Duvall Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <488A171F.6020005@sun.com> To: Harshal Cc: lsarc-ext@Sun.COM, Brian Cameron Message-id: <20080725181936.GT15656@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> <20080725175843.GA17878@zruty.sfbay.sun.com> <488A171F.6020005@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 949 On Fri, Jul 25, 2008 at 11:40:39PM +0530, Harshal wrote: > Danek Duvall wrote: >> After some offline discussion, it's been determined that the primary >> interface to SWT is through Java, and not through the native libs. Thus >> I'd ask that the native libs be considered Project Private, and kept in >> /usr/lib/swt (a Project Private directory). Further, the SWT jar files >> should move to /usr/share/lib or /usr/share/lib/swt, as with most of the >> rest of our public jar files. >> > > for SWT jar files will /usr/share/lib/java/ do? just a question, if its not > OK, I will change it to /usr/share/lib. /usr/share/lib/java would be fine. >> Are you sure that cairomm is needed, or just cairo? > > cairomm Odd, because neither the swt website nor the cairo website says anything about it, and my gentoo installation doesn't require cairomm to install swt. But if so, then that adds LSARC/2008/074 to the dependency list. Thanks, Danek From Harshal.Patil@sun.com Fri Jul 25 11:33:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6PIXJBl028542 for ; Fri, 25 Jul 2008 11:33:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6PIX1bs013313 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 25 Jul 2008 19:33:18 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4K00L03RJHL800@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 25 Jul 2008 11:33:17 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4K00E8ERJG2I70@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 25 Jul 2008 11:33:17 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6PIXlJ1027031 for ; Fri, 25 Jul 2008 18:33:47 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K4K00B01RE6H500@mail-apac.sun.com> (original mail from Harshal.Patil@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 26 Jul 2008 02:32:44 +0800 (SGT) Received: from [192.168.1.2] ([122.167.8.101]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4K00MYYRII9MC6@mail-apac.sun.com>; Sat, 26 Jul 2008 02:32:44 +0800 (SGT) Date: Sat, 26 Jul 2008 00:03:14 +0530 From: Harshal Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <20080725181936.GT15656@zruty.sfbay.sun.com> Sender: Harshal.Patil@sun.com To: Danek Duvall Cc: lsarc-ext@sun.com, Brian Cameron Message-id: <488A1C6A.8060104@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> <20080725175843.GA17878@zruty.sfbay.sun.com> <488A171F.6020005@sun.com> <20080725181936.GT15656@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 1244 Danek Duvall wrote: > On Fri, Jul 25, 2008 at 11:40:39PM +0530, Harshal wrote: > >> Danek Duvall wrote: >>> After some offline discussion, it's been determined that the primary >>> interface to SWT is through Java, and not through the native libs. Thus >>> I'd ask that the native libs be considered Project Private, and kept in >>> /usr/lib/swt (a Project Private directory). Further, the SWT jar files >>> should move to /usr/share/lib or /usr/share/lib/swt, as with most of the >>> rest of our public jar files. >>> >> for SWT jar files will /usr/share/lib/java/ do? just a question, if its not >> OK, I will change it to /usr/share/lib. > > /usr/share/lib/java would be fine. > >>> Are you sure that cairomm is needed, or just cairo? >> cairomm > > Odd, because neither the swt website nor the cairo website says anything > about it, and my gentoo installation doesn't require cairomm to install > swt. But if so, then that adds LSARC/2008/074 to the dependency list. > Didn't try it on Linux, but on my OpenSolaris virtual machine, if I dont have SUNWcairomm installed then SWT source doesn't build libswt-cairo-gtk-3349.so Sorry I didn't get this sentence, "But if so, then that adds LSARC/2008/074 to the dependency list". From danek.duvall@Sun.COM Fri Jul 25 11:37:29 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6PIbSRw028556 for ; Fri, 25 Jul 2008 11:37:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6PIbRk0015583 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Fri, 25 Jul 2008 19:37:28 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4K00J01RQFSD00@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri, 25 Jul 2008 12:37:27 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4K00HS8RQE2810@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri, 25 Jul 2008 12:37:26 -0600 (MDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6PIbPrh053457; Fri, 25 Jul 2008 11:37:25 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m6PIbN5W018428; Fri, 25 Jul 2008 11:37:24 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m6PIbNna018427; Fri, 25 Jul 2008 11:37:23 -0700 (PDT) Date: Fri, 25 Jul 2008 11:37:22 -0700 From: Danek Duvall Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <488A1C6A.8060104@sun.com> To: Harshal Cc: lsarc-ext@Sun.COM Message-id: <20080725183722.GU15656@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> <20080725175843.GA17878@zruty.sfbay.sun.com> <488A171F.6020005@sun.com> <20080725181936.GT15656@zruty.sfbay.sun.com> <488A1C6A.8060104@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 501 On Sat, Jul 26, 2008 at 12:03:14AM +0530, Harshal wrote: > Didn't try it on Linux, but on my OpenSolaris virtual machine, if I dont > have SUNWcairomm installed then SWT source doesn't build > libswt-cairo-gtk-3349.so Um, okay. > Sorry I didn't get this sentence, "But if so, then that adds LSARC/2008/074 > to the dependency list". ARC dependencies are listed as ARC cases, if known, not individual interfaces. 2008/074 introduced all the C++ versions of the GTK+ family of libraries. Danek From Harshal.Patil@sun.com Fri Jul 25 11:40:01 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6PIe07E028573 for ; Fri, 25 Jul 2008 11:40:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6PIdmw8016425 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 25 Jul 2008 19:39:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4K00L0FRUKSD00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 25 Jul 2008 11:39:56 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4K00EK5RUJBP90@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 25 Jul 2008 11:39:56 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6PIeQfc027105 for ; Fri, 25 Jul 2008 18:40:26 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K4K00C01RM4IE00@mail-apac.sun.com> (original mail from Harshal.Patil@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 26 Jul 2008 02:39:23 +0800 (SGT) Received: from [192.168.1.2] ([122.167.8.101]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K4K007N0RTLUHVU@mail-apac.sun.com>; Sat, 26 Jul 2008 02:39:23 +0800 (SGT) Date: Sat, 26 Jul 2008 00:09:53 +0530 From: Harshal Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <20080725183722.GU15656@zruty.sfbay.sun.com> Sender: Harshal.Patil@sun.com To: Danek Duvall Cc: lsarc-ext@sun.com Message-id: <488A1DF9.1060909@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> <20080725175843.GA17878@zruty.sfbay.sun.com> <488A171F.6020005@sun.com> <20080725181936.GT15656@zruty.sfbay.sun.com> <488A1C6A.8060104@sun.com> <20080725183722.GU15656@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 429 Danek Duvall wrote: > On Sat, Jul 26, 2008 at 12:03:14AM +0530, Harshal wrote: >> Sorry I didn't get this sentence, "But if so, then that adds LSARC/2008/074 >> to the dependency list". > > ARC dependencies are listed as ARC cases, if known, not individual > interfaces. 2008/074 introduced all the C++ versions of the GTK+ family of > libraries. > > Danek Where can I find this ARC dependencies list? just for curiosity. From danek.duvall@sun.com Fri Jul 25 12:52:26 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6PJqQrx029978 for ; Fri, 25 Jul 2008 12:52:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6PJqMhL015638 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 25 Jul 2008 20:52:25 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4K0070DV7B3F00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 25 Jul 2008 12:52:23 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4K00EQ6V7A2KD0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 25 Jul 2008 12:52:22 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6PJqLwu030817; Fri, 25 Jul 2008 12:52:21 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m6PJqKgh019021; Fri, 25 Jul 2008 12:52:20 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m6PJqJd0019020; Fri, 25 Jul 2008 12:52:20 -0700 (PDT) Date: Fri, 25 Jul 2008 12:52:19 -0700 From: Danek Duvall Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <488A1DF9.1060909@sun.com> To: Harshal Cc: lsarc-ext@sun.com Message-id: <20080725195219.GV15656@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> <20080725175843.GA17878@zruty.sfbay.sun.com> <488A171F.6020005@sun.com> <20080725181936.GT15656@zruty.sfbay.sun.com> <488A1C6A.8060104@sun.com> <20080725183722.GU15656@zruty.sfbay.sun.com> <488A1DF9.1060909@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 270 On Sat, Jul 26, 2008 at 12:09:53AM +0530, Harshal wrote: > Where can I find this ARC dependencies list? just for curiosity. You can do searches on sac.eng or ask people who are involved in the area. I'm not sure there's any better way to figure this stuff out. Danek From Brian.Cameron@sun.com Mon Jul 28 04:04:31 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SB4VZ5012375 for ; Mon, 28 Jul 2008 04:04:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6SB4RPx027951 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 28 Jul 2008 12:04:30 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4P00K11QRGKZ00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 28 Jul 2008 05:04:28 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4P00CHDQRCHY60@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 28 Jul 2008 05:04:24 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6SB4OVl028004 for ; Mon, 28 Jul 2008 11:04:24 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4P00A01QL5K900@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 28 Jul 2008 05:04:24 -0600 (MDT) Received: from [129.156.226.192] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4P00C8FQRBILA0@mail-amer.sun.com>; Mon, 28 Jul 2008 05:04:24 -0600 (MDT) Date: Mon, 28 Jul 2008 06:04:33 -0500 From: Brian Cameron Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <20080725175843.GA17878@zruty.sfbay.sun.com> Sender: Brian.Cameron@sun.com To: Danek Duvall Cc: lsarc-ext@sun.com, Harshal Patil Message-id: <488DA7C1.5050100@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> <20080725175843.GA17878@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080701) Status: RO Content-Length: 849 Danek: > The imported interfaces appear to be ATK 1.x and GTK+ 2.x, which the GNOME > cases have marked as committed for some time, as well as libgnome, > libgnomevfs, and libgnomeui, none of which I'm sure of the stability. > Brian (or JohnF), can you comment? You can refer to the man pages for at ("man libatk-1.0") or for GTK ("man libgtk-x11-2.0") to see that these interfaces are Committed. The manpages for libgnome and libgnomeui highlight these are Volatile. However, the GNOME community is in the process of making them deprecated. You should probably avoid using these unless there is a real need. You should get contracts for these libgnomevfs is "Obsolete Volatile". You should probably use libgio, which is the replacement library for gnomevfs. libgio is also Volatile so you would need a contract for either library. Brian From danek.duvall@sun.com Mon Jul 28 10:07:08 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6SH78UW022915 for ; Mon, 28 Jul 2008 10:07:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6SH74Dc000146 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 28 Jul 2008 10:07:08 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4Q00F3D7JUU200@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 28 Jul 2008 10:07:06 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4Q00F6K7JRPR10@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 28 Jul 2008 10:07:03 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6SH71ma014718; Mon, 28 Jul 2008 10:07:01 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m6SH71F8028670; Mon, 28 Jul 2008 10:07:01 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m6SH71GL028669; Mon, 28 Jul 2008 10:07:01 -0700 (PDT) Date: Mon, 28 Jul 2008 10:07:00 -0700 From: Danek Duvall Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <488DA7C1.5050100@sun.com> To: Brian Cameron Cc: lsarc-ext@sun.com, Harshal Patil Message-id: <20080728170700.GK15656@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> <20080725175843.GA17878@zruty.sfbay.sun.com> <488DA7C1.5050100@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 808 On Mon, Jul 28, 2008 at 06:04:33AM -0500, Brian Cameron wrote: > The manpages for libgnome and libgnomeui highlight these are Volatile. > However, the GNOME community is in the process of making them deprecated. > You should probably avoid using these unless there is a real need. You > should get contracts for these > > libgnomevfs is "Obsolete Volatile". You should probably use libgio, > which is the replacement library for gnomevfs. libgio is also Volatile > so you would need a contract for either library. It's not up to us what libraries SWT uses. Some enterprising engineer might go tell IBM to do it differently, though. Do you have pre-filled contracts for these libraries that just need signing, or will Harshal have to go off and figure out how to fill out the contracts? Thanks, Danek From danek.duvall@sun.com Mon Aug 4 10:03:22 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m74H3MSe022066 for ; Mon, 4 Aug 2008 10:03:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m74H3II2003472 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 4 Aug 2008 10:03:22 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K530011Z61MU200@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 04 Aug 2008 10:03:22 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5300MTN61KQD30@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 04 Aug 2008 10:03:20 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m74H3Iu6020973; Mon, 04 Aug 2008 10:03:18 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m74H3IwT027412; Mon, 04 Aug 2008 10:03:18 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m74H3INv027411; Mon, 04 Aug 2008 10:03:18 -0700 (PDT) Date: Mon, 04 Aug 2008 10:03:18 -0700 From: Danek Duvall Subject: Re: SWT (Standard Widget Toolkit) (LSARC/2008/462) In-reply-to: <20080718215809.GY15656@zruty.sfbay.sun.com> To: lsarc-ext@sun.com Cc: Harshal Patil Message-id: <20080804170318.GE15656@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080718215809.GY15656@zruty.sfbay.sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 2069 I've updated the proposal to take into account the discussions had off-line. We're still waiting for help from the GNOME team on contracts for the use of various Volatile GNOME libraries, but otherwise the case should be complete. The proposal is in the case directory as proposal.txt, and is attached here. Thanks, ====================================================================== Summary ======= SWT is an open source widget toolkit for Java designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented. SWT is release under Eclipse Public License. This project requests a minor release binding, requires minor changes in makefile. it will be added in SFW as SUNWswt. Interfaces ========== Exported Interfaces ------------------- /usr/share/lib/java/swt.jar Uncommitted /usr/share/lib/java/swt-debug.jar Uncommitted /usr/lib/swt/libswt-pi-gtk-3349.so Project Private /usr/lib/swt/libswt-gtk-3349.so Project Private /usr/lib/swt/libswt-gnome-gtk-3349.so Project Private /usr/lib/swt/libswt-cde-gtk-3349.so Project Private /usr/lib/swt/libswt-cairo-gtk-3349.so Project Private /usr/lib/swt/libswt-awt-gtk-3349.so Project Private /usr/lib/swt/libswt-atk-gtk-3349.so Project Private The shared libraries are dynamically loaded by the Java classes. Since the libraries will only change when the jar file does, they will always be in sync, and the use of version numbers in the SONAME doesn't have an impact on consumers of SWT's Public interfaces. Imported Interfaces ------------------- /usr/lib/libcairomm-1.0.so.1 Uncommitted LSARC/2008/704 /usr/lib/libpng.so.3 Uncommitted LSARC/2003/568 GTK+, ATK Committed LSARC/2008/207 libgnome, libgnomevfs, libgnomeui Volatile LSARC/2008/207 Reference Documents =================== [1] http://www.eclipse.org/swt/ [2] http://en.wikipedia.org/wiki/Standard_Widget_Toolkit Danek From sacadmin Mon Sep 22 07:01:22 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8ME1M3m015012 for ; Mon, 22 Sep 2008 07:01:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8ME16nX002350 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Mon, 22 Sep 2008 08:01:22 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7L00F17OA7GJ00@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 07:01:19 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7L00A8OOA06650@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 07:01:12 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8ME1ABN022325; Mon, 22 Sep 2008 07:01:10 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m8ME2IOX022135; Mon, 22 Sep 2008 07:02:18 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8ME2IwA022134; Mon, 22 Sep 2008 07:02:18 -0700 (PDT) Date: Mon, 22 Sep 2008 07:02:18 -0700 From: Danek Duvall Subject: contract between LSARC 2006/202 (GNOME 2.14) and LSARC 2008/462 (SWT) To: lsarc@sun.com Cc: Zdenek Macura , Leo Binchy Message-id: <20080922140218.GV4762@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 User-Agent: Mutt/1.5.16 (2007-06-27) x_sac_archived: LSARC/2006/202 Status: RO Content-Length: 5889 Leo, Zdenek, please respond to this email saying you agree to this contract. I'll close the case as soon as that's done. Thanks, Danek @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: LSARC/2006/202-XXX 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris Consolidation: JDS Department or Group: OPG Desktop Bugster Product/Category/SubCategory: gnome Responsible Manager: Leo Binchy 3. The CONSUMER is identified by the following: Product or Bundle: Solaris Consolidation: JDS Department or Group: HPC Software Bugster Product/Category/SubCategory:swt/solaris/opensolaris Responsible Manager: Zdenek Macura 4. The INTERFACES are: libgnome Volatile libgnomeui Volatile libgnomevfs Obsolete Volatile 5. The ARC controlling these INTERFACES is: LSARC 6. The CASE describing (Exporting) these INTERFACES is: LSARC/2006/202 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: _N_ 7a. Although the stability level doesn't normally restrict it, SUPPLIER promises to only modify INTERFACES in an incompatible way as follows: _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will expose INTERFACES to a PARTNER, which is external to Sun, namely: Name of Company: Name of Department or Group within Company: Responsible Manager: _N_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same consolidation, they have the option of arranging for simultaneous conversion to the new interfaces. If this is not possible, or if they are not in the same consolidation, then SUPPLIER will either make best effort to work with CONSUMER so that CONSUMER can detect which version of INTERFACES is being supplied, or else SUPPLIER will make best effort to supply both old and new versions of INTERFACES. If SUPPLIER cannot make both versions of INTERFACES available, and SUPPLIER and CONSUMER cannot devise a method whereby CONSUMER can detect which version of INTERFACES is being supplied, and the old version of CONSUMER will not run with the new version of SUPPLIER, then either the EOL process must be followed by SUPPLIER, or else a major release of SUPPLIER will be required, or the change will not be allowed. 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make best effort to accommodate such changes, which shall then be treated in accordance with paragraph 7 above. 9. Notwithstanding paragraphs 7 and 8, a change to any portion of the INTERFACES shall be regarded as a completely new set of INTERFACES which require both ARC approval and execution of a new contract. 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: The supplier shall notify the consumer when the interfaces shall be updated and will supply the consumer with the new interfaces in order to obtain appropriate testing. The notification shall be via email with an acknowledgement from the consumer of reciept of the email. Upon successful testing the consumer shall send an approval email to the supplier within 2 weeks. [In particular, include whether the SUPPLIER will inform the CONSUMER or obtain approval of the change from the CONSUMER.] 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: The supplier will be supporting the basic interfaces that are in the Open Source community. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: There is no documentation being supplied at this time. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: SWT is used by Azureus and Eclipse. Tests will consist of testing the Azureus to make sure that applications that depend on these interfaces work. The testing will be done by the consumer who will have 2 weeks to approve the changes. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: This contract will be terminated if these interfaces become official standards, or become a stable open source library with infrequent changes. This would require a new ARC case raising the interfaces above EXTERNAL. 15. This contract is not valid until "signed" via agreement from the SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by this contract. E-mail agreement to the contract should be archived in the mail archive of CASE; verbal agreement to the contract should be noted in the meeting minutes. This contract remains valid until superseded or invalidated. For SUPPLIER: Leo Binchy Date: 09/12/2008 For CONSUMER:Zdenek Macura Date: 09/12/2008 For ARC: Danek Duvalll Date: 09/12/2008 A copy of this contract shall be deposited in the CASE directory as "contract-" or in a "contracts" subdirectory. 16. (Not to be filled in until superseded or invalidated.) This contract was superseded or invalidated by CASE: For ARC: Date: From sacadmin Mon Sep 22 07:27:29 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8MERT63015384 for ; Mon, 22 Sep 2008 07:27:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8MERTCj006348 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Mon, 22 Sep 2008 07:27:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7L00H2ZPHSTA00@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 07:27:28 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7L00A4XPHQ65A0@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 07:27:27 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8MERQ8r000492 for ; Mon, 22 Sep 2008 14:27:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7L00H01OLDDD00@fe-emea-10.sun.com> (original mail from Leo.Binchy@Sun.COM) for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 15:27:26 +0100 (BST) Received: from [129.156.226.96] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7L00J7PPHHU8F0@fe-emea-10.sun.com>; Mon, 22 Sep 2008 15:27:18 +0100 (BST) Date: Mon, 22 Sep 2008 15:27:17 +0100 From: Leontine Binchy Subject: Re: contract between LSARC 2006/202 (GNOME 2.14) and LSARC 2008/462 (SWT) In-reply-to: <20080922140218.GV4762@mumak.SFBay.Sun.COM> Sender: Leo.Binchy@Sun.COM To: Danek Duvall Cc: lsarc@Sun.COM, Zdenek Macura , Brian Cameron Message-id: <48D7AB45.9040308@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080922140218.GV4762@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) Status: RO Content-Length: 6323 Hi Danek, Is there a reason as to why we want the contract between GNOME 2.14 as opposed to the latest GNOME 2.24 (LSARC 2008/510) Thanks Leo Danek Duvall wrote: > Leo, Zdenek, please respond to this email saying you agree to this > contract. I'll close the case as soon as that's done. > > Thanks, > Danek > > > @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: LSARC/2006/202-XXX > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Sun Microsystems, Incorporated. > > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > Product or Bundle: Solaris > Consolidation: JDS > Department or Group: OPG Desktop > Bugster Product/Category/SubCategory: gnome > Responsible Manager: Leo Binchy > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: JDS > Department or Group: HPC Software > Bugster Product/Category/SubCategory:swt/solaris/opensolaris > Responsible Manager: Zdenek Macura > > 4. The INTERFACES are: > > libgnome Volatile > libgnomeui Volatile > libgnomevfs Obsolete Volatile > > 5. The ARC controlling these INTERFACES is: LSARC > > 6. The CASE describing (Exporting) these INTERFACES is: LSARC/2006/202 > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _N_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will > expose INTERFACES to a PARTNER, which is external to Sun, namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _N_ 7c. Although the stability level doesn't normally allow it, CONSUMER will > import INTERFACES from a separate consolidation. > > _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any > portion of the INTERFACES, SUPPLIER will notify CONSUMER of the > proposed new version, no later than the application for ARC > approval of the new version. > If SUPPLIER and CONSUMER are contained in the same consolidation, > they have the option of arranging for simultaneous conversion > to the new interfaces. If this is not possible, or if they are > not in the same consolidation, then SUPPLIER will either make best > effort to work with CONSUMER so that CONSUMER can detect which > version of INTERFACES is being supplied, or else SUPPLIER will > make best effort to supply both old and new versions of > INTERFACES. > If SUPPLIER cannot make both versions of INTERFACES available, > and SUPPLIER and CONSUMER cannot devise a method whereby > CONSUMER can detect which version of INTERFACES is being > supplied, and the old version of CONSUMER will not run with the > new version of SUPPLIER, then either the EOL process must be > followed by SUPPLIER, or else a major release of SUPPLIER will > be required, or the change will not be allowed. > > 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make > best effort to accommodate such changes, which shall then be > treated in accordance with paragraph 7 above. > > 9. Notwithstanding paragraphs 7 and 8, a change to any portion > of the INTERFACES shall be regarded as a completely new set of > INTERFACES which require both ARC approval and execution of > a new contract. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > The supplier shall notify the consumer when the interfaces > shall be updated and will supply the consumer with the > new interfaces in order to obtain appropriate testing. > The notification shall be via email with an acknowledgement > from the consumer of reciept of the email. Upon successful > testing the consumer shall send an approval email to the > supplier within 2 weeks. > > [In particular, include whether the SUPPLIER will inform the > CONSUMER or obtain approval of the change from the CONSUMER.] > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > The supplier will be supporting the basic interfaces that are > in the Open Source community. > > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > There is no documentation being supplied at this time. > > > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > SWT is used by Azureus and Eclipse. Tests will > consist of testing the Azureus to make sure that applications > that depend on these interfaces work. The testing will be done > by the consumer who will have 2 weeks to approve > the changes. > > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > This contract will be terminated if these interfaces become > official standards, or become a stable open source library > with infrequent changes. This would require a new ARC case > raising the interfaces above EXTERNAL. > > > 15. This contract is not valid until "signed" via agreement from the > SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by > this contract. E-mail agreement to the contract should be archived > in the mail archive of CASE; verbal agreement to the contract > should be noted in the meeting minutes. This contract remains > valid until superseded or invalidated. > > For SUPPLIER: Leo Binchy Date: 09/12/2008 > For CONSUMER:Zdenek Macura Date: 09/12/2008 > For ARC: Danek Duvalll Date: 09/12/2008 > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: > > From sacadmin Mon Sep 22 07:37:59 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8MEbwpJ015513 for ; Mon, 22 Sep 2008 07:37:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8MEbuuR010778 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Mon, 22 Sep 2008 07:37:58 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7L00I0NPZ9VL00@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 07:37:57 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7L00AZWPZ86890@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 07:37:56 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8MEbrxQ046836; Mon, 22 Sep 2008 07:37:53 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m8MEd2m3022456; Mon, 22 Sep 2008 07:39:02 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8MEd2GJ022455; Mon, 22 Sep 2008 07:39:02 -0700 (PDT) Date: Mon, 22 Sep 2008 07:39:02 -0700 From: Danek Duvall Subject: Re: contract between LSARC 2006/202 (GNOME 2.14) and LSARC 2008/462 (SWT) In-reply-to: <48D7AB45.9040308@sun.com> To: Leontine Binchy Cc: lsarc@sun.com, Zdenek Macura , Brian Cameron Message-id: <20080922143902.GA22189@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080922140218.GV4762@mumak.SFBay.Sun.COM> <48D7AB45.9040308@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 273 On Mon, Sep 22, 2008 at 03:27:17PM +0100, Leontine Binchy wrote: > Is there a reason as to why we want the contract between GNOME 2.14 as > opposed to the latest GNOME 2.24 (LSARC 2008/510) This was the one Brian recommended. I'm not wedded to one or the other. Danek From sacadmin Mon Sep 22 07:56:38 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8MEub39015976 for ; Mon, 22 Sep 2008 07:56:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8MEuZbH014473 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Mon, 22 Sep 2008 07:56:37 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7L00K05QUDLD00@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 07:56:37 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7L00ACZQUC68C0@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 07:56:37 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8MEua43022328 for ; Mon, 22 Sep 2008 14:56:36 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7L00301P8BBW00@fe-emea-10.sun.com> (original mail from Zdenek.Macura@Sun.COM) for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 15:56:36 +0100 (BST) Received: from [129.157.19.161] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7L005ULQT9LOC0@fe-emea-10.sun.com>; Mon, 22 Sep 2008 15:55:59 +0100 (BST) Date: Mon, 22 Sep 2008 16:55:59 +0200 From: Zdenek Macura Subject: Re: contract between LSARC 2006/202 (GNOME 2.14) and LSARC 2008/462 (SWT) In-reply-to: <20080922140218.GV4762@mumak.SFBay.Sun.COM> Sender: Zdenek.Macura@sun.com To: Danek Duvall Cc: lsarc@sun.com, Leo Binchy Message-id: <48D7B1FF.1030108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080922140218.GV4762@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080724) Status: RO Content-Length: 6196 I agree, Zdenek Danek Duvall wrote: > Leo, Zdenek, please respond to this email saying you agree to this > contract. I'll close the case as soon as that's done. > > Thanks, > Danek > > > @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: LSARC/2006/202-XXX > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Sun Microsystems, Incorporated. > > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > Product or Bundle: Solaris > Consolidation: JDS > Department or Group: OPG Desktop > Bugster Product/Category/SubCategory: gnome > Responsible Manager: Leo Binchy > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: JDS > Department or Group: HPC Software > Bugster Product/Category/SubCategory:swt/solaris/opensolaris > Responsible Manager: Zdenek Macura > > 4. The INTERFACES are: > > libgnome Volatile > libgnomeui Volatile > libgnomevfs Obsolete Volatile > > 5. The ARC controlling these INTERFACES is: LSARC > > 6. The CASE describing (Exporting) these INTERFACES is: LSARC/2006/202 > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _N_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will > expose INTERFACES to a PARTNER, which is external to Sun, namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _N_ 7c. Although the stability level doesn't normally allow it, CONSUMER will > import INTERFACES from a separate consolidation. > > _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any > portion of the INTERFACES, SUPPLIER will notify CONSUMER of the > proposed new version, no later than the application for ARC > approval of the new version. > If SUPPLIER and CONSUMER are contained in the same consolidation, > they have the option of arranging for simultaneous conversion > to the new interfaces. If this is not possible, or if they are > not in the same consolidation, then SUPPLIER will either make best > effort to work with CONSUMER so that CONSUMER can detect which > version of INTERFACES is being supplied, or else SUPPLIER will > make best effort to supply both old and new versions of > INTERFACES. > If SUPPLIER cannot make both versions of INTERFACES available, > and SUPPLIER and CONSUMER cannot devise a method whereby > CONSUMER can detect which version of INTERFACES is being > supplied, and the old version of CONSUMER will not run with the > new version of SUPPLIER, then either the EOL process must be > followed by SUPPLIER, or else a major release of SUPPLIER will > be required, or the change will not be allowed. > > 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make > best effort to accommodate such changes, which shall then be > treated in accordance with paragraph 7 above. > > 9. Notwithstanding paragraphs 7 and 8, a change to any portion > of the INTERFACES shall be regarded as a completely new set of > INTERFACES which require both ARC approval and execution of > a new contract. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > The supplier shall notify the consumer when the interfaces > shall be updated and will supply the consumer with the > new interfaces in order to obtain appropriate testing. > The notification shall be via email with an acknowledgement > from the consumer of reciept of the email. Upon successful > testing the consumer shall send an approval email to the > supplier within 2 weeks. > > [In particular, include whether the SUPPLIER will inform the > CONSUMER or obtain approval of the change from the CONSUMER.] > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > The supplier will be supporting the basic interfaces that are > in the Open Source community. > > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > There is no documentation being supplied at this time. > > > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > SWT is used by Azureus and Eclipse. Tests will > consist of testing the Azureus to make sure that applications > that depend on these interfaces work. The testing will be done > by the consumer who will have 2 weeks to approve > the changes. > > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > This contract will be terminated if these interfaces become > official standards, or become a stable open source library > with infrequent changes. This would require a new ARC case > raising the interfaces above EXTERNAL. > > > 15. This contract is not valid until "signed" via agreement from the > SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by > this contract. E-mail agreement to the contract should be archived > in the mail archive of CASE; verbal agreement to the contract > should be noted in the meeting minutes. This contract remains > valid until superseded or invalidated. > > For SUPPLIER: Leo Binchy Date: 09/12/2008 > For CONSUMER:Zdenek Macura Date: 09/12/2008 > For ARC: Danek Duvalll Date: 09/12/2008 > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: > > From sacadmin Mon Sep 22 11:01:50 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8MI1oZZ022057 for ; Mon, 22 Sep 2008 11:01:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8MI1cvi023871 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Mon, 22 Sep 2008 11:01:49 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7L0031ZZF0E900@brm-avmta-1.central.sun.com> for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 12:01:48 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7L00LWXZF0NP40@brm-avmta-1.central.sun.com> for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 12:01:48 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8MI1lPT005802 for ; Mon, 22 Sep 2008 18:01:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7L00I01ZCG7G00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc@sun.com (ORCPT lsarc@sun.com); Mon, 22 Sep 2008 12:01:47 -0600 (MDT) Received: from [192.168.1.102] ([97.86.41.246]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7L00AYJZEN4Z90@mail-amer.sun.com>; Mon, 22 Sep 2008 12:01:36 -0600 (MDT) Date: Mon, 22 Sep 2008 13:01:23 -0500 From: Brian Cameron Subject: Re: contract between LSARC 2006/202 (GNOME 2.14) and LSARC 2008/462 (SWT) In-reply-to: <48D7AB45.9040308@sun.com> Sender: Brian.Cameron@sun.com To: Leontine Binchy Cc: Danek Duvall , lsarc@sun.com, Zdenek Macura Message-id: <48D7DD73.9000605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080922140218.GV4762@mumak.SFBay.Sun.COM> <48D7AB45.9040308@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080825) x_sac_archived: LSARC/2006/202 Status: RO Content-Length: 7590 Leo/Danek: > Is there a reason as to why we want the contract between GNOME 2.14 as > opposed to the latest GNOME 2.24 (LSARC 2008/510) The GNOME 2.14 case is where we tried to define the overall stability levels for the overall GNOME desktop using the new ARC interface taxonomy (e.g. Committed instead of Stable, Volatile instead of External, etc.). So it is a good case to use when wanting to refer to the interface levels of GNOME platform libraries or other general interfaces. Since GNOME 2.14, the GNOME umbrella cases have only discussed differences since the GNOME 2.14 case. So it would be sensible to refer to a later case (such as 2008/510) when referring to a specific new interface that was cataloged in that future case, but which didn't exist in the GNOME 2.14 case. Having said all that, it probably doesn't really matter which GNOME case is used. What really matters, I think, is that we establish the contract and make sure that we work with the other internal teams at Sun to make sure that the interfaces they depend on work as needed. I hope that explains things. Brian > Danek Duvall wrote: >> Leo, Zdenek, please respond to this email saying you agree to this >> contract. I'll close the case as soon as that's done. >> >> Thanks, >> Danek >> >> >> @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 >> 06/12/06] >> >> CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES >> >> 0. Number: LSARC/2006/202-XXX >> >> 1. This contract is between >> a SUPPLIER of INTERFACES and >> a CONSUMER of those INTERFACES, >> both of whom are entities within Sun Microsystems, Incorporated. >> >> 2. The SUPPLIER (definer and/or implementor) is identified by the >> following: >> Product or Bundle: Solaris >> Consolidation: JDS >> Department or Group: OPG Desktop >> Bugster Product/Category/SubCategory: gnome >> Responsible Manager: Leo Binchy >> >> 3. The CONSUMER is identified by the following: >> Product or Bundle: Solaris >> Consolidation: JDS >> Department or Group: HPC Software >> Bugster Product/Category/SubCategory:swt/solaris/opensolaris >> Responsible Manager: Zdenek Macura >> >> 4. The INTERFACES are: >> >> libgnome Volatile >> libgnomeui Volatile >> libgnomevfs Obsolete Volatile >> >> 5. The ARC controlling these INTERFACES is: LSARC >> >> 6. The CASE describing (Exporting) these INTERFACES is: LSARC/2006/202 >> >> 7. The following SPECIAL ARRANGEMENTS are made which modify the rules >> imposed by the stability levels listed in section 4 above: >> >> _N_ 7a. Although the stability level doesn't normally restrict it, >> SUPPLIER promises to only modify INTERFACES in an incompatible >> way as follows: >> >> _N_ 7b. Although the stability level doesn't normally allow it, >> CONSUMER will >> expose INTERFACES to a PARTNER, which is external to Sun, namely: >> Name of Company: >> Name of Department or Group within Company: >> Responsible Manager: >> >> _N_ 7c. Although the stability level doesn't normally allow it, >> CONSUMER will >> import INTERFACES from a separate consolidation. >> >> _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any >> portion of the INTERFACES, SUPPLIER will notify CONSUMER of the >> proposed new version, no later than the application for ARC >> approval of the new version. >> If SUPPLIER and CONSUMER are contained in the same consolidation, >> they have the option of arranging for simultaneous conversion >> to the new interfaces. If this is not possible, or if they are >> not in the same consolidation, then SUPPLIER will either make best >> effort to work with CONSUMER so that CONSUMER can detect which >> version of INTERFACES is being supplied, or else SUPPLIER will >> make best effort to supply both old and new versions of >> INTERFACES. >> If SUPPLIER cannot make both versions of INTERFACES available, >> and SUPPLIER and CONSUMER cannot devise a method whereby >> CONSUMER can detect which version of INTERFACES is being >> supplied, and the old version of CONSUMER will not run with the >> new version of SUPPLIER, then either the EOL process must be >> followed by SUPPLIER, or else a major release of SUPPLIER will >> be required, or the change will not be allowed. >> >> 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make >> best effort to accommodate such changes, which shall then be >> treated in accordance with paragraph 7 above. >> >> 9. Notwithstanding paragraphs 7 and 8, a change to any portion >> of the INTERFACES shall be regarded as a completely new set of >> INTERFACES which require both ARC approval and execution of >> a new contract. >> >> 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be >> handled as follows: >> The supplier shall notify the consumer when the interfaces >> shall be updated and will supply the consumer with the >> new interfaces in order to obtain appropriate testing. >> The notification shall be via email with an acknowledgement >> from the consumer of reciept of the email. Upon successful >> testing the consumer shall send an approval email to the >> supplier within 2 weeks. >> >> [In particular, include whether the SUPPLIER will inform the >> CONSUMER or obtain approval of the change from the CONSUMER.] >> >> 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as >> follows: >> The supplier will be supporting the basic interfaces that are >> in the Open Source community. >> >> >> 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as >> follows: >> >> There is no documentation being supplied at this time. >> >> >> >> 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be >> tested as follows: >> >> SWT is used by Azureus and Eclipse. Tests will >> consist of testing the Azureus to make sure that applications >> that depend on these interfaces work. The testing will be done >> by the consumer who will have 2 weeks to approve >> the changes. >> >> >> 14. SUPPLIER and CONSUMER agree that this contract can be terminated as >> follows: >> >> This contract will be terminated if these interfaces become >> official standards, or become a stable open source library >> with infrequent changes. This would require a new ARC case >> raising the interfaces above EXTERNAL. >> >> >> 15. This contract is not valid until "signed" via agreement from the >> SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by >> this contract. E-mail agreement to the contract should be archived >> in the mail archive of CASE; verbal agreement to the contract >> should be noted in the meeting minutes. This contract remains >> valid until superseded or invalidated. >> >> For SUPPLIER: Leo Binchy Date: 09/12/2008 >> For CONSUMER:Zdenek Macura Date: 09/12/2008 >> For ARC: Danek Duvalll Date: 09/12/2008 >> >> A copy of this contract shall be deposited in the CASE directory as >> "contract-" or in a "contracts" subdirectory. >> >> 16. (Not to be filled in until superseded or invalidated.) >> This contract was superseded or invalidated by CASE: >> For ARC: Date: >> >> From sacadmin Tue Sep 23 01:01:44 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8N81iRB020215 for ; Tue, 23 Sep 2008 01:01:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8N81h4r031354 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Tue, 23 Sep 2008 02:01:43 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7N0000T2ASTU00@brm-avmta-1.central.sun.com> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 23 Sep 2008 02:01:40 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7N00KUV2ARMKA0@brm-avmta-1.central.sun.com> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 23 Sep 2008 02:01:39 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8N81c30017052 for ; Tue, 23 Sep 2008 08:01:38 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7N0080120T6200@fe-emea-09.sun.com> (original mail from Leo.Binchy@Sun.COM) for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 23 Sep 2008 09:01:38 +0100 (BST) Received: from [129.156.226.96] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7N002272AF0HF0@fe-emea-09.sun.com>; Tue, 23 Sep 2008 09:01:28 +0100 (BST) Date: Tue, 23 Sep 2008 09:01:27 +0100 From: Leontine Binchy Subject: Re: contract between LSARC 2006/202 (GNOME 2.14) and LSARC 2008/462 (SWT) In-reply-to: <20080922140218.GV4762@mumak.SFBay.Sun.COM> Sender: Leo.Binchy@sun.com To: Danek Duvall Cc: lsarc@sun.com, Zdenek Macura Message-id: <48D8A257.8060703@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080922140218.GV4762@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) x_sac_archived: LSARC/2006/202 Status: RO Content-Length: 6188 A approve Danek Duvall wrote: > Leo, Zdenek, please respond to this email saying you agree to this > contract. I'll close the case as soon as that's done. > > Thanks, > Danek > > > @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: LSARC/2006/202-XXX > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Sun Microsystems, Incorporated. > > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > Product or Bundle: Solaris > Consolidation: JDS > Department or Group: OPG Desktop > Bugster Product/Category/SubCategory: gnome > Responsible Manager: Leo Binchy > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: JDS > Department or Group: HPC Software > Bugster Product/Category/SubCategory:swt/solaris/opensolaris > Responsible Manager: Zdenek Macura > > 4. The INTERFACES are: > > libgnome Volatile > libgnomeui Volatile > libgnomevfs Obsolete Volatile > > 5. The ARC controlling these INTERFACES is: LSARC > > 6. The CASE describing (Exporting) these INTERFACES is: LSARC/2006/202 > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _N_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will > expose INTERFACES to a PARTNER, which is external to Sun, namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _N_ 7c. Although the stability level doesn't normally allow it, CONSUMER will > import INTERFACES from a separate consolidation. > > _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any > portion of the INTERFACES, SUPPLIER will notify CONSUMER of the > proposed new version, no later than the application for ARC > approval of the new version. > If SUPPLIER and CONSUMER are contained in the same consolidation, > they have the option of arranging for simultaneous conversion > to the new interfaces. If this is not possible, or if they are > not in the same consolidation, then SUPPLIER will either make best > effort to work with CONSUMER so that CONSUMER can detect which > version of INTERFACES is being supplied, or else SUPPLIER will > make best effort to supply both old and new versions of > INTERFACES. > If SUPPLIER cannot make both versions of INTERFACES available, > and SUPPLIER and CONSUMER cannot devise a method whereby > CONSUMER can detect which version of INTERFACES is being > supplied, and the old version of CONSUMER will not run with the > new version of SUPPLIER, then either the EOL process must be > followed by SUPPLIER, or else a major release of SUPPLIER will > be required, or the change will not be allowed. > > 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make > best effort to accommodate such changes, which shall then be > treated in accordance with paragraph 7 above. > > 9. Notwithstanding paragraphs 7 and 8, a change to any portion > of the INTERFACES shall be regarded as a completely new set of > INTERFACES which require both ARC approval and execution of > a new contract. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > The supplier shall notify the consumer when the interfaces > shall be updated and will supply the consumer with the > new interfaces in order to obtain appropriate testing. > The notification shall be via email with an acknowledgement > from the consumer of reciept of the email. Upon successful > testing the consumer shall send an approval email to the > supplier within 2 weeks. > > [In particular, include whether the SUPPLIER will inform the > CONSUMER or obtain approval of the change from the CONSUMER.] > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > The supplier will be supporting the basic interfaces that are > in the Open Source community. > > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > There is no documentation being supplied at this time. > > > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > SWT is used by Azureus and Eclipse. Tests will > consist of testing the Azureus to make sure that applications > that depend on these interfaces work. The testing will be done > by the consumer who will have 2 weeks to approve > the changes. > > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > This contract will be terminated if these interfaces become > official standards, or become a stable open source library > with infrequent changes. This would require a new ARC case > raising the interfaces above EXTERNAL. > > > 15. This contract is not valid until "signed" via agreement from the > SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by > this contract. E-mail agreement to the contract should be archived > in the mail archive of CASE; verbal agreement to the contract > should be noted in the meeting minutes. This contract remains > valid until superseded or invalidated. > > For SUPPLIER: Leo Binchy Date: 09/12/2008 > For CONSUMER:Zdenek Macura Date: 09/12/2008 > For ARC: Danek Duvalll Date: 09/12/2008 > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: > > From sacadmin Tue Sep 23 08:53:32 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8NFrWDZ002767 for ; Tue, 23 Sep 2008 08:53:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8NFqujE000145 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Tue, 23 Sep 2008 16:53:30 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7N00C05O557E00@brm-avmta-1.central.sun.com> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 23 Sep 2008 09:53:29 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7N008BWO548N50@brm-avmta-1.central.sun.com> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 23 Sep 2008 09:53:29 -0600 (MDT) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8NFrQ0I011645; Tue, 23 Sep 2008 08:53:26 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m8NFsZgZ001765; Tue, 23 Sep 2008 08:54:35 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8NFsZfY001764; Tue, 23 Sep 2008 08:54:35 -0700 (PDT) Date: Tue, 23 Sep 2008 08:54:35 -0700 From: Danek Duvall Subject: Re: contract between LSARC 2006/202 (GNOME 2.14) and LSARC 2008/462 (SWT) In-reply-to: <48D8A257.8060703@sun.com> To: Leontine Binchy Cc: lsarc@sun.com, Zdenek Macura Message-id: <20080923155435.GK22821@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080922140218.GV4762@mumak.SFBay.Sun.COM> <48D8A257.8060703@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 173 On Tue, Sep 23, 2008 at 09:01:27AM +0100, Leontine Binchy wrote: > A approve Thanks. As ARC sponsor, I approve, and I'm marking this case closed approved. Thanks, Danek From sacadmin Tue Sep 23 10:36:38 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8NHacnA009948 for ; Tue, 23 Sep 2008 10:36:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8NHab3U028885 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Tue, 23 Sep 2008 10:36:38 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7N00B1HSX1QN00@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 23 Sep 2008 10:36:37 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7N000F3SX06880@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 23 Sep 2008 10:36:36 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8NHaZ7L005036 for ; Tue, 23 Sep 2008 17:36:35 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7N00901S666N00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 23 Sep 2008 11:36:35 -0600 (MDT) Received: from [129.153.250.11] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7N006B2SWTMG80@mail-amer.sun.com>; Tue, 23 Sep 2008 11:36:30 -0600 (MDT) Date: Tue, 23 Sep 2008 12:36:29 -0500 From: Brian Cameron Subject: Re: contract between LSARC 2006/202 (GNOME 2.14) and LSARC 2008/462 (SWT) In-reply-to: <20080922140218.GV4762@mumak.SFBay.Sun.COM> Sender: Brian.Cameron@Sun.COM To: Danek Duvall Cc: lsarc@Sun.COM, Zdenek Macura , Leo Binchy Reply-to: Brian.Cameron@Sun.COM Message-id: <48D9291D.3060905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080922140218.GV4762@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 6541 Danek: I don't yet see this contract copied into either the LSARC 2008/462 or 2002/202 case directories yet. Could you ping me when the contract is copied there? The JDS team keeps a Wiki page which references all contracts we need to keep track of, so I'd like to add this contract to the Wiki when it is available. Thanks, Brian > Leo, Zdenek, please respond to this email saying you agree to this > contract. I'll close the case as soon as that's done. > > Thanks, > Danek > > > @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: LSARC/2006/202-XXX > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Sun Microsystems, Incorporated. > > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > Product or Bundle: Solaris > Consolidation: JDS > Department or Group: OPG Desktop > Bugster Product/Category/SubCategory: gnome > Responsible Manager: Leo Binchy > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: JDS > Department or Group: HPC Software > Bugster Product/Category/SubCategory:swt/solaris/opensolaris > Responsible Manager: Zdenek Macura > > 4. The INTERFACES are: > > libgnome Volatile > libgnomeui Volatile > libgnomevfs Obsolete Volatile > > 5. The ARC controlling these INTERFACES is: LSARC > > 6. The CASE describing (Exporting) these INTERFACES is: LSARC/2006/202 > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _N_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will > expose INTERFACES to a PARTNER, which is external to Sun, namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _N_ 7c. Although the stability level doesn't normally allow it, CONSUMER will > import INTERFACES from a separate consolidation. > > _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any > portion of the INTERFACES, SUPPLIER will notify CONSUMER of the > proposed new version, no later than the application for ARC > approval of the new version. > If SUPPLIER and CONSUMER are contained in the same consolidation, > they have the option of arranging for simultaneous conversion > to the new interfaces. If this is not possible, or if they are > not in the same consolidation, then SUPPLIER will either make best > effort to work with CONSUMER so that CONSUMER can detect which > version of INTERFACES is being supplied, or else SUPPLIER will > make best effort to supply both old and new versions of > INTERFACES. > If SUPPLIER cannot make both versions of INTERFACES available, > and SUPPLIER and CONSUMER cannot devise a method whereby > CONSUMER can detect which version of INTERFACES is being > supplied, and the old version of CONSUMER will not run with the > new version of SUPPLIER, then either the EOL process must be > followed by SUPPLIER, or else a major release of SUPPLIER will > be required, or the change will not be allowed. > > 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make > best effort to accommodate such changes, which shall then be > treated in accordance with paragraph 7 above. > > 9. Notwithstanding paragraphs 7 and 8, a change to any portion > of the INTERFACES shall be regarded as a completely new set of > INTERFACES which require both ARC approval and execution of > a new contract. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > The supplier shall notify the consumer when the interfaces > shall be updated and will supply the consumer with the > new interfaces in order to obtain appropriate testing. > The notification shall be via email with an acknowledgement > from the consumer of reciept of the email. Upon successful > testing the consumer shall send an approval email to the > supplier within 2 weeks. > > [In particular, include whether the SUPPLIER will inform the > CONSUMER or obtain approval of the change from the CONSUMER.] > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > The supplier will be supporting the basic interfaces that are > in the Open Source community. > > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > There is no documentation being supplied at this time. > > > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > SWT is used by Azureus and Eclipse. Tests will > consist of testing the Azureus to make sure that applications > that depend on these interfaces work. The testing will be done > by the consumer who will have 2 weeks to approve > the changes. > > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > This contract will be terminated if these interfaces become > official standards, or become a stable open source library > with infrequent changes. This would require a new ARC case > raising the interfaces above EXTERNAL. > > > 15. This contract is not valid until "signed" via agreement from the > SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by > this contract. E-mail agreement to the contract should be archived > in the mail archive of CASE; verbal agreement to the contract > should be noted in the meeting minutes. This contract remains > valid until superseded or invalidated. > > For SUPPLIER: Leo Binchy Date: 09/12/2008 > For CONSUMER:Zdenek Macura Date: 09/12/2008 > For ARC: Danek Duvalll Date: 09/12/2008 > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: > -- Brian From sacadmin Tue Sep 23 10:46:10 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8NHkAJE010213 for ; Tue, 23 Sep 2008 10:46:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8NHk388050693 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Tue, 23 Sep 2008 11:46:09 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7N00C0PTCXOV00@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 23 Sep 2008 10:46:09 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7N00053TCW67A0@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 23 Sep 2008 10:46:08 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8NHk5lH042342; Tue, 23 Sep 2008 10:46:05 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m8NHlF3L003285; Tue, 23 Sep 2008 10:47:15 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8NHlF7T003284; Tue, 23 Sep 2008 10:47:15 -0700 (PDT) Date: Tue, 23 Sep 2008 10:47:15 -0700 From: Danek Duvall Subject: Re: contract between LSARC 2006/202 (GNOME 2.14) and LSARC 2008/462 (SWT) In-reply-to: <48D9291D.3060905@Sun.COM> To: Brian Cameron Cc: lsarc@Sun.COM, Zdenek Macura , Leo Binchy Message-id: <20080923174715.GN22821@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080922140218.GV4762@mumak.SFBay.Sun.COM> <48D9291D.3060905@Sun.COM> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 531 On Tue, Sep 23, 2008 at 12:36:29PM -0500, Brian Cameron wrote: > I don't yet see this contract copied into either the LSARC 2008/462 or > 2002/202 case directories yet. Could you ping me when the contract > is copied there? The JDS team keeps a Wiki page which references all > contracts we need to keep track of, so I'd like to add this contract > to the Wiki when it is available. Since you're the owner of 2006/202, I'll let you copy it into place there. I'll add a link to it in 2008/462 once it's in place. Thanks, Danek From sacadmin Tue Sep 23 14:54:39 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8NLscEi018897 for ; Tue, 23 Sep 2008 14:54:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8NLsYCO002472 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Tue, 23 Sep 2008 22:54:37 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7O00F0H4UZRY00@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@Sun.COM); Tue, 23 Sep 2008 14:54:35 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7O00JMZ4UZ6HE0@nwk-avmta-1.sfbay.Sun.COM> for lsarc@sun.com (ORCPT lsarc@Sun.COM); Tue, 23 Sep 2008 14:54:35 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8NLsZE8021155 for ; Tue, 23 Sep 2008 21:54:35 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7O00I014R7LQ00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc@Sun.COM (ORCPT lsarc@Sun.COM); Tue, 23 Sep 2008 15:54:35 -0600 (MDT) Received: from [129.153.250.185] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7O00EY14UYWO80@mail-amer.sun.com>; Tue, 23 Sep 2008 15:54:34 -0600 (MDT) Date: Tue, 23 Sep 2008 16:54:24 -0500 From: Brian Cameron Subject: Re: contract between LSARC 2006/202 (GNOME 2.14) and LSARC 2008/462 (SWT) In-reply-to: <20080923174715.GN22821@mumak.SFBay.Sun.COM> Sender: Brian.Cameron@sun.com To: Danek Duvall Cc: lsarc@sun.com, Zdenek Macura , Leo Binchy Message-id: <48D96590.7020803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080922140218.GV4762@mumak.SFBay.Sun.COM> <48D9291D.3060905@Sun.COM> <20080923174715.GN22821@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080825) Status: RO Content-Length: 589 Danek: >> I don't yet see this contract copied into either the LSARC 2008/462 or >> 2002/202 case directories yet. Could you ping me when the contract >> is copied there? The JDS team keeps a Wiki page which references all >> contracts we need to keep track of, so I'd like to add this contract >> to the Wiki when it is available. > > Since you're the owner of 2006/202, I'll let you copy it into place there. > I'll add a link to it in 2008/462 once it's in place. Done, you can find the contract here: http://sac.eng/arc/LSARC/2006/202/contracts/LSARC-2008-462-SWT.txt Brian