I am going to merge to develop. The changes to flex-falcon require fiddling with the build.xml files in flex-asjs, which I've already done in maven-migration. If I duplicate some of the changes in develop I might get more merge conflicts on the eventual merge, so I might as well do it now.
-Alex On 4/29/16, 5:08 PM, "Alex Harui" <aha...@adobe.com> wrote: >I just got the flex-asjs build to run in the maven-migration branch. I >had to touch the compile-as-config.xml and compile-js-config.xml files. >My understanding is that they get copied to the target folder and paths >are relative from there, and I saw references to ../src/main/resources >which I had to add to a few other places, or are you thinking we'll copy >more stuff to target? > >I'm tempted to merge these changes into the develop branch. > >Thoughts? >-Alex > >On 4/29/16, 11:12 AM, "Alex Harui" <aha...@adobe.com> wrote: > >> >> >>On 4/29/16, 10:37 AM, "Christofer Dutz" <christofer.d...@c-ware.de> >>wrote: >> >>> >>>Hi Alex, >>> >>>but I sort of get at least 3 runs: >>>1. Sort of generate JavaScript from the ActionScript >>>2. Compile the ActionScript and include the JavaScript >>>3. Compile the extern >> >>Yes it should be 3 and no more than 3. >> >>> >>>So in Maven-speak I would propose to compile the normal swc to the main >>>artifact for a module and compile the extern to the same module, but use >>>a classifier "extern" for this (I know that probably the "classifier" >>>will not ring a bell for you, but I hope it will soon). I could >>>implement >>>the compiler that for each swc it tries to resolve the "extern" artifact >>>for the same module, if it gets one, it adds that to the library path, >>>if >>>not, it doesn't. The Problem is that Maven will probably handle this, >>>but >>>I doubt the IDEs will. >>> >>>In any other solution this including the different parts of the same >>>module is going to drive people nuts. We deffinitely have to fix this. >> >>I'm not sure what you think needs fixing. I think we must support >>libraries that have API signatures that can be different on different >>platforms. Do any other Maven projects support single code base to >>multiple platforms? Or maybe single code base with conditional >>compilation to different versions or vendors of Java? IOW, different >>flavors of artifacts are going to be required. Maybe that's a >>classifier, >>or maybe it is something else, but I would hope Maven supports something >>like this. >> >>With my limited knowledge of Maven, it seems like we might need more than >>one pom.xml per project or create separate projects for the "extern" swcs >>that share the same source code. In fact, the latter is how I'm >>currently >>setting up Flash Builder. I'm going to try to illustrate a simple case >>below: >> >>Core project needs to produce: >>- .js files compiled with COMPILE::AS3=false,COMPILE::JS=true >>- .swc compiled with COMPILE::AS3=true,COMPILE::JS=false, including .js >>files >>- .swc compiled with COMPILE::AS3=false,COMPILE::JS=true >> >>I think you got that far, but now look at some downstream swc like >>Binding. It needs to produce: >>- .js files compiled with COMPILE::AS3=false,COMPILE::JS=true but with >>the >>Core.swc compiled with COMPILE::AS3=false,COMPILE::JS=true as a >>dependency >>for the -library-path. >>- .swc compiled with COMPILE::AS3=true,COMPILE::JS=false, including .js >>files but with the Core.swc compiled with >>COMPILE::AS3=true,COMPILE::JS=false as a dependency on the >>-external-library-path >>- .swc compiled with COMPILE::AS3=false,COMPILE::JS=true but with the >>Core.swc compiled with COMPILE::AS3=false,COMPILE::JS=true as a >>dependency >>for the -library-path (and maybe someday, on the -external-library-path >>instead of -library-path). >> >>Hopefully you can see that the different compiles in Binding have >>different upstream dependencies. It wasn't clear from what I read about >>classifiers that you could switch upstream dependencies that with a >>classifier. Classifiers just seem to label the output artifact. We need >>a solution for a single code base to be used to create different results >>with different dependency sets. >> >>Or maybe it should be 3 projects, one for each step? It'll be a pain in >>Ant to refactor to two or three projects per current project, but it is >>doable since Ant can just use relative paths to find things like the >>shared source code. >> >>Thoughts? >>-Alex >> >
