Home → Problems →

Error "unable to open ... playerglobal.swc" for SDK 3.6 library project

• Edit

thomas.auinger

16 Jan, 2013 01:48 PM

I am trying to convert my code library project named "codebank" from Maven to Gradle. Build fails with

D:\Workspaces\Flex\codebank-flex>gradle build
:compileFlex
Compiling with compc
        -external-library-path+=C:\Users\aui.gradle\gradleFx\sdks\90ab805dba94e334514f108723b68558059c33d7/frameworks/libs/player/{targetPlayerMajorVersion}.{targetPlayerMinorVersion}/playerglobal.swc
        -runtime-shared-library-path=
        -external-library-path+=C:\Users\aui.gradle\gradleFx\sdks\90ab805dba94e334514f108723b68558059c33d7/frameworks/libs/framework.swc
        -include-file assets/cursor_move.gif D:\Workspaces\Flex\codebank-flex\src\main\resources\assets\cursor_move.gif
        -include-file assets/cursor_resize.gif D:\Workspaces\Flex\codebank-flex\src\main\resources\assets\cursor_resize.gif
        -target-player=10.0
        -output=D:\Workspaces\Flex\codebank-flex\build\codebank-flex.swc
[ant:java] Java Result: 1
:compileFlex FAILED







FAILURE: Build failed with an exception.

• What went wrong: Execution failed for task ':compileFlex'. > compc execution failed: Loading configuration file C:\Users\aui.gradle\gradleFx\sdks\90ab805dba94e334514f108723b68558059c33d7\frameworks\flex-config.xml command line: Error: unable to open 'C:\Users\aui.gradle\gradleFx\sdks\90ab805dba94e334514f108723b68558059c33d7/frameworks/libs/player/10.{targetPlayerMinorVersion}/playerglobal.swc'

Whats going on here?



By the way, the 3.6 SDK has sub-folders just named with the major player version (such as "9"), while the 4.6 SDK has major and minor (such as "11.1"). However, adding a player sub-folder "10.0" in my 3.6 sdk doesnt help..



The auto-installed 3.6a SDK I am using was downloaded from Adobe and then deployed to my Archiva.



Here is my build file

//
// --- setup GradleFX plugin ---
//







buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath group: 'org.gradlefx', name: 'gradlefx', version: '0.6'
    }
}







apply plugin: 'gradlefx'







//
//
//







group = 'de.byteconsult'
version = '1.9-SNAPSHOT'
type = 'swc'







ext {
    flexSdkVersion = '3.6a'
}







repositories {
     mavenRepo url: "http://svn:8081/archiva/repository/internal"
     mavenRepo url: "http://svn:8081/archiva/repository/snapshots"
     mavenCentral()
}







dependencies {
    flexSDK group: 'com.adobe', name: 'flex-sdk', version: flexSdkVersion, ext: 'zip'
}







additionalCompilerOptions = [
  '-target-player=10.0'
]

1. Support Staff 1 Posted by Yennick Trevels on 16 Jan, 2013 02:40 PM

   

   The thing is that we set this internally in GradleFx:

   -external-library-path=$flexHome/frameworks/libs/player/{targetPlayerMajorVersion}.{targetPlayerMinorVersion}/playerglobal.swc
   

   So I'll have to look how we can change this in the GradleFx code.

   Meanwhile, can you try to set the following option:

   additionalCompilerOptions = [
       "-external-library-path=$flexHome/frameworks/libs/player/{targetPlayerMajorVersion}/playerglobal.swc"
   ]
   

   This is not ideal since it overrides the other external-library options we set in GradleFx, but this will probably help you a bit further while I investigate the issue in our code.

   • Edit

2. 2 Posted by thomas.auinger on 16 Jan, 2013 02:45 PM

   

   Nope, sorry.. $flexHome is evaluated to "null":
   

   * What went wrong:
   Execution failed for task ':compileFlex'.
   > compc execution failed: Loading configuration file C:\Users\aui.gradle\gradleFx\sdks\90ab805dba94e334514f108723b68558059c33d7\frameworks\flex-config.xml
     Adobe Compc (Flex Component Compiler)command line: Error: unable to open 'null/frameworks/libs/player/10/playerglobal.swc'
   

   My build file has changed to:
   

   additionalCompilerOptions = [
       "-target-player=10.0",
       "-external-library-path=$flexHome/frameworks/libs/player/{targetPlayerMajorVersion}/playerglobal.swc"
   ]
   

   • Edit

3. Support Staff 3 Posted by Yennick Trevels on 16 Jan, 2013 02:53 PM

   

   and if you wrap the additionalCompilerOptions inside an afterEvaluate block like this:

   afterEvaluate {
      additionalCompilerOptions = [ ... ]
   }
   

   flexHome is probably evaluated during the configuration phase of Gradle, so it isn't set yet when it's gathering the additionalCompilerOptions argument. afterEvaluate allows you to set something right after this configuration phase and right before the execution phase (this is Gradle specific stuff).

   • Edit

