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(a)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