You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2011/09/04 14:15:15 UTC
[MATH] location for localization resource files
The location for the localization resources only appears to be needed
in the method:
LocalizedFormats.getLocalizedString()
so it is very easy to change where they are, now that the POM uses the
standard Maven resource location (previously it was using a subdir
only which prevented such a move)
As discussed else-thread we can now move the resources out of META-INF.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [MATH] location for localization resource files
Posted by sebb <se...@gmail.com>.
On 4 September 2011 18:56, Phil Steitz <ph...@gmail.com> wrote:
> On 9/4/11 10:45 AM, Phil Steitz wrote:
>> On 9/4/11 5:15 AM, sebb wrote:
>>> The location for the localization resources only appears to be needed
>>> in the method:
>>>
>>> LocalizedFormats.getLocalizedString()
>>>
>>> so it is very easy to change where they are, now that the POM uses the
>>> standard Maven resource location (previously it was using a subdir
>>> only which prevented such a move)
>>>
>>> As discussed else-thread we can now move the resources out of META-INF.
>> I am not sure I understand. These resources are needed at runtime
>> by applications using [math]. I guess you are suggesting that we
>> can put them somewhere else in the source tree and have the build
>> package them there. Is that what you mean? In that case, we need
>> to make sure to adjust the ant build as well. What is wrong with
>> the current setup, exactly?
>
> Sorry, I read the second message first. I don't care much, other
> than to make sure the Ant build does not get broken by the change.
I will check that.
> Personally, I prefer to err on the side of more stuff in the
> component's own pom, since it makes these kinds of problems easier
> to diagnose and requires less background knowledge to understand the
> build.
The localization entry in the Math pom was only necessary because the
patch to commons parent (v3) to add N&L to jars failed to take the
default resources directory into account. That was a mistake (*). Had
we used a different method to handle the N&L files the pom probably
would not have needed to specify the resources.
Using the standard Maven directory structure seems to me to be better
than customising the poms for projects that use resources.
(*) When commons parent 21 was updated to add N&L files for test jars,
the same technique was copied; the issue with the MATH test resources
has just revealed that we made a mistake in commons parent 3 and
propagated it in 21.
> Phil
>>
>> Phil
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [MATH] location for localization resource files
Posted by Phil Steitz <ph...@gmail.com>.
On 9/4/11 10:45 AM, Phil Steitz wrote:
> On 9/4/11 5:15 AM, sebb wrote:
>> The location for the localization resources only appears to be needed
>> in the method:
>>
>> LocalizedFormats.getLocalizedString()
>>
>> so it is very easy to change where they are, now that the POM uses the
>> standard Maven resource location (previously it was using a subdir
>> only which prevented such a move)
>>
>> As discussed else-thread we can now move the resources out of META-INF.
> I am not sure I understand. These resources are needed at runtime
> by applications using [math]. I guess you are suggesting that we
> can put them somewhere else in the source tree and have the build
> package them there. Is that what you mean? In that case, we need
> to make sure to adjust the ant build as well. What is wrong with
> the current setup, exactly?
Sorry, I read the second message first. I don't care much, other
than to make sure the Ant build does not get broken by the change.
Personally, I prefer to err on the side of more stuff in the
component's own pom, since it makes these kinds of problems easier
to diagnose and requires less background knowledge to understand the
build.
Phil
>
> Phil
>> ---------------------------------------------------------------------
>> 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
Re: [MATH] location for localization resource files
Posted by Phil Steitz <ph...@gmail.com>.
On 9/4/11 5:15 AM, sebb wrote:
> The location for the localization resources only appears to be needed
> in the method:
>
> LocalizedFormats.getLocalizedString()
>
> so it is very easy to change where they are, now that the POM uses the
> standard Maven resource location (previously it was using a subdir
> only which prevented such a move)
>
> As discussed else-thread we can now move the resources out of META-INF.
I am not sure I understand. These resources are needed at runtime
by applications using [math]. I guess you are suggesting that we
can put them somewhere else in the source tree and have the build
package them there. Is that what you mean? In that case, we need
to make sure to adjust the ant build as well. What is wrong with
the current setup, exactly?
Phil
>
> ---------------------------------------------------------------------
> 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