4. Support Staff 4 Posted by Maxime Cowez on 16 Jan, 2013 02:54 PM

   

   @Yennick This does raise the question how far we're willing to go to support older SDK versions. I'd say Flex 2 is out of the question, but Flex 3 is in the twilight zone. I had a similar discussion with Christofer Dutz (FlexMojos); he says that's exactly what brought the FlexMojos codebase to its knees. All that backwards compatibility.
   It'll probably become even more complicated once/if the Apache Flex guys finish their Falcon compiler.

   @Thomas That's because the project hasn't been evaluated yet. Either replace the $flexHome token with the real path, or put it in an afterProject block ,like this:

   gradle.afterProject { project ->
        additionalCompilerOptions = [
            "-target-player=10.0",
            "-external-library-path=${project.flexHome}/frameworks/libs/player/{targetPlayerMajorVersion}/playerglobal.swc"
       ]
   }
   

   • Edit

5. 5 Posted by thomas.auinger on 16 Jan, 2013 02:55 PM

   

   BUILD SUCCESSFUL

   ;)

   PS I am happy to live with this work-around, if projects still build

   • Edit

6. Support Staff 6 Posted by Yennick Trevels on 16 Jan, 2013 03:07 PM

   

   @Maxim true, it'll spawn lot's of if-else structures if implemented badly. Flex 3 is indeed on the edge, not sure we should still support it (meaning code changes). But in the end we should have a decent strategy to handle different versions because as you say, Apache Flex will probably bring more deviations from Flex 4.6 and lower.

   @Thomas cool, I'll have a look if this can have some nasty side effects (like rsl's not working anymore)

   • Edit

7. 7 Posted by thomas.auinger on 17 Jan, 2013 01:17 PM

   

   I do have a follow-up problem now. Thing is, I cannot declare any other external library anymore, since we kind-of "hardcode" that value now. Hence all declared dependencies must be "internal", which results in a huge SWC.

   Any suggestions welcome ;)

   What surprises me is that even if I create a "10.0" folder under "frameworks/libs/player" I still get that error message

   command line: Error: unable to open 'C:\Users\aui\.gradle\gradleFx\sdks\1a2671edac53558c3e843c377acc68b216185050/frameworks/libs/player/10.{targetPlayerMinorVersion}/playerglobal.swc'
   

   Does that make sense to you?

   • Edit

8. Support Staff 8 Posted by Yennick Trevels on 17 Jan, 2013 06:14 PM

   

   That's what I was afraid for, the nasty side effects :)

   Regarding the error, it doesn't make much sense, I would expect the {targetPlayerMinorVersion} to be replaced with 0.

   I'll take a further look to see if I can find an explanation why this occurs and a possible solution.

   • Edit

9. Support Staff 9 Posted by Yennick Trevels on 17 Jan, 2013 07:12 PM

   

   I guess the reason that it doesn't replace the targetPlayerMinorVersion is that in Flex 3.6 it didn't exist yet. If you look at the flex-config.xml file in the 3.6 SDK then you'll notice that targetPlayerMinorVersion isn't used there.
   Because we set this option explicitly in Gradle as shown below, it's giving you this error:

   "-external-library-path += $flexConvention.flexHome/frameworks/libs/player/{targetPlayerMajorVersion}.{targetPlayerMinorVersion}/playerglobal.swc"
   

   Actually, I'm not entirely sure we should set this in GradleFx, since it's already in flex-config.xml. I removed the line in my local GradleFx build, and my sample project produces the same file sizes and it also works.
   @Maxim Do you know why this is added explicitly in our code? I can't remember why it's there.

   • Edit

10. Support Staff 10 Posted by Yennick Trevels on 17 Jan, 2013 09:52 PM

    

    I removed the code in GradleFx that sets the playerglobal.swc on the external-library-path since I don't think it's really necessary (independent of which Flex version). In case Maxim remembers the reason why it was added, I'll add it back, but meanwhile you can use the snapshot build with the fix.

    Use this repository declaration to use our snapshot repository:

    repositories {
        maven { url 'https://oss.sonatype.org/content/repositories/snapshots' }
    }
    

    and then use this as the GradleFx version: 0.6.4-SNAPSHOT

    • Edit

11. 11 Posted by thomas.auinger on 18 Jan, 2013 08:09 AM

    

    Yiiha! Great stuff, guys! Thanks heaps

    • Edit

12. Support Staff 12 Posted by Maxime Cowez on 18 Jan, 2013 10:19 AM

    

    @Yennick I took a look in the Git logs. It appears I introduced this code when I created the frameworkLinkage property (look for the branch feature-frameworklinkage if you want to find it in the logs yourself).

    So I would suggest testing all frameworkLinkage types before releasing your patch.
    Based on the code, I can see at least one possible issue:

        if (linkage == FrameworkLinkage.none)
            compilerArguments.add("-load-config=")
    

    which means that for a pure ActionScript project, the config file is omitted and there will be no playerglobal.swc on the build path.

    So what do we do to fix it?

    • Use the same condition to put the swc on the build path explicitly. This would still generate errors for pure AS projects compiled with a 3.x SDK.
    • Load the config file anyway. I think this may blow up the size of the pure AS application. To be tested.
    • Don't load the config file, but parse it to get the relevant node and add the swc to the build path explicitly based on this node's value, only for pure AS projects.
    • Edit

13. Support Staff 13 Posted by Yennick Trevels on 18 Jan, 2013 10:43 PM

    

    I'd go for option 3.

    • Edit

14. Support Staff 14 Posted by Maxime Cowez on 19 Jan, 2013 09:11 AM

    

    I created a new issue to address this:
    https://github.com/GradleFx/GradleFx/issues/75

    • Edit