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 29A48D99E for ; Sat, 8 Dec 2012 00:27:58 +0000 (UTC) Received: (qmail 20364 invoked by uid 500); 8 Dec 2012 00:27:57 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 20335 invoked by uid 500); 8 Dec 2012 00:27:57 -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 20326 invoked by uid 99); 8 Dec 2012 00:27:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Dec 2012 00:27:57 +0000 X-ASF-Spam-Status: No, hits=1.0 required=5.0 tests=FRT_ADOBE2,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [69.167.147.50] (HELO franklin.liquidweb.com) (69.167.147.50) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Dec 2012 00:27:50 +0000 Received: from localhost ([127.0.0.1]:35755) by franklin.liquidweb.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Th8GO-00051E-Tb for flex-dev@incubator.apache.org; Fri, 07 Dec 2012 19:27:28 -0500 Received: from 71.181.122.158 ([71.181.122.158]) by franklin.liquidweb.com (Horde Framework) with HTTP; Fri, 07 Dec 2012 19:27:28 -0500 Message-ID: <20121207192728.19055a41nftf3ddc@franklin.liquidweb.com> Date: Fri, 07 Dec 2012 19:27:28 -0500 From: Michael Schmalle To: flex-dev@incubator.apache.org Subject: Re: [Falcon] Unit tests failing References: <149F8129B58B2D418508E63117D9C5419B5B623C01@nambx05.corp.adobe.com> <149F8129B58B2D418508E63117D9C5419B5B623C10@nambx05.corp.adobe.com> <149F8129B58B2D418508E63117D9C5419B5B623C19@nambx05.corp.adobe.com> <20121207191021.64203ir7ey3aapgt@franklin.liquidweb.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.8) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - franklin.liquidweb.com X-AntiAbuse: Original Domain - incubator.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - teotigraphix.com X-Get-Message-Sender-Via: franklin.liquidweb.com: authenticated_id: teotigra/from_h X-Source: X-Source-Args: X-Source-Dir: X-Virus-Checked: Checked by ClamAV on apache.org Quoting Chema Balsas : > The only problem with that is that if you're fixing things in the sdk so > that the tests pass, you need to run ant eclipse everytime you change > something to bring your changes over from the develop branch, right? Ah, your right about this, it would have to be copied over again. But copying an sdk with a build target is easier than adding compiler flags any day. :) > If you get to configure the variables properly the tests will always pick > the latests changes on the sdk directly (which it's not necessarily good... > just depends on what you're doing, of course). > > We could have 'ant eclipse' to copy the sdk and 'ant eclipse-no-sdk' to be > able to decide :) Right, It's just getting the setup correct. Which as Gordon and I have mentioned is hard when running straight eclipse junit, like a method (no access to the build properties). Whats the solution? :) Mike > 2012/12/8 Michael Schmalle > >> >> See all this got changed and I didn't know about it. I spent way to much >> time on something I could have just run a build target on! :) >> >> Ow that hurts. I was seriously about ready to give up. >> >> So I guess I can now ditch the compiler arg crap and just copy the sdk >> over. >> >> >> Mike >> >> Quoting Gordon Smith : >> >> I'm fine with just having 'ant eclipse' do 'ant copy.sdk'. Alex shouldn't >>> care because he doesn't use Eclipse. :) >>> >>> - Gordon >>> >>> >>> -----Original Message----- >>> From: Chema Balsas [mailto:jbalsas@gmail.com] >>> Sent: Friday, December 07, 2012 4:05 PM >>> To: flex-dev@incubator.apache.org >>> Subject: Re: [Falcon] Unit tests failing >>> >>> I couldn't find anything in Eclipse either. The only place is >>> /etc/launchd.conf (it was ~/MacOS/environment.plist before) which is quite >>> like ~/.profile but for GUI apps. >>> >>> I personally think this is quite complicated, and documentation for this >>> is scarce at the best... >>> >>> 2012/12/8 Gordon Smith >>> >>> > Can this really be possible that there is no place to configure >>>> > Junit's >>>> runtime environment from within Eclipse? >>>> >>>> I looked in the workspace preferences dialog under Run/Debug > >>>> Launching but didn't see a way to do anything useful. >>>> >>>> - Gordon >>>> >>>> -----Original Message----- >>>> From: Alex Harui [mailto:aharui@adobe.com] >>>> Sent: Friday, December 07, 2012 3:52 PM >>>> To: flex-dev@incubator.apache.org >>>> Subject: Re: [Falcon] Unit tests failing >>>> >>>> >>>> >>>> >>>> On 12/7/12 3:48 PM, "Gordon Smith" wrote: >>>> >>>> > And it should NOT require any voodoo to launch Eclipse, such as a >>>> > launch script. >>>> Agreed >>>> > >>>> > I would be able to tolerate it requiring a one-time setup in the >>>> > Eclipse workspace, but I can't find any place to configure >>>> > environment variables there. >>>> Can this really be possible that there is no place to configure >>>> Junit's runtime environment from within Eclipse? >>>> > >>>> > - Gordon >>>> > >>>> > >>>> > -----Original Message----- >>>> > From: Gordon Smith [mailto:gosmith@adobe.com] >>>> > Sent: Friday, December 07, 2012 3:45 PM >>>> > To: flex-dev@incubator.apache.org >>>> > Subject: RE: [Falcon] Unit tests failing >>>> > >>>> > All unit tests (at least for Falcon) should be zero-configuration. >>>> > You open up a file like MXMLArrayTagTests.java. You double-click the >>>> > name of an individual test you want to debug, such as the first one, >>>> > MXMLArrayTag_empty(), to select it. Then you right-click on it and >>>> > choose Debug As > JUnit Test from the context menu. It should just >>>> > work. The default debug configuration that gets created for this >>>> > test needs to be sufficient without any additional Program Arguments >>>> > or VM >>>> Arguments. >>>> > >>>> > - Gordon >>>> > >>>> > -----Original Message----- >>>> > From: Alex Harui [mailto:aharui@adobe.com] >>>> > Sent: Friday, December 07, 2012 3:36 PM >>>> > To: flex-dev@incubator.apache.org >>>> > Subject: Re: [Falcon] Unit tests failing >>>> > >>>> > The copy.sdk target is still in there if you need it. >>>> > >>>> > But first, wow do you use the unit tests from Eclipse? I've never >>>> > tried it, I always use the command line. Do you set up a run config >>>> > of some sort? If you set a FLEX_HOME in the config's environment >>>> > does >>>> that work? >>>> > >>>> > Once I understand how you use Eclipse I will try to get it to work. >>>> > >>>> > >>>> > On 12/7/12 3:27 PM, "Gordon Smith" wrote: >>>> > >>>> >> After trying and failing to do any Falcon work today, I'll keep >>>> >> complaining about this. The unit tests are no longer working in >>>> >> Eclipse. I get >>>> >> >>>> >> command line >>>> >> Error: unable to open >>>> >> 'D:\Apache\incubator\flex\**falcon\trunk\compiler\** >>>> generated\dist\sdk\ >>>> >> fr >>>> >> a >>>> >> meworks\ >>>> >> mxml-2009-manifest.xml'. >>>> >> >>>> >> command line >>>> >> Error: unable to open >>>> >> 'D:\Apache\incubator\flex\**falcon\trunk\compiler\** >>>> generated\dist\sdk\ >>>> >> fr >>>> >> a >>>> >> meworks\ >>>> >> libs\player\11.1\playerglobal.**swc'. >>>> >> >>>> >> This is presumably because the SDK is no longer being copied into a >>>> >> place that the unit tests can find them. The unit tests can't use >>>> >> an environment variable to find them because it is infeasible to >>>> >> specify that environment every time you want to make an Eclipse >>>> >> debug config for a particular unit test. >>>> >> >>>> >> Is there some way to make this work in Eclipse that I don't know >>>> >> about, so that every JUnit test "just work" without having to >>>> >> customize a run-config or debug-config for it? >>>> >> >>>> >> If not, I will restore some ant targets to do the SDK copying. Alex >>>> >> may not want to use them, but I need to. >>>> >> >>>> >> - Gordon >>>> >> >>>> >> >>>> >> -----Original Message----- >>>> >> From: Gordon Smith >>>> >> Sent: Thursday, December 06, 2012 2:58 PM >>>> >> To: flex-dev@incubator.apache.org >>>> >> Subject: RE: [Falcon] Unit tests failing >>>> >> >>>> >> OK, then I'll stop complaining. >>>> >> >>>> >> - Gordon >>>> >> >>>> >> -----Original Message----- >>>> >> From: Alex Harui [mailto:aharui@adobe.com] >>>> >> Sent: Thursday, December 06, 2012 1:59 PM >>>> >> To: flex-dev@incubator.apache.org >>>> >> Subject: Re: [Falcon] Unit tests failing >>>> >> >>>> >> The versions in compiler/commandline already looked for FLEX_HOME >>>> >> environment variable. >>>> >> >>>> >> >>>> >> On 12/6/12 1:56 PM, "Gordon Smith" wrote: >>>> >> >>>> >>> I should have said Falcon's 'mxmlc' and 'compc' shell scripts. >>>> >>> >>>> >>> - Gordon >>>> >>> >>>> >>> -----Original Message----- >>>> >>> From: Gordon Smith >>>> >>> Sent: Thursday, December 06, 2012 1:55 PM >>>> >>> To: flex-dev@incubator.apache.org >>>> >>> Subject: RE: [Falcon] Unit tests failing >>>> >>> >>>> >>> So, how does Falcon's 'asc' shell script do its job? Did you make >>>> >>> it use an environment variable to find an SDK? >>>> >>> >>>> >>> - Gordon >>>> >>> >>>> >>> -----Original Message----- >>>> >>> From: Alex Harui [mailto:aharui@adobe.com] >>>> >>> Sent: Thursday, December 06, 2012 1:40 PM >>>> >>> To: flex-dev@incubator.apache.org >>>> >>> Subject: Re: [Falcon] Unit tests failing >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> On 12/6/12 12:57 PM, "Gordon Smith" wrote: >>>> >>> >>>> >>>> But doesn't it make it impossible to use Falcon's shell scripts, >>>> >>>> which expect to find other things in the SDK using relative paths >>>> >>>> from those shell scripts??? >>>> >>> You mean like the mxmlc and compc scripts? They take a FLEX_HOME >>>> >>> environment variable and seem to be working. >>>> >>>> >>>> >>>> Falcon isn't going to be independent of the SDK in the sense of >>>> >>>> being external to it. The goal is for it to replace the old >>>> >>>> compiler >>>> >>>> *in* the SDK. I don't want to be polluting an SDK with Falcon >>>> >>>> until it is ready, but it made sense to me to copy whatever SDK >>>> >>>> you want test Falcon with into Falcon's directory, so that >>>> >>>> everything is relative to each other as it will eventually be. >>>> >>>> >>>> >>> I guess I haven't given up on the vision of Falcon being so >>>> >>> independent that it doesn't have to be in every SDK release. For >>>> >>> sure, I am currently working on a "new SDK" and I want Falcon and >>>> >>> FalconJS to work with it. I want to finish the vision of not >>>> >>> having to change Falcon for every version of the SDK. >>>> >>> That would eventually allow the SDK folder to not contain any java >>>> >>> code, and changing SDK versions becomes a matter of changing SWCs >>>> >>> and not JARs. >>>> >>> >>>> >>> And I don't want to eliminate the possibility that someone will >>>> >>> take on the effort to integrate Falcon into an IDE. >>>> >>> >>>> >>> -- >>>> >>> Alex Harui >>>> >>> Flex SDK Team >>>> >>> Adobe Systems, Inc. >>>> >>> http://blogs.adobe.com/aharui >>>> >>> >>>> >> >>>> >> -- >>>> >> Alex Harui >>>> >> Flex SDK Team >>>> >> Adobe Systems, Inc. >>>> >> http://blogs.adobe.com/aharui >>>> >> >>>> > >>>> > -- >>>> > Alex Harui >>>> > Flex SDK Team >>>> > Adobe Systems, Inc. >>>> > http://blogs.adobe.com/aharui >>>> > >>>> >>>> -- >>>> Alex Harui >>>> Flex SDK Team >>>> Adobe Systems, Inc. >>>> http://blogs.adobe.com/aharui >>>> >>>> >>>> >>> >> -- >> Michael Schmalle - Teoti Graphix, LLC >> http://www.teotigraphix.com >> http://blog.teotigraphix.com >> >> > -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com