@Velo - Unless you hear an outcry for CSS themes as dependencies in the 3.x line, I'd say no.
-Brian On Mar 25, 5:46 pm, Marvin Froeder <[email protected]> wrote: > Ok, but now there is no pressure to put this on 3.x > > On Thu, Mar 25, 2010 at 6:44 PM, Brian <[email protected]> wrote: > > 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 > > ... > > 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.
