//////////////////////////////////////////////////////////////////////////////// // // Licensed to the Apache Software Foundation (ASF) under one or more // contributor license agreements. See the NOTICE file distributed with // this work for additional information regarding copyright ownership. // The ASF licenses this file to You under the Apache License, Version 2.0 // (the "License"); you may not use this file except in compliance with // the License. You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. // //////////////////////////////////////////////////////////////////////////////// =1= Introduction FlexTasks is an automated build tool for Flex application development. It is built on top of the Apache Ant project. FlexTasks is intended for both internal and external use in the absence of FlexTasks. =2= Description - Scenario Paul has been assigned a bug to resolve with only a few hours to spare. He refuses to use FlexBuilder, as that would take focus away from his Emacs window. He decides to write an ant build file to automate the build process: He then types into his shell (vicariously through Emacs), $ ant bug and within seconds the Flex application is built and ready for inspection by Exterminator Paul. - Details Users must first install FlexTasks by placing the distribution jar in the "lib" directory of their ant install. This will allow them to use tasks defined by FlexTasks without any special modifications to their build files (such as including a ). FlexTasks exposes all of the command line options of mxmlc through the attributes and nested elements of an task. The full name and abbreviated name of a command line option can be used interchangably when the option is implemented as an attribute. For example, and are both acceptable ways to pass the -compiler.as3 option to mxmlc. All boolean options are implemented as attributes of the element. All options that take a single argument are also implemented as attributes of the element. The descriptions of these types of options vary in the mxmlc documentation. If an option is documented as taking a , , , or some sort of path element, and that option is non-repeatable, then this option is set by setting an attribute in the element. Options that are repeatable, or take more than one argument (such as -default-size) are implemented as nested elements with attributes corresponding to the names given to arguments in the mxmlc documentation. For example, if one desired to pass the option -default-size 800 600 to mxmlc, would accomplish this. It is an error to include multiple nested elements corresponding to a non-repeatable option. There are two nested elements that can contain nested elements: and . These elements encapsulate all options starting with "compiler.fonts" and "metadata", repectively. What has been described thus far applies to these elements as well. For example, if one wanted to include contributors names along with a description of the application, the following would accomplish this: . Special case: the compiler.fonts.languages.language-range option is set by adding to a nested element, rather than a element. It may be wise to change this in the future. For more information, see the FlexTasks page on the flexteam wiki.