[hibernate-dev] Public API of Hibernate Validator

[Hardy Ferentschik]

Hi,

I am not a OSGi expert, but I guess we can think about this a little more.
As you say org.hibernate.validator and org.hibernate.validator.constraints  
should definitely
be public. Regarding the classes in org.hibernate.validator.engine I would  
suggest to create a
new package. ResourceBundleMessageInterpolator and ResourceBundleLocator  
needs to be exported.
Not sure about yet if there is something else.

I am still processing my email backlog and will have a closer look later.


--Hardy

Create a Jira issue and we can take it on board for Validator 4.1

On Sun, 18 Apr 2010 20:57:18 +0200, Gunnar Morling  
<gunnar.morling at googlemail.com> wrote:

> Hi guys,
>
> currently I'm experimenting a bit with integrating Bean Validation in
> general and Hibernate Validator in particular with OSGi. In that context  
> I
> wondered, whether there is some sort of "public" API of Hibernate  
> Validator.
> The generated HV OSGi manifest (see HV-267) currently exports all  
> packages,
> but I think there should be a more fine-grained distinction, which
> packages/classes should be publicly available.
>
> For instance "org.hibernate.validator" and
> "org.hibernate.validator.constraints" would be part of such a public API
> (while "org.hibernate.validator.constraints.impl" wouldn't). Things are
> getting more complicated when looking at  
> "org.hibernate.validator.engine".
> Most of the classes there should be considered private to HV, but at  
> least
> ResourceBundleMessageInterpolator (together with the new stuff related to
> ResourceBundleLocator in  
> "org.hibernate.validator.engine.resourceloading")
> is of interest for users/integrators.
>
> Using OSGi, one can control exported types on a class level, but  
> presumably
> it makes things easier, if certain complete packages make up the public  
> API.
> Also besides the OSGi scenario I think it's useful to explicitly describe
> the public API. That way users would know, which HV classes they are
> "allowed" to use (and therefore can rely on their stability) and which  
> ones
> not. We OTOH would know which classes we can modify without the need to
> maintain backward compatibility.
>
> WDYT? If we come to the conclusion that for instance
> ResourceBundleMessageInterpolator should be moved to another package, I
> think it might be a good idea to do that for 4.1, as right now the  
> number of
> concerned classes still seems very limited.
>
> Gunnar