Le 09/02/2012 22:43, Gilles Sadowski a écrit : > Hello. > >>>> >>>> Some times ago, we had a discussion about some issues with Android >>>> devices. One issue was that the packaging system for Android did remove >>>> some folders we put inside META-INF. The folder we put there was >>>> localization. >>>> >>>> I would like to mode this folder from META-INF/localization to a new >>>> assets/localization, to better match Android (but not completely as we >>>> do not use their specific localization API and associated xml files). >>>> >>>> If we need other resources, they should also be put under this "assets" >>>> directory. >>>> >>>> What do you think ? >>> >>> Why not "resources" (which already exists and is more Java-ish)? >> >> The problem is not the resources folder, which is maven standard layout >> and should be used, as Sebb points out. >> >>> [Maybe it's the use of "META-INF" that is the problem.] >> >> Yes, the problem is the structure below the resources folder, which is >> the one that will be copied into the generated jar. >> >> For now, we have resources/META-INF/localization, which appears as >> META-INF/localization in the maven generated jar. I would like to have >> resources/assets/localization, which would appear as assets/localization >> in the jar. >> >> This is compliant with maven since in the project structure it lies >> below the resources directory, and this would be compliant with Android >> for which application specific resources should be in an assets directory. > > Does that mean that what is (just) below "resources" is not application > specific?
Some parts in the layout may be application specific, and some parts are mandated by Java (the META-INF directory) or other frameworks. The android platforms seems to have published a complex layout (see <http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources>) with lots of predefined directories under a "res" top folder (animator, anim, color, drawable, menu ...), which are associated with resource Ids. They also considered resources without Ids, which looked to us as something their tools would almost not touch, the "assets" directory (there is a very terse description in the res/raw entry). > Why would be the behaviour with "resources/localization" instead of > "resources/assets/localization"? For most platforms, I think it would be similar. I am only concerned with android trying to be too smart and managing thing it should not touch. So I tried to use the folder they knew about (so their build tools do not forget copying the resource files) but do not touch them or expect them to be registered in some way. > Did you have a problem because the "FastMath" resource data was under > "resources/data"? Or is it specific to l10n? I did have problems with the resource files from Orekit. These files were not present in the application. At first, they were also in the META-INF directory. At that time I thought it was standard Java practice to put some configuration files here, and several open-source projects do this. When we understood these files were ripped off the directory because Android thought it should own everything there, we tried ti find another place where to put this file, and Alexis pointed out the assets directory, which seemed a safe place. I did not have problems with resource/data, but I used only a simple jar conversion too (dx, from the platform tools) and did not build a completete application (an apk). So I don't know if the file would have been preserved by the complete build tool or not. > >> The current directory, lying under META-INF, was stripped out because >> some build/conversion tools considered they own META-INF. > > I always thought it was strange to have the files in there... :-} There are several other projects who did that. As seen in a forum, someone wondered if it was an emerging standard or an emerging anti-pattern ... Luc > > > Best, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
