[hibernate-dev] Message-Templates from multiple JARs

[Emmanuel Bernard]

On 16 févr. 2010, at 09:58, Max Rydahl Andersen wrote:

> 
> ----- "Emmanuel Bernard" <emmanuel at hibernate.org> wrote:
> 
>> I don't see i18n as something that should necessarily be packaged
>> inside a component. Resource keys are generally grouped in one or two
>> files for the overall application (so that fixing a typo is quick).
> 
> You must be developing small or monolith applications then ;)
> 
> The common way I know of (from eclipse apps) is that the resource bundles
> *specific* to that module/plugin is stored in the module and if there are 
> some common phrases/messages they are simply put into separate module/plugin
> or you simply depend on that module/plugin you want to share that common phrase
> with.
> 

Do you have some docs on how Eclipse handles it?
What's a module? a UI-less element whereas a plugin has a UI?

>> If
>> you have to dig into individual or even third party components, it
>> becomes a pain point. So I don't see that as encapsulation violation
>> (or at this stage, you have to consider that displaying the error
>> message to the user is violating encapsulation).
> 
> Not following this, additional resource bundles is/should be possible to add translations
> to 3rd party components without changing it.
> 
> -max
> 
> 
>> 
>> You would put the @ResourceBundle on the constraint annotation? I
>> don't like the idea, it would encourage the creation of a myriad of
>> different resource bundle files. Also today the spec allows to inject
>> your own ResourceBundle implementation via the MessageInterpolator
>> (will even be better in Hibernate Validator after HV-238). Adding a
>> @ResourceBundle will clash with this freedom.
>> 
>> Another point I want to mention, Hibernate Validator 3.x had support
>> for a more sophisticated RB approach but it turned out to be a big
>> ball of inconsistency and holes and I purposely simplified the model
>> in Bean Validation.
>> 
>> On 15 févr. 2010, at 21:36, Hardy Ferentschik wrote:
>> 
>>> Hi,
>>> 
>>> Having multiple resource bundles and some custom way of specifying
>> these bundles is
>>> related to HV-238 and HV-251.
>>> 
>>> Having a ResourceBundleLocatorStrategy should solve your problem
>> Gunnar, right?
>>> 
>>> The default strategy could behave like it does now and we can
>> provide an additional strategy
>>> which allows for multiple resource bundles. You would specify the
>> strategy in the hibernate
>>> config file. The names for the different resource files could also
>> be specified in the
>>> config (or maybe there is a better way!?)
>>> 
>>> --Hardy
>>> 
>>> 
>>> On Mon, 15 Feb 2010 16:51:13 -0300, Gunnar Morling
>> <gunnar.morling at googlemail.com> wrote:
>>> 
>>>> I agree, there probably won't be that many 3rd-party constraint
>> vendors :-)
>>>> 
>>>> Nevertheless I think the problem is not too exotic. In my day job
>> for
>>>> example we're building a large-scale enterprise application, which
>> is made
>>>> up of multiple JARs ("components") developed by multiple,
>> independent
>>>> development teams.
>>>> 
>>>> Now it would be great, if two teams could develop independently
>> their custom
>>>> constraints, specific to their component. As of now they would have
>> to
>>>> provide a unified ValidationMessages.properties, violating the
>> encapsulation
>>>> of the components.
>>>> 
>>>> A rather simple solution might be a meta-annotation @MessageBundle,
>> which
>>>> optionally could be used at constraint annotation type declarations
>> to
>>>> specify the name of the message bundle to be used. That way name
>> collisions
>>>> between constraints from different JARs still could occur, but
>> finding
>>>> unique names should not be too hard. If that meta-annotation is not
>> given, a
>>>> fallback to ValidationMessages.properties might be used.
>>>> 
>>>> WDYT?
>>>> 
>>>> Cheers, Gunnar
>>>> 
>>>> 
>>>> 2010/2/15 Emmanuel Bernard <emmanuel at hibernate.org>
>>>> 
>>>>> Yes, you need to copy it over or more likely adapt the messages to
>> your
>>>>> application (in which case you don't care).
>>>>> The problem with listing the resource bundle is that you need an
>> order to
>>>>> specify which has precedence over which.
>>>>> 
>>>>> Another solution could be some sort of plugin system where 3rd
>> party
>>>>> constraint makers can reference automatically a resource bundle.
>> But
>>>>> realistically, how many 3rd party constraint makers will there
>> be?
>>>>> 
>>>>> The question is: is the additional complexity for the solution
>> worth the
>>>>> current problem?
>>>>> 
>>>>> On 14 févr. 2010, at 22:00, Gunnar Morling wrote:
>>>>> 
>>>>>> Hello you two,
>>>>>> 
>>>>>> recently I thought about the following situation:
>>>>>> 
>>>>>> * I have a JAR containing a custom constraint on the class path
>> (could be
>>>>> a constraint provided by some 3rd-party constraint vendor)
>>>>>> * I have another custom constraint within the actual project
>> itself (and
>>>>> therefore a ValidationMessages.properties as well)
>>>>>> 
>>>>>> Now the ValidationMessages.properties provided by the 3rd-party
>> vendor is
>>>>> hidden by my own ValidationMessages.properties, which - if I'm not
>> mistaken
>>>>> - requires me to copy the contents of the first to the latter.
>>>>>> 
>>>>>> Is there any better solution to this problem?
>>>>>> 
>>>>>> Maybe BV/HV should provide some means for constraint vendors to
>> specify
>>>>> the resource bundle containing messages? If you think, that's
>> useful I'd
>>>>> create a JIRA issue for that one.
>>>>>> 
>>>>>> Thanks for any ideas,
>>>>>> 
>>>>>> Gunnar
>>>>> 
>>>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> -- 
> /max