Likely broken after bug 1065494 lands.

Unfortunately, I think this is basically impossible with Eclipse. We've maintained a fortuitous hack to allow multiple resource directories for a long time, but this might be the end of the road. The issue is that Eclipse projects can only reference a single resource directory. What we do is make a new project per resource directory, and make the projects depend on each other. That works when there are no cyclic dependencies. We have cyclic dependencies here. I see no way forward, but I will let it rattle around for a bit.

lucasr: it appears that you only add resources in newtablet/res. It might be awkward, but how would you feel about just prefixing the entirety of newtablet/res with new_tablet_ (most already are) and copying them into resources/? I'm having a tough time getting anything with these merged resource directories to work in Android Studio, although Gradle handles this easily.

This works around the newtablet resource issue for Eclipse users. I'm throwing this up so that others can easily point impacted developers to the ticket and so that folks can easily apply the work-around.

(In reply to Nick Alexander :nalexander from comment #2) > lucasr: it appears that you only add resources in newtablet/res. It might > be awkward, but how would you feel about just prefixing the entirety of > newtablet/res with new_tablet_ (most already are) and copying them into > resources/? I'd fine with that. The only reason I created the separate resource directory was because that seemed to be only way we have right now to optionally include resources in the build i.e. ANDROID_RES_DIRS += ... Maybe we could have something like 'exclude_patterns' for resources? This way we'd be able to exclude any resources prefixed with new_tablet. With that said, I'm a bit surprised that this is not working with Eclipse given that the CrashReporter seems to use a very similar pattern. How is it different than the new tablet stuff?

(In reply to Lucas Rocha (:lucasr) from comment #4) > (In reply to Nick Alexander :nalexander from comment #2) > > lucasr: it appears that you only add resources in newtablet/res. It might > > be awkward, but how would you feel about just prefixing the entirety of > > newtablet/res with new_tablet_ (most already are) and copying them into > > resources/? > > I'd fine with that. The only reason I created the separate resource > directory was because that seemed to be only way we have right now to > optionally include resources in the build i.e. ANDROID_RES_DIRS += ... OK, good to know. > Maybe we could have something like 'exclude_patterns' for resources? This > way we'd be able to exclude any resources prefixed with new_tablet. I'd be fine with this, as a temporary measure. I'm not that concerned about temporarily shipping 50k of resources on Nightly and Aurora. > With that said, I'm a bit surprised that this is not working with Eclipse > given that the CrashReporter seems to use a very similar pattern. How is it > different than the new tablet stuff? It's delicate but it works because CR depends on the static resources (and not vice versa). The issue here is that newtablet and the static resources have cyclic dependencies (at least, right now): newtablet relies on styles and strings (and some other things); but in turn, the static resources rely on newtablet. I think it would be possible to extract shared resources into a common dependency, or to extract everything into newtablet, but that doesn't fit your optional include approach above.

(In reply to Nick Alexander :nalexander from comment #3) > I'm throwing this up so that others can easily point impacted > developers to the ticket and so that folks can easily apply the > work-around. Please add to https://wiki.mozilla.org/Mobile/Fennec/Android/Eclipse

/r/819 - Bug 1075797 - Move new tablet resources into regular resources. r=lucasr /r/821 - Bug 1075797 - Build system changes. r=lucasr Pull down these commits: hg pull review -r b33d9f554f0b5cef8b68a4ad4004d2ebea6d8a89

lucasr: I can't figure out how to comment on my review request. I talked to you about doing this in IRC, and you were against because you wanted to minimize risk. I don't see the risk here: none of the files in newtablet/res were present in resources. The build changes are tiny. Are you concerned that this will break in some way I don't understand if we flip the switch back to off? Are you concerned that a move of this sort will make uplift hard? I didn't think there was a realistic expectation of uplifting.

/r/819 - Bug 1075797 - Move new tablet resources into regular resources. r=lucasr /r/821 - Bug 1075797 - Build system changes. r=lucasr /r/825 - Bug 1102339 - Don't generate widget/Themed*.java. r=rnewman Pull down these commits: hg pull review -r adc5346c5ad3821840ee9d4299bc1b0d53ca0499

https://reviewboard.mozilla.org/r/825/#review377 ::: mobile/android/base/moz.build (Diff revision 1) > + 'widget/ThemedEditText.java', Add a comment here to indicate that these are generated files? Or add them in a separate += clause? ::: mobile/android/base/widget/ThemedEditText.java (Diff revision 1) > + I'd like a header at the top of each of these files that warns about them being generated from fragments. ::: mobile/android/base/widget/generate_themed_views.py (Diff revision 1) > + Trailing whitespace. I'm in favor of flattening these into version control. My only concern is that we make it abundantly clear that they're generated files, so we don't get quiet regressions when someone edits the output and someone else overwrites it.

Hey Nick, doing this now would mean we won't be able to exclude new tablet UI resources from the build if we, for some reason, decide to postpone the new UI to 37. Yes, this is unlikely to happen but I'd prefer to only commit to the new UI for real once this cycle is over. We can land this in the first day of the 37 cycle.

Comment on attachment 8525799 [details] MozReview Request: bz://1075797/nalexander Patch looks fine to me. Please test this with tablet ui disabled.

Let's just call it a soft dependency.