Ok, I'm going to have to retract my last email on this thread. My understanding of themes as it applies to Flex 4 was a bit distorted. By default, Flex 4 includes manifests and namespaces for MXML 2009, MXML 2006, Spark, and Halo components to be used in MXML. From there the theme that is applied to the build, determines which styles are supported on which components. The Halo theme only provides styles for Halo components. The Spark theme provides styles for Spark and Halo components. What was tripping me up were some of the compiler error messages. I interpreted them as saying they couldn't find the Halo components (e.g. - HBox, VBox, etc), but what was really being said was that the Spark theme doesn't support this particular style on a Halo component; in this case it was the borderSides style on an series of HBox/VBox. Once I removed these styles, compilation succeeded as with the 4.0.0.13875 and 4.0.0.14159 SDKs. There is no need to include the halo.swc theme unless you're going to only use the halo theme and Halo components or run in flex3 compatibility mode. The Spark theme supports both Spark and Halo components, just not select styles.
FWIW - The feature added as a result of this thread is still beneficial to have since themes can be CSS or SWC files. -Brian On Mar 24, 3:55 pm, Brian <[email protected]> wrote: > @Velo - Based on your feedback, I was able to get the following > working until 4.x is ready for consumption. Basically used the > dependency plugin to copy the themes into a folder that FM could use. > Thanks for the help. > > ... > > <plugin> > <artifactId>maven-dependency-plugin</artifactId> > <executions> > <execution> > <id>copy-themes-for-flex4</id> > <phase>generate-resources</phase> > <goals> > <goal>copy-dependencies</goal> > </goals> > <configuration> > <includeTypes>swc,css</includeTypes> > <outputDirectory>target/themes</outputDirectory> > <overWriteIfNewer>true</overWriteIfNewer> > <includeGroupIds>com.adobe.flex.framework</ > includeGroupIds> > <includeArtifactIds>halo,spark</includeArtifactIds> > <includeClassifiers>theme</includeClassifiers> > <stripVersion>true</stripVersion> > </configuration> > </execution> > </executions> > </plugin> > > ... > > <plugin> > <groupId>org.sonatype.flexmojos</groupId> > <artifactId>flexmojos-maven-plugin</artifactId> > ... > <configuration> > ... > <themes> > <theme>${project.build.directory}/themes/spark-theme.css</ > theme> > <theme>${project.build.directory}/themes/halo-theme.swc</ > theme> > </themes> > ... > </configuration> > </plugin> > > ... > > <!-- Themes --> > <dependency> > <groupId>com.adobe.flex.framework</groupId> > <artifactId>halo</artifactId> > <version>${flex.sdk.version}</version> > <classifier>theme</classifier> > <type>swc</type> > <scope>theme</scope> > </dependency> > <dependency> > <groupId>com.adobe.flex.framework</groupId> > <artifactId>spark</artifactId> > <version>${flex.sdk.version}</version> > <classifier>theme</classifier> > <type>css</type> > <scope>theme</scope> > </dependency> > > ... > > On Mar 24, 2:06 pm, Marvin Froeder <[email protected]> wrote: > > > On Wed, Mar 24, 2010 at 2:38 PM, Brian <[email protected]> wrote: > > > @Velo - Ok, I can see what you're saying. I guess the disconnect I'm > > > seeing is more of the way dependencies and config are being managed in > > > Maven versus the other tools out there that can re-use the notion of > > > an SDK folder and hardcoded locations. FWIW - With regards to the oem > > > compiler loading multiple config files, it looks like this is feasible > > > by calling Configuration#addConfiguration (http://opensource.adobe.com/ > > > svn/opensource/flex/sdk/tags/4.0.0.14159_RCK/modules/compiler/src/java/ > > > flex2/tools/oem/Configuration.java<http://opensource.adobe.com/%0Asvn/opensource/flex/sdk/tags/4.0.0.141...> > > > ). > > > > I guess my previous example hinged on the fact that I'm still > > > referencing themes with paths relative to the SDK folder, so it's not > > > really valid. Another example I was thinking of were the cacheable > > > framework RSL URLs that are in the default flex-config.xml for Flex 4. > > > Since they're bound to a relative path to the SDK folder I can't reuse > > > them, but how would I use them with FM 3.6 as it stands now? > > > Copy the css fils to your project on a know path and set a configuration for > > it. Is the fast workaround for now > > > > The rsl- > > > url property of each doesn't follow the same url pattern to use the > > > rslUrls configuration option and the version # for TLF is different > > > than the version FM keeps in Nexus for it. I'm guessing the FP knows > > > which cacheable RSLs to reuse based on path, so if I were to use > > > different paths for cacheable URLs wouldn't the FP be reloading my > > > RSLs even though it has them already? Is there anyway to port this > > > url config over with the current FM 3.x line? > > > RSLs path can change on every application.... and flexmojos does manage to > > copy the RSLs to war too, so not a big deal. > > > > I guess I'm trying to look for some reuse with the SDK configuration > > > where there just may not be any to help the migration process from SDK > > > and FM version to version. Definitely a daunting task you have ahead > > > of you; I'm grateful for all the work you're putting in, especially > > > after digging into this problem further. If I come up with a patch > > > for loading css files as dependencies for the 3.x line I'll send it > > > your way. Thanks again for the help; let me know what you think about > > > the RSL url question. > > > > -Brian > > > > On Mar 24, 10:37 am, Marvin Froeder <[email protected]> wrote: > > > > On Wed, Mar 24, 2010 at 11:17 AM, Brian <[email protected]> wrote: > > > > > @Velo - Thanks for the quick response and making it through my > > > > > details. I've filed an improvement request to add support to CSS > > > > > files as theme dependencies @ > > > > >https://issues.sonatype.org/browse/FLEXMOJOS-286. > > > > > There are 4 themes that come with the SDK that would need to be > > > > > included in the framework-configs.zip file: Halo, Spark, > > > > > AeonGraphical, and Wireframe. You wouldn't have to include the > > > > > compiler flags to use them, but providing a way to say you'd like to > > > > > use them w/o uploading a copy to your own artifact repo would be > > > > > helpful (e.g - deploying stock themes to the FM artifact repo). > > > > > > You mentioned "... I only deploy the flex-config.xml because flex > > > > > compiler does need this files, they can be empty (because they aren't > > > > > really necessary)". Right now it's my understanding that the default > > > > > flex-config.xml and air-config.xml files that comes with the SDK are > > > > > used to convey the Adobe set of standard defaults. > > > > > No, it points to a set of hard coded requirements inside the SDK bundle. > > > > For instance, flex-config.xml, if you do not set this option it > > > > automagically assume ../framework/flex-config.xml but if you set it to > > > "", > > > > it just works.... > > > > > Similar thing happen with fonts.ser files.... if you point it to > > > > localFonts.ser it works fine. And localFonts.ser is just an empty file. > > > > > The themes... if you do not set, flex 4 hardcode it to > > > > ../frameworks/themes/spark/spark.css, but again, if I set the theme to > > > > "" > > > it > > > > allows it to run.... > > > > > Anyway, this defaults are hardcoded, but instead of hardcoding it on the > > > > code, which would make it more reusable, Adobe prefer to hardcode it on > > > some > > > > location inside the SDK bundle, which prevent tools like maven from > > > working > > > > w/o overwriting this stuff to other hardcoded locations.... > > > > > > When a new SDK > > > > > ships, these files are updated so that the recommended defaults are > > > > > pushed to anyone using the defaults with their tools. Flash Builder, > > > > > the Flex compilers, and the Flex SDK Ant tasks all use the flex- > > > > > config.xml as a central configuration point and then diverge based on > > > > > user configuration. If FM, is dynamically building the equivalent of > > > > > user configuration portion, similar to the other tools, shouldn't it > > > > > base its default config off of the SDK default files (e.g. - flex- > > > > > config.xml)? I understand there would still be growing pains, as > > > > > there are now, to match up configuration options offered in the SDK > > > > > with FM features, but at the very least couldn't people specify a new > > > > > set of defaults if feature parity wasn't available in FlexMojos? > > > > > Oem api doesn't provide me the means to do that, and still this defaults > > > are > > > > hardcoded locations on hard drive, usually relative locations to JVM > > > launch > > > > directory, so there is no easy way to handle it, at least not w/o > > > > forking > > > > the VM.... > > > > > > Case > > > > > in point, support for multiple SDK themes using a new default flex- > > > > > config.xml before the CSS theme artifact feature is ready? Right now, > > > > > from what I understand, FlexMojos offers building with a custom flex- > > > > > config.xml, but not the ability to override the settings in that > > > > > custom flex-config.xml file once you've said to use it as a config > > > > > option (configFile option in compile-swf/swc). What do you think? > > > > > I missed you here.... > > > > > > -Brian > > > > > > On Mar 24, 3:21 am, Marvin Froeder <[email protected]> wrote: > > > > > > On Wed, Mar 24, 2010 at 2:02 AM, Brian <[email protected]> wrote: > > > > > > > Ok, so I've been racking my brain over getting a Flex 4 app we've > > > > > > > written using beta 2 working with 4.0.0.13875. It uses a > > > combination > > > > > > > of halo and spark components and I've been able to resolve all > > > > > > > compilation errors except for having the Halo and Spark themes > > > being > > > > > > > used together at compilation. Please note, I've updated the halo > > > > > > > namespace to the mx namespace as well as migrated all spark > > > components > > > > > > > that have changed from beta2. > > > > > > > > I've tried the following permutations with FlexMojos 3.6 to no > > > avail: > > > > --------------------------------------------------------------------------------------------------------- > > > > > > > > Tried: Deploying a new framework-configs-4.0.0.13875.zip to my > > > local > > > > > > > nexus repo with both the Halo and Spark themes in their > > > > > > > appropriate > > > > > > > folders and updating the flex-config.xml file to also use the > > > halo.swc > > > > > > > as a theme. I also tried commenting out all themes, as done in > > > > > > > previous SDK releases of the flex-config.xml file, with the same > > > > > > > results as given below. > > > > > > > > Result: The changes to the flex-config.xml are ignored by the > > > compile- > > > > > > > swf/swc goals and only the spark.css file is listed as the theme > > > > > > > to > > > > > > > use to the compiler. I receive compilation errors for unknown > > > > > > > components in the mx namespace due to the lack of the halo.swc > > > > > > > file > > > > > > > being present as a theme. > > > > > > > DO NOT CORRUPT THE ORIGINAL FILES, THAT IS THE BEST WAY TO SCREW > > > > > FLEXMOJOS > > > > > > BEHAVIOR. NUKE THIS! This is kinda change Java > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "Flex Mojos" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/flex-mojos http://flexmojos.sonatype.org/ To unsubscribe from this group, send email to flex-mojos+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
