I think Adobe's build machines had some scripts that set build.number to the Perforce revision number that it was building.
- Gordon -----Original Message----- From: Chema Balsas [mailto:jbal...@gmail.com] Sent: Tuesday, December 04, 2012 6:08 PM To: flex-dev@incubator.apache.org Subject: Re: Falcon SDKSWCTests Ok, I've submitted a patch for that ( https://issues.apache.org/jira/browse/FLEX-33286). I've checked and those were the only projects including that file. I've also checked, and the content of version.properties always seems to be "build=0". I've even compiled without including the file and everything seems to be working. Could we just remove those references completely or there may be some other side effects? Chema 2012/12/5 Gordon Smith <gosm...@adobe.com> > In that case, let's move -include-file option for version.properties > back out of compile-config.xml and into the <compc> task. > > - Gordon > > -----Original Message----- > From: Chema Balsas [mailto:jbal...@gmail.com] > Sent: Tuesday, December 04, 2012 5:22 PM > To: flex-dev@incubator.apache.org > Subject: Re: Falcon SDKSWCTests > > Hi Cyril, > > The version.properties file is created and removed inside the compile > target for those projects. > > It is generated at the beginning of the target by: > <echo file="${FLEX_HOME}/frameworks/version.properties" > append="false">build=${build.number}</echo> > > And then removed at the end by: > <delete file="${FLEX_HOME}/frameworks/version.properties"/> > > which is why you shouldn't find it ;) > > 2012/12/5 Cyrill Zadra <cyrill.za...@gmail.com> > > > Hey Chema > > > > In the follwing compile-config.xml is the version.properties included. > > > > rpc > > spark > > spark_dmv > > > > <include-file> > > <name>version.properties</name> > > <path>../../version.properties</path> > > </include-file> > > > > In my builded flex sdk it does not exists. Is that part really used > > or can it be removed? Or does anyone know how this > > version.properties is generated? > > > > Cyrill > > > > > > > > > > On Mon, Dec 3, 2012 at 8:16 AM, Chema Balsas <jbal...@gmail.com> wrote: > > > @Cyril Thanks for noticing! > > > > > > @Gordon You're welcome! I'm really happy to see all this movement > > > around Falcon/FalconJS lately :) > > > > > > > > > 2012/12/1 Gordon Smith <gosm...@adobe.com> > > > > > >> Oops! Thank you @Chema! > > >> > > >> Sent from my iPad > > >> > > >> On Nov 30, 2012, at 7:09 PM, "Cyrill Zadra" > > >> <cyrill.za...@gmail.com> > > >> wrote: > > >> > > >> > Hi Gordon > > >> > > > >> >> @Cyril: Thanks for your help with introducing the > > >> >> compile-config.xml > > >> files so that we can more easily make Falcon JUnit tests that > > >> compile > > each > > >> SDK SWC. > > >> > > > >> > That wasn't me .. I think that work was done by Chema Balsas > > >> > (see > > [1]). > > >> > > > >> > [1] https://issues.apache.org/jira/browse/FLEX-33226 > > >> > > > >> > On Fri, Nov 30, 2012 at 1:09 PM, Gordon Smith > > >> > <gosm...@adobe.com> > > wrote: > > >> >> @Cyril: Thanks for your help with introducing the > > >> >> compile-config.xml > > >> files so that we can more easily make Falcon JUnit tests that > > >> compile > > each > > >> SDK SWC. > > >> >> > > >> >> Now that we have one such test - for compiling framework.swc - > > passing, > > >> would anybody like to work on investigating the status of other > > >> tests > > that > > >> compile rpc.swc, mx.swc, spark.swc, etc.? We need to figure out > > >> whether > > the > > >> SDK source code needs to change because Falcon is pickier than > > >> the old compiler, or whether Falcon has AS bugs that need to be fixed. > > >> >> > > >> >> - Gordon > > >> >> > > >> > > >
