flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: AW: AW: AW: AW: AW: [ASJS] Merging to Maven
Date Sat, 30 Apr 2016 05:26:32 GMT
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" <aharui@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" <aharui@adobe.com> wrote:
>
>>
>>
>>On 4/29/16, 10:37 AM, "Christofer Dutz" <christofer.dutz@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
>>
>

Mime
View raw message