Aggregating responses to multiple mails: You couldn't find anything in Maven-central, cause we never released it as maven artifact. What I'm doing currently is simply mavenizing the 4.15 FDK and referencing the swfutils from there, but that dependency doesn't have any further dependencies, but that's just because I didn't model them in the mavenizer.
Regarding the double run externc ... I noticed this too ... but I think I managed to get everything working with just one pass in the Maven build. In order to get things running I compared the output with the final output of the Ant JavaScript and re-engineered ALL of the replacement operations. So eventually looking at the replacements of the maven build could eliminate the need to run externc twice. So you want/did add the source files of swfutils to the falcon projects? in what branch did you do that? Can I now remove the dependency to the Flex 4.15 SDK? Regarding the merge ... I'm ready when you are. Chris ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Freitag, 22. April 2016 18:35 An: dev@flex.apache.org Betreff: Re: AW: AW: AW: [FlexJS] Status on Maven migration On 4/22/16, 1:11 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >I'm currently just pulling the jar from the latest SDK release ... >anything wrong with that? IIRC, swfutils may have other dependencies on Flex SDK jars and end up pulling lots of stuff in, including classes I'm trying to replace with versions of mxmlc and compc that proxy in to Falcon. I was able to find this subset of swfutils that works for both flex-compiler-oem and debugger and doesn't bring in un-needed stuff. I couldn't find swfutils in maven central or a pom.xml for it to see what its dependencies are. I also found another issue: the externs/createjs project was running externc twice, once with the js-root option. I remembered as I was working on that part of the Ant build that the reason it is called twice is to "sanitize" the .js files before they are put into the SWC so that the Google Closure Compiler will correctly use them as externs files. The CreateJS source files are brought down, munged with various replace/sed tasks into a state where ExternC can use them to create .as files, but later in the workflow, the Google Closure Compiler wants more cleanly formatted .js files to use as externs during minification/optimization. So I was thinking of directing the output of the js-root pass to target/generated-sources/externs, and modifying the compile-as-config.xml to pick up the <include-files> from there. Is that ok? Thanks, -Alex
