Would it be a valid compromise to have two Cordova outputs … one that dumps the
config.xml and one that also runs Cordova?
I could live with that. Then I could continue to run Cordova in the packaging
phase.
Chris
Am 31.01.17, 21:23 schrieb "Alex Harui" <aha...@adobe.com>:
On 1/31/17, 11:51 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>So if I understand you correctly, FlexJS would be outputting an
>“apk”-file because it invokes Cordova internally?
>
>I would vote -1 on that.
>
>The problem here is that we are tightly coupling FlexJS and Cordova. We
>then have one execution, that does generation, compilation and packaging
>(Maven terms) in one step … I would like to keep the compilation and the
>packaging separate. Wouldn’t it be possible to generate the Cordova
>configuration containing the plugins needed in the compilation of a
>“type=cordova” compilation and to use that later on in the packaging
>phase of the build?
>
>As an alternative, in maven we could use a dedicated packaging type to
>automate the configuration of flexjs-maven-plugin and the
>cordova-maven-plugin to do what currently I’m manually doing in the
>examples if you activate the “with-cordova” Maven profile. On the Ant
>target you could integrate the call to Cordova, but I would not like to
>see this Cordova invocation in the compiler itself.
>
>For example, when activating the “with-cordova” profile, in
>“flexjs-framework/examples/flexjs/CordovaCameraExample/target/template/pla
>tforms/android/build/outputs/apk/android-debug.apk” the maven build
>produces the Android APK version of the application with Cordova. But
>when I just tried installing the application for the first time, this
>didn’t quite work as expected, so I would be glad for some assistance on
>what’s going wrong there. If the compiler now produced the config.xml as
>output and cordova would just pick that up, that would be great, but I
>would not like the compiler to do any more.
Well, it depends on what you mean by "compiler". Already, when you run
MXMLJSC from the command-line, it "compiles" by taking a source file and
generating an output file for it, then it packages the output files into a
"web-site" via the MXMLFlexJSPublisher class that copies all of the Google
Closure Library files and the various JS files from the SWC and generates
an index.html file.
MXMLC generates ABC files in memory for each .AS file, then packages it
into a SWF. But it currently doesn't create an index.html file. You have
to do that yourself or Flash Builder and other IDEs seem to know how to
create the html file.
In this new branch, there are many more "clients". MXMLJSC becomes a
shell that calls other clients. The default client, MXMLJSCFlex, does
what MXMLJSC does today. It takes the source files and generates JS
output for them, then calls MXMLFlexJSPublisher to copy the GCL files and
JS files from the SWC and generates the html file.
For Cordova, I am proposing to add yet another client called
MXMLJSCFlexCordova. It will run the same compile step, but then package
via MXMLFlexJSCordovaPublisher which will call Cordova CLI.
I believe that if I tweaked the CompileJSMojo to call MXMLJSCFlex, there
would be no dependencies on any code that calls Cordova CLI. And the code
to call Cordova CLI will probably just use Exec instead of calling any
Cordova JARs so these bits work in a NPM distribution. It could be that
the Maven distribution never publishes MXMLJSCFlexCordova since the Maven
way to build a Cordova app is to use POMs and Maven.
My goal is to have IDEs like Flash Builder, which default to just calling
a compiler, which today generates a runnable SWF, to be able to generate a
runnable web-site and/or a runnable mobile app without any extra steps for
the user. I don't know of a way to add another step to what the IDEs know
how to do.
I did notice that Maven has a packaging phase and have wondered if there
is yet another refactor needed to break the packaging/publishing out into
more independent modules so Maven could call them individually during a
packaging phase but Ant and IDE clients would integrate them together.
We could pass information from the compiler to the packager/publisher via
XML or some other output file if that's helpful. Is there a standard for
doing that? Right now it saves time to share data structures but it
doesn’t have to be that way.
Thoughts?
-Alex
