Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D337AD506 for ; Tue, 7 Aug 2012 19:45:27 +0000 (UTC) Received: (qmail 96971 invoked by uid 500); 7 Aug 2012 19:45:26 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 96925 invoked by uid 500); 7 Aug 2012 19:45:26 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 96917 invoked by uid 99); 7 Aug 2012 19:45:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Aug 2012 19:45:26 +0000 X-ASF-Spam-Status: No, hits=-1.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of aharui@adobe.com designates 64.18.1.183 as permitted sender) Received: from [64.18.1.183] (HELO exprod6og102.obsmtp.com) (64.18.1.183) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Aug 2012 19:45:16 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUCFwNr4RvDpAbzErepGTfWcTX132uvtY@postini.com; Tue, 07 Aug 2012 12:44:55 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q77Jir8N001918 for ; Tue, 7 Aug 2012 12:44:53 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q77Jiqvm029815 for ; Tue, 7 Aug 2012 12:44:52 -0700 (PDT) Received: from NAMBX02.corp.adobe.com ([10.8.127.96]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Tue, 7 Aug 2012 12:44:52 -0700 From: Alex Harui To: "flex-dev@incubator.apache.org" Date: Tue, 7 Aug 2012 12:44:48 -0700 Subject: RE: [MENTOR] Source code layout for committers Thread-Topic: [MENTOR] Source code layout for committers Thread-Index: Ac100xQ5KUUM4bGGRh6oeFB4RG0t7wAAPGBg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 > -----Original Message----- > From: Greg Reddin [mailto:gredbug@gmail.com] > Sent: Tuesday, August 07, 2012 12:30 PM > To: flex-dev@incubator.apache.org > Subject: Re: [MENTOR] Source code layout for committers >=20 > On Tue, Aug 7, 2012 at 1:22 PM, Alex Harui wrote: > > While that's fine for the vast majority of users that are just > consumers of the SDK, my question is about the committers and other > folks who want to make changes to the SDK. Is there any Apache policy > that requires committers to have "clean" source code layouts such that > no non-compatible licensed files are mixed into the source tree? Or do > folks just have to be careful that they don't accidentally modify or > check in something they shouldn't? >=20 > Apache can't control what committers do with the code once they check > it out to their machines. If they want to fold non-compatible code > into the tree they checked out they can -- so long as they don't > commit any of it back to the repo. >=20 > I think we need a better story for this though. It seems dangerous to > me to have a working copy of a source code tree with stuff folded into > it that you don't want to commit. How hard would it be to set up some > svn:ignore properties for the files that get folded in? Is that enough > to ensure they don't get committed (at least that would ensure they > don't get committed by mistake without some kind of warning)? That's > basically what we do with Maven projects to keep from checking in the > target directory, for example. >=20 > Greg I think there is probably a better story. I hadn't thought of svn:ignore, we can certainly explore that, but also, in theory it should be possible to use Flash Builder to work on Apache Flex, but it just wouldn't recognize the results as an Apache Flex SDK. Which would hopefully be fine when you're in the mode of changing the SDK. Then when you want to=20 build apps on top of the SDK, you can run the build and maybe some other script that copies your new libraries out to some folder tree that does look like an SDK to Flash Builder. I will explore these options now that I know at someone else thinks something like this is worth looking into. Alex Harui Flex SDK Developer Adobe Systems Inc. Blog: http://blogs.adobe.com/aharui