On 1/16/17, 12:45 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:

>I would strongly object to make the FlexJS Compiler directly utilize
>Cordova. This would tightly couple the two.
>Guess I just don’t understand quite what’s the difference between the
>CordovaCameraExample which produces a Cordova project, which is then
>packaged using cordova in another step.
>I think creating an archetype for this to easily setup a new project is
>definitely a thing that should be done (eventually by myself), but I
>wouldn’t like to see the FlexJS compiler include anything Cordova
>directly.

Not sure what you mean by "include".  I don't think we would add any new
jars to the class path.  But the Publisher part of FalconJX knows certain
things about the output JS already because it has to scan all JS files to
figure out the right goog.requires anyway.  For example the inject_html
"directives" instruct on some of the content of the output HTML file, and
I'm about to commit a change where the publisher scans for @externs in
order to make it much easier to work with third-party libraries by
creating their typedefs in AS.  If a Cordova-specific publisher scanned
for "@cordovaplugin", it might greatly simplify management of Cordova
plugins in Cordova projects.  I think there is already more than one
Publisher like one for Node.

I will say, though, that I've been wondering if the Publisher piece really
belongs in the compiler in the first place.  If there is a more
Maven-friendly way to do it we should definitely try to head in that
direction.  My main thought here is that we are already scanning the JS
and we can leverage that scan to improve developer productivity for
Cordova.  But if we move that scan to something else, then that's where
the Cordova-specific functionality should move as well.  It wouldn't be
good to scan all of the JS twice.

-Alex

Reply via email to