I don't think the Flash Builder Project files are going to give IntelliJ people any issues. I wouldn't object to having machine neutral IntelliJ files in there as well, as long as the various compiler specific information is in a flex-config.xml type file. That way all the various IDEs use that information and people know to look at the one specific place to see that configuration and change it if necessary.
Is there any reason the compiler config information can't be moved to a flex-config.xml type file and still work in Flash Builder and Ant? Jeff On Tue, Aug 21, 2012 at 11:25 AM, Carol Frampton <cfram...@adobe.com> wrote: > First off, these files were checked in but had the wrong headers so FB > barfed on them. I was just correcting that. > > Yes, I believe they should be checked in, but they must be system neutral > so anyone can use them. If you make any personal changes to them those > changes should not be checked in. > > If someone wants to check in corresponding build files for IntelliJ that's > fine with me as long as they are system neutral. > > System neutral means the files work on OSX or Windows and it doesn't > matter where your SDK is. > > I think FB project files are a huge pain to set up so I would not want to > have to do it myself, even if there are instructions somewhere. > > Carol > > On 8/21/12 11 :19AM, "Omar Gonzalez" <omarg.develo...@gmail.com> wrote: > >>On Tue, Aug 21, 2012 at 8:14 AM, Jeff Conrad <jeff...@gmail.com> wrote: >> >>> Hi Carol, >>> >>> I think Justin's question was more oriented around what's the best >>> practice for checking in .project, .flexLibProperties, and >>> .actionScriptProperties files? Should they be included in source >>> control or ignored? >>> >>> I took a peek at some of the files included and they contain some >>> important information that would make any potential contributor's job >>> easy. For instance, in projects/framework/.actionScriptProperties, >>> there are a ton of additional compiler arguments that if I had to put >>> into every project like that, I'd go crazy: >>> >>> >>> >>>additionalCompilerArguments="-keep-as3-metadata=Bindable,Managed,ChangeEv >>>ent,NonCommittingChangeEvent,Transient >>> -load-config+=framework-config.xml >>> --include-file=defaults.css,../defaults.css >>> -include-file=defaults-3.0.0.css,../defaults-3.0.0.css >>> -include-file=Assets.swf,../assets/Assets.swf >>> -include-file=assets/CalendarIcon.png,../assets/CalendarIcon.png >>> -namespace=library://ns.adobe.com/flex/mx,../manifest.xml >>> -namespace+=http://www.adobe.com/2006/mxml,../manifest.xml >>> -resource-bundle-list=bundles.properties -library-path= -locale=" >>> >>> I'm in favor of either keeping this information in source control. I >>> don't want to have to remember all of that to make sure I'm building >>> the SDK correctly. >>> >>> I suppose the other question that has to be asked, though, is whether >>> or not Flash Builder would be making different SWCs than the ant >>> scripts or where all of that information is included. It looks like >>> the ant scripts set the same arguments directly in the build.xml file. >>> >>> When someone gets time, maybe we can move all those arguments to >>> framework-config.xml file and have both the .actionScriptProperties >>> and build.xml file reference those so it's more DRY? I'll do it >>> sometime this week, but someone is more than welcome to beat me to it. >>> >>> Does anyone know if there's a quirk in the compiler that causes >>> information set in a flex-config.xml file to be ignored by either the >>> Ant or Flash Builder? If it's a bug in the compiler, I'll just leave >>> well enough alone until after Falcon. >>> >>> Jeff >>> >> >>Personally I would prefer that these files are not checked in, and that >>the >>necessary information for setting up projects is posted in the README and >>in Confluence. >> >>I get where you're coming from in that its easier to get up and running in >>Flash Builder, but you must also remember that not everybody uses Flash >>Builder (I don't and never will) so we still need to make this information >>easily found for people using other IDEs, such as IntelliJ, or even >>TextMate (I know, not really an IDE, but still). >> >>I would also say this is kind of the reason we use ANT to build the >>project, in other words, to decouple the source code from relying on any >>specific coding IDE. >> >>-omar >
