According to this issue<http://code.google.com/p/android/issues/detail?id=2018#c64>this has been marked as "Released" and the last message says "This is largely possible in the Gradle build system as it exists today". However I couldn't find a sample to achieve this. Also because the message says "... largely possible ...", I would think that it isn't fully possible. What part is missing and will it (ever) be completed?
On Saturday, October 13, 2012 6:01:11 AM UTC+2, Manfred Moser wrote: > > Well.. if it makes it easier... now is the time to do it. There > definitely seems to be a need for it.. > > manfred > > On Fri, Oct 12, 2012 at 8:57 PM, Xavier Ducrohet > <[email protected]<javascript:>> > wrote: > > I would almost prefer to have a different type of projects: > > - resource only > > - no manifest > > - no dependencies > > > > This would be much easier to handle those at the app project level. > > > > On Fri, Oct 12, 2012 at 8:48 PM, Manfred Moser > > <[email protected]<javascript:>> > wrote: > >> Sounds like a plan ;-) > >> > >> You could also have a switch that causes not to generate separate R > >> classes for libraries that use the same package space and if there are > >> duplicate resources fail the build hard with an explicit message. > >> > >> manfred > >> > >> On Fri, Oct 12, 2012 at 5:55 PM, Xavier Ducrohet > >> <[email protected]<javascript:>> > wrote: > >>> The issue with android archives is that there's a cost to them in the > >>> app with multiple R classes (although we could detect no source code > >>> and not generate it), but the dependency has an order and library > >>> resources override resources from other libraries. > >>> > >>> I think the proper way to have res only packages would have to detect > >>> conflict and break the build on conflicts. > >>> > >>> > >>> > >>> On Fri, Oct 12, 2012 at 3:59 PM, Manfred Moser > >>> <[email protected]<javascript:>> > wrote: > >>>> I think this is one of the perfect use cases for the android archive > format. > >>>> > >>>> You could e.g. have one project that only has the resources for > store, > >>>> the next one for player and so on. > >>>> > >>>> Each could also have the respective code and more. > >>>> > >>>> Then you could basically build and application by declaring > >>>> dependencies to these different android archives (aar) and write the > >>>> glue code to stick it together > >>>> > >>>> and you could even do lots of different ones. > >>>> > >>>> Another use case would be a white labelled application and resource > >>>> bundles that just contain the theme and related customizations .. > >>>> > >>>> Each branded app would just declare the theme and the white labelled > >>>> app as dependencies and stick it together.. > >>>> > >>>> Once this works the pain of having lots of resources in one project > >>>> automatically goes away.. > >>>> > >>>> This is already possible now with the apklib format and the android > >>>> maven plugin but the new gradle build and the aar format will make > >>>> this even more powerful (and yes the maven plugin will support that > >>>> too).. > >>>> > >>>> manfred > >>>> > >>>> On Fri, Oct 12, 2012 at 11:49 AM, Xavier Ducrohet > >>>> <[email protected]<javascript:>> > wrote: > >>>>> It might be possible to have sub folders under the main ones, but > >>>>> probably not in conjunction with having drawable/ldpi. > >>>>> Also it would probably be limited to one level of sub-folders. > >>>>> > >>>>> No guarantees though, I have to see how disruptive that would be in > >>>>> the tools. The impact in ADT in particular might be non-negligible. > >>>>> > >>>>> One other thing we've been thinking about is bundles. This is to > >>>>> answer another problem but we may as well discussed it here too. > >>>>> > >>>>> There are cases where resources depend on other resources that are > >>>>> likely not used on their own. > >>>>> For instance, creating a custom button requires a drawable selector > >>>>> that redirects to some 9-patches. The 9-patches are never used > except > >>>>> in the selector. > >>>>> One issue is removing the selector or updating it (changing the name > >>>>> of the 9-patches) but not removing the old 9-patches won't lead to > any > >>>>> compilation issue since (in most case) the 9-patches are used > directly > >>>>> by other resources or code. So the app still works but there are > >>>>> obsolete resources in it. > >>>>> Other examples could be custom themes which would use colors, > drawables, etc... > >>>>> > >>>>> The idea is to have a bundle (zip archive) that contains files in a > >>>>> structure similar to the res folder. Those are put in the project > >>>>> folder somewhere and at built time this is used as additional > resource > >>>>> folders (after extraction). > >>>>> Of course we'd need tools to create such bundles (selector editor, > >>>>> theme/style editor, etc...) > >>>>> > >>>>> thoughts? > >>>>> > >>>>> On Fri, Oct 12, 2012 at 9:16 AM, Adam Vollmer > >>>>> <[email protected]<javascript:>> > wrote: > >>>>>> This is a huge want for me as well. > >>>>>> > >>>>>> There are a few directions that this can take > >>>>>> > >>>>>> First, what I think everyone wants, is the ability to logically > sort their > >>>>>> resources instead of dumping everything into the same directory. It > can be > >>>>>> effectively transparent to aapt; all it has to do is understand how > to > >>>>>> recurse into subdirectories from res/layout-whatever and include > all of the > >>>>>> content in there. > >>>>>> > >>>>>> We've got literally thousands of resources; the ability to put lots > of them > >>>>>> into bins (e.g. store resources, player resources, misc) is a huge > help for > >>>>>> trying to sort out just what we actually have. > >>>>>> > >>>>>> A second ask, which isn't really related but which I think would be > really > >>>>>> neat and useful, would be to have "base" directories for resource > types, > >>>>>> with more specific subdirectories. For example, we've got drawable, > >>>>>> drawable-ldpi, drawable-mdpi, drawable-hdpi, drawable-xhdpi. What > if we had > >>>>>> a directory called drawable, which had subdirectories called ldpi, > mdpi, > >>>>>> hdpi, and xhdpi? > >>>>>> > >>>>>> Obviously, this doesn't mesh as well with the first suggestion, but > I'm > >>>>>> spitballing, and it would help our res directories from being giant > >>>>>> spaghetti messes > >>>>>> > >>>>>> > >>>>>> On Fri, Oct 12, 2012 at 11:35 AM, Xavier Ducrohet > >>>>>> <[email protected]<javascript:>> > wrote: > >>>>>>> > >>>>>>> This is orthogonal to the new build system as it's tied to aapt > (which > >>>>>>> the build system relies on). > >>>>>>> > >>>>>>> I'd like to improve things there but it'll come later. > >>>>>>> > >>>>>>> Could you describe your use case? Basically what do you want those > >>>>>>> subfolders to represent? > >>>>>>> > >>>>>>> On Fri, Oct 12, 2012 at 7:57 AM, Özcan Kaymak > >>>>>>> <[email protected]<javascript:>> > wrote: > >>>>>>> > Will we developers be able to organize drawables into subfolders > with > >>>>>>> > the > >>>>>>> > new build system? > >>>>>>> > There is also a issue filed about this: here > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Xavier Ducrohet > >>>>>>> Android SDK Tech Lead > >>>>>>> Google Inc. > >>>>>>> http://developer.android.com | http://tools.android.com > >>>>>>> > >>>>>>> Please do not send me questions directly. Thanks! > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Xavier Ducrohet > >>>>> Android SDK Tech Lead > >>>>> Google Inc. > >>>>> http://developer.android.com | http://tools.android.com > >>>>> > >>>>> Please do not send me questions directly. Thanks! > >>> > >>> > >>> > >>> -- > >>> Xavier Ducrohet > >>> Android SDK Tech Lead > >>> Google Inc. > >>> http://developer.android.com | http://tools.android.com > >>> > >>> Please do not send me questions directly. Thanks! > > > > > > > > -- > > Xavier Ducrohet > > Android SDK Tech Lead > > Google Inc. > > http://developer.android.com | http://tools.android.com > > > > Please do not send me questions directly. Thanks! > -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
