commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] moving resources folder
Date Fri, 10 Feb 2012 10:06:59 GMT
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message