cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: Ant/Crosswalk woes
Date Thu, 05 Jun 2014 17:02:59 GMT
Dumb questions from someone who knows nothing about this:

(a) Is it possible to share the same directories and still get incremental
builds so long as we guard for previous build being done via the same
method?  aka, could build steps be:

if (!exists_file(last_build_was_$TYPE))

(b) Is it possible to leave the separate paths, but change the build steps
to swap directory locations just for the duration of the offending AAPT


On Thu, Jun 5, 2014 at 11:51 AM, Ian Clelland <>

> tl;dr: I'm running into an issue with the Crosswalk webview project that, I
> think, means we have to abandon our custom ant-build and ant-gen
> directories.
> Some time ago, we put in some override rules into cordova-android's Ant
> build config. This was done because the defaults, "bin" and "gen", are also
> used by Eclipse, and if you ran Eclipse and the command line tools on the
> same project, they would step all over each others' build artifacts. The
> only solution at the time was to do a full clean before each build, making
> incremental (fast) builds impossible.
> There's a problem, though -- it turns out that when the Android AAPT
> packager tool collects all of the resources from the /res/ directories, it
> is *hard coded* to put its artifacts in /bin/.
> (Here's a fun line of code:
> )
> The result of this is that the project compiles, but without all of the
> resources needed for a XWalk WebView. The app runs, but fails at run-time
> to construct the view, and falls back to the system WebView.
> This would also be a problem for any other library projects that use /res/
> folders.
> Turning off our custom build rules fixes this, but now we're back to the
> old situation. I don't see another way to handle this, though.
> I think I'm going to have to revert the commit that changed the build
> directories, on the 4.0.x branch at least. I'll add an issue for supporting
> Gradle as well; it shouldn't have this particular issue; and then at some
> point in the future we can go back to supporting fast builds again.
> Ian

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